Witajcie.
Chciałbym, przy prywatnym projekcie, odejść od jQuery i skupić się na innym frameweroku/bibliotece w celach głównie edukacyjnych. Pytanie własnie tylko na jakim ?
Potrzebne mi to będzie do zarządzania elementami DOM, jakieś małe animacje, ładowanie danych w tle, filtrowanie list, drag&drop, upload itd. ale jednak backend będzie stał robiony w php (laravel) a nie np. node.js

Najbardziej skłaniam się do użycia angulara tylko właśnie nie wiem czy to nie za duży kombajn jak na moje potrzeby ? Czy jednak angulara nie powinno się raczej używać do stron stricte typu SPA a nie portali pisanych w PHP tworząc tylko swoje dyrektywy ?
Jeśli angular do 1.4 czy może już jest sens się wdrażać w 2.0 ?

Co byście polecili ?

Jeśli chodzi o Angulara, to szczerze odradzam, bo to dość źle zaprojektowane bydlę: http://www.webkrytyk.pl/krytyka/my-truth-about-angular-js/

W sumie jeśli chcesz się skupić na takich dość prostych sprawach typu DOM, animacje itd. to może warto zerknąć na http://microjs.com/ i wybrać coś małego, co Ci podpasuje? Bo nie tworzysz typowej apki SPA, tylko raczej podrasowujesz JS-em coś "bardziej tradycyjnego".

Jeśli natomiast kręcą Cię dyrektywy Angulara to najlepiej będzie Ci podsunąć hasło Web Components

Z frameworków typu Angular poleciłbym mimo wszystko Backbone'a. Może i jestem konserwatystą, ale dla mnie jest to najczystsze rozwiązanie.

react + flux?

@com nie sądzisz, że to armata na muchę w tym wypadku? React to potężne bydlę z całym tym swoim konceptem Virtual DOM, JSX itd. Do tego dochodzi Flux ze swoimi obostrzeniami.

Na mniejszą skalę chyba lepiej sprawuje się nie virtual, a asynchronous DOM: https://github.com/wilsonpage/fastdom

patrzenie, że coś jest armata nie zawsze jest dobrym podejściem, bo co jak będzie chciał to rozwinąć i ten mu już tego nie da. Dla aplikacji którą wiemy że to jest projekt tygodniowy to może i tak, ale najlepiej nie zamykać się na rozwój. To trochę tak jak ludzie mówią że nie użyją sf czy nawet tego lv, bo to kobyła a potem projekt się rozrasta i w jakimś mikro muszą wszystko klepać z palca

btw to była tylko propozycja, Twój asynchronous DOM być może tez jest dla tego przypadku dobry, ale go nie znam akurat

W ten sposób wytworzyliśmy sobie pluginy do dodawania w jQuery

React to typowe narzędzie do SPA i IMO tam się najlepiej sprawdzi. Względnie można go użyć jako systemu szablonów, ale to raczej bez sensu zbytnio…

Ogólnie w JS ostatnio obserwuję zbyt duże przywiązanie do poszczególnych narzędzi. Pierwszy przykład z brzegu: CSS Modules, czyli pomysł na lokalne CSS (zatem dublujemy style[scoped] ze specki HTML5, ale nvm), które… są kompilowane do modułu ES6 (!), działają na zasadzie generowania bezsensownych nazw klas, żeby się z niczym nie pokrywały () i są przedstawiane jako obiekty w kodzie JS (!) do wstawienia w atrybut [style] reużywalnych komponentów (!!) - a wszystko to jako plugin do jedynego słusznego managera pakietów, WebPacka (sic!). A skąd tak poroniony pomysł? Z Reacta, który robi coś bardzo podobnego… Innymi słowy: tworzy się zwarte ekosystemy przywiązane ściśle do konkretnych rozwiązań, które wręcz nie mają prawa istnieć poza nimi. A tuż obok istnieją standardy robiące dokładnie to samo (Web Components choćby). Ale to taka niepotrzebna w gruncie rzeczy dygresja…

@Comandeer - dzięki za artykuł, widzę, że Twojego autorstwa W sumie to tylko utwierdził, mnie w przekonaniu, że angular nie jest "dobry" aczkolwiek, czy nie warto się pochylić w stronę wersji 2.0, skoro, tak jak też wa artykule było powiedziane, zmieniają podejście raczej na lepsze? Szukam czegoś co było by też dobre pod względami zawodowymi, dlatego wersje "micro" raczej nie są moim targetem.

Może macie wyrobione zdanie o fw Vue.js ? Natknąłem się na niego właśnie przy przygodzie z laravelem, ma już kilka lat, troszkę czerpał ideę z angulara, ale wydaje się znacznie szybszy i "czystszy".

ale JQuery wcale nie jest armata, jakby nią było, nie trzeba było by robić w niej tych wszystkich pod narzędzi w postaci pluginów, co zresztą jest wgl bezsensu bo kod tam to spaghetti. A Web Components to nadal drafty są, a gdyby nie te biblioteki to standard by nie powstał wgl btw nie siedzę aż tak w frontendzie jak ty

JQuery też wiele zmieniło w samy js, min przyczyniło sie do stworzenia w końcu queryselector

Angular 2.0 wprowadza 3 czy 4 rodzaje zapisu atrybutów w HTML-u - tam dopiero będzie sajgon pod tym względem To będzie zupełnie inny framework niż 1.x i prawdę mówiąc nie wiem czy to go nie zabije - jednak wiele firm zbyt dużo zainwestowało w Angulara 1.x.

Pod względami zawodowymi Angular 1.x to jednak obecnie must have, bo wszyscy go używają (co mnie ciut dziwi, zważając na wszystkie jego dziwactwa - po prostu miał doskonały marketing). Więc znać podstawy z niego trzeba, ale wgłębiać się w to niekoniecznie. Dużo firm także bawi się Emberem, który jest jeszcze większą kobyłą. Na szczęście Bacbkone dalej jest modny i też sporo firm go używa (a ostatnio kumplowi nawet się udało przekonać swoją firmę do porzucenia Angulara na jego rzecz!).

Co do Vue.js - jak dla mnie to taki Angular.js z reactowymi naleciałościami. Nie bawiłem się tym, bo po prostu tego typu rozwiązania mi nie podchodzą. Jednak pod tymi względami jestem konserwatystą. Ale tak na oko to pewnie cierpi na kilka angularowych przypadłości.

Ciekawy może być także np. Taunus, ale jeśli nie lubisz node.js/io.js to raczej nie dla Ciebie Główne założenie w nim jest takie, że część kodu jest wykonywana na serwerze i na kliencie (współdzielony kod JS, czyli tak w dużym skrócie: izomorficzne aplikacje).


Polecam poczytać The Extensible Web Manifesto

Owszem, nie jest - jeśli się go używa do tego, do czego został stworzony: jako helper DOM-owy. Ale jak się z niego robi rozwiązanie wszystkich problemów to sam się problemem staje.

Tylko to ciągnie za sobą naukę kolejnego sposobu tworzenia całych web aplikacji, bez wsparcia wstecznego. Mówiłem o tym:
https://developer.mozilla.org/en-US/docs/Web/Web_Components


Podpisuję się pod tym i ja

Są polyfille. Poza tym - React czy Angular nie dostarczają BC żadnego (Angular 2.0 z Angular 1.x ma aż NIC wspólnego ). Owszem, nie ma BC, ale mówimy tutaj o otwartym standardzie. I nagle ten standard jest zastępowany przez na szybko wymyślone rozwiązania w JS, które zamykają Cię w jednym, bardzo ograniczonym ekosystemie. W przypadku standardu, nawet jako draft, nie masz tego ograniczenia - Twoje wypociny powinny działać ze wszystkimi narzędziami, przeglądarkami itd.

W Angular 2 przynajmniej tę rzecz zrozumieli i zamiast wymyślać swoje własne komponenty to postanowili iść w Web Components (i od razu to zepsuli wprowadzając własną składnię atrybutów HTML). A jeśli chcemy zbudować jakiś framework, to i tak lepiej go oprzeć na standardzie (który w 98% przypadków jest low-levelowy) i dorobić do niego warstwę abstrakcji niźli dłubać wszystko od początku i zamykać się we własnym światku.

No i IMO Web Components powinny służyć do tworzenia hermetycznym komponentów GUI - tylko i wyłącznie. Z głównym trzonem aplikacji porozumiewałyby się przy pomocy systemu pub/sub (albo po prostu eventów DOM). Web Components nie powinny tykać logiki aplikacji jako takiej (wyobrażasz sobie żądanie Ajaksem jako znacznik ajax-request?).

a tak swoją droga gdyby google nie zabrało się za tworzenie tego co nazwano potem polymer to web components by nie powstał. Co się sprowadza do tego co napisałem, że gdyby nie biblioteki standardów by tez nie było.

@com no właśnie: Extensible Web Manifesto. Rzucić pomysł → implementacja w JS → zgłosić do standaryzacji pokazując prototyp w JS → budować implementację natywną na jego podstawie.

Chociaż nie wiem czy X-Tags Mozilli nie było pierwsze. A jakby się uprzeć i poszperać w speckach W3C to wyjdzie, że pomysł narodził się koło… 1998 roku http://www.w3.org/TR/NOTE-HTMLComponents

tak ale tam to bardziej xhtmla się tyczyło. No ok rozumiem Cię, ale czekanie na standard trwa czasem wieki, tak by x-tags czy polymer nie powstały, tylko standard narzuca Ci jedyną słuszną drogę, nie jesteś elastyczny, bo musisz się trzymać wyznaczonej przez nich ramy. Jak chociażby te własne znaczniki htmla



a dyrektywy np angularowe z 1.x one nie modyfikowały wgl standardu, bo dostawiłes data-* i nawet parsery się nie miały do czego przyczepić

Ale proces standaryzacji obecnie się zmienił. HTML i DOM to obecnie żywe standardy, zmieniane na pniu, CS jest podzielony na moduły niezależnie implementowane, a wiele obecnych standardów to inicjatywy oddolne. Web Components powstały w 3 lata i obecnie istnieje pełna implementacja w Chrome i prawie pełna w lisku. W porównaniu do css3, którego projekt powstał w 1998 to to jest chwilka.
Obecnie standaryzuje się to, co jest już de facto standardem, więc z tym narzucaniem to nie jest tak do końca. To jest po prostu oficjalnie zatwierdzenie praktyk wykorzystywanych przez webmasterów (custom tagi są od lat, teraz się dochrapały wsparcia ze strony DOM - tylko tyle i aż tyle).

Nie mówię, że frameworki mają nie powstawać, ale jeśli istnieje jakiś standard, który robi to, co ma robić nasz framework, to czemu mamy się na nim nie oprzeć? To wymyślanie koła na nowo.

BTW Ty podesłałeś wstęp z notki grupy roboczej o web components, nie ze specki autorzy specki są zgoła inni

Co do dyrektyw angulara: owszem, można było, ale preferowanym i reklamowanym sposobem były atrybuty ng-*. Jednak to i tak najmniejszy problem tego frameworka

dobrze ale jaki % osób używa już na masowa skale polymer czy x-tags. Standard dopiero powstaję, więc jak ktoś chce to wybierze jeden z tych dwóch i z tego skorzysta, ale alternatywa niekoniecznie musi się na tym przecież opierać. HTML i DOM się rozwija, bo HTML5 się jeszcze nie ustandaryzował, pamiętam czasy kiedy przechodziłem na 5, a wszędzie w naszym kraju na stronach dalej był html4, zresztą nie tylko w naszym kraju, a teraz nikt sobie nie wyobraża pisać w 4.

Nie znalazłem innej wersji, wszędzie tak czy owak widnieje Google

to nie nie do końca tak, bo te tagi wygl wtedy data-ng-* i takie były preferowane przez standard, a że ludzie są za leniwi to nie używało się data bo działać działało, ale że nie było zgodne ze standardem to kto się tym przejmował..

No nie musi - tylko co się zyskuje świadomie omijając rzecz, która w najbliższej przyszłości stanie się oficjalnie standardem? Wówczas autor biblioteki stanie przed dylematem: albo ciągniemy BC i tworzymy zamknięty rezerwat, albo zrywamy BC i tworzymy rozwiązanie, które może współpracować z innymi. Angular 1.x taki rezerwat stworzył, więc Angular 2 próbuje to naprawić - ale ciut za późno niestety.

HTML5 jest już od października standardem. Zresztą to nie tak, że HTML się rozwija, bo HTML5 nie jest skończony. Nie. HTML5 to pozostałość starego procesu standaryzacji W3C. Prawdziwy HTML (specka od WHATWG) nigdy nie będzie zakończony, ale będzie ewoluować wraz z Siecią. To żywy standard.

Co do specki web components: faktycznie, sami ludzie z Google. Z tym, że to edytorzy. Nie wiadomo kto przyczynił się do stworzenia samej specki. No i redaktorzy się zmieniają (np do 2012 Hixie był redaktorem połowy specek w W3C )

W docsach angulara wszędzie jest ng-*. A przynajmniej było jak zerkałem.

owszem tu się z Tobą zgadzam, ale nie koniecznie biblioteka ta musi bazować na web components, bo to jest tylko propozycja z której można skorzystać, a nie trzeba. Ona nie narzuca teraz nam tego że każda web aplikacja w przyszłości musi się na tym opierać, zapewne za x lat tak będzie, ale to nie nastąpi tak z dnia na dzień. Angular zbudował własny światek, tak jak mówisz, ale react np to już nie do końca to samo z tym jego wirtualnym dom.

Owszem, ale puki był otwartym standardem, można było w nim upychać wszystkie te nowinki i to sprawnie robiono. Nie wiedziałem, ze się już ustandaryzował, dobrze wiedzieć, a to że pożyczyli sobie go od WHATWG to ja wiem

Edytorzy to jedno, autorzy też tam są

Owszem ale inicjatywa wyszła od Google a na pewno udzielali się tam inni również, w końcu w3c zrzesza cała ich masę.

no tak ng-* ale to już wina dev Googla za to odpowiedzialnego, ale sam standard był na to przygotowany od dawna i nawet Angular miał wsparcie

Nie twierdzę, że każdy webapp ma się opierać na web components - byłbym pierwszym, który by zaprotestował mówię jedynie, że nie ma sensu tworzyć np poronionych pomysłów z lokalnymi modułami CSS, podczas gdy wystarczy napisać prostego polyfilla dla style[scoped]. Tak samo nie ma sensu kombinować z jakimiś własnymi pomysłami na custom elements jeśli istnieją Web Components. Jeśli potrzebujemy custom elementów, to weźmy web components i doróbmy abstrakcję na ich podstawie (co robi Polymer).

React to wgl ściśły rezerwat prawdę powiedziawszy. Dopóki nie wprowadzili Fluxa i nie wrzucili do niego HTML + CSS okraszonych składnią łudząco podobną do zarzuconego E4X to było to całkiem miłe, odświeżające rozwiązanie. Teraz to jest rozwiązanie, pod które jak się już napisze kod to się będzie tkwić w tym po uszy.

Obecnie środowisko webdevów za bardzo ufa narzędziom i przywiązuje się grubymi łańcuchami do nich. I to mnie ciut niepokoi. Warunki dyktują albo ludzie, którzy siedzą nad aplikacjami, w których liczą się tylko wydajność, wydajność i jeszcze raz pieniądze (fb i react), albo ludzie, którzy próbowali z nazwy JS uciąć S (google i angular). Tak ja to widzę. Mam nadzieję, że jednak się mylę.

No jasne, że można ale nie zawsze autorom przyjdzie coś takiego na myśl. Albo bedzie brakować im do tego standardu. Angular np powstał wczesniej od web componentow to nie moglich użyć w 1.x a co planuka jak mowiłeś w 2. Podobnie react powstawał kiedy to jeszcze raczkowało.

No moze i tkwi sie w tym ale idac takim tokiem wrocimy do vaniliajs ktore nie mowie ze jest zle ale nie zawsze daje taka wygode pracy.

Co do react i flux to chyba coś pomieszałeś albo ja coś źle Cie zrozumiałem.

Nie mówię, że biblioteki są złe, ale niektóre ewidentnie są pisane w taki sposób, żeby nie dało się z nich zrezygnować. A to jest po prostu nieporozumienie. Zamiast operować na istniejących standardach to wymyślają własne, cęsto świadomie z tym standardem sprzeczne (bo tak). Nie mówię tutaj o Angularze (chociaż on AFAIR powstawał równolegle do Polymera), ale o nowszych bibliotekach i pomysłach takich jak wspominane już CSS Modules.

Co do Reacta: raczej nie pomieszałem - wchłonął CSS-a https://speakerdeck.com/vjeux/react-css-in-js a składnia E4X (ECMAScript 4 XML) to przecież nic innego jak ich JSX (nawet nazwa oparta na tym samym!). Zresztą filozofia Fluxa wcale nie jest aż taka odkrywcza i osobiście twierdzę, że architektura eventowa zaproponowana kilka lat temu przez Zakasa daje więcej możliwości http://www.slideshare.net/mobile/nzakas/sc...on-architecture

Właśnie też szukam nowych lepszych rozwiązań. A co myślicie o http://somajs.github.io/somajs/site/ ?

Prawdę mówiąc nie znam, ale nie wygląda źle. Podoba mi się zwłaszcza dispatcher.

Tak ale napisałeś że Flux to css albo ja Cię tak zrozumiałem, owszem ale to przecież nic odkrywczego nie jest, css w js był od zawsze, tu zaletą tego jest to że można przekazać sobie go jako obiekt, poza tym modyfikacje css to i w jQuery już miałeś w formie takiej jak tu tylko, że inaczej to wywoływało. Co do Fluxa nwm być może masz rację ja nie mówię, że nie.

Faktycznie, zdanie było dość niefortunne składniono i wyszło na to, że to Flux, a nie React, wchłonął CSS-a. Oczywiście chodziło mi o React

Co do porównania $.fn.css z tym, co robi React: to zupełnie różne sprawy przecież. jQuery bowiem pozwala na chamskie modyfikowanie stylów wybranego elementu, a filozofia Reacta zakłada, że będziemy tak robić zawsze. Zwróć uwagę na to, że FB było zmuszone albo generować siekę zamiast poprawnych nazw klas i wymusić jedno, konkretne narzędzie do tworzenia całego kodu, albo dorobić do Reacta obsługę stylów we wręcz niesamowicie chamski sposób - czyli przy pomocy [style]. Zatem świadomie łamią zasady podziału aplikacji na warstwy. Ale równocześnie w prezentacji o tym chyba z 3 razy pada termin at scale - i być może faktycznie przy ich rozmiarach ma to jakieś sensowne przełożenie na produktywność. Szkoda tylko, że cała reszta świata webdevu zachowuje się jakby tego at scale tam nie było i pcha tego typu rozwiązania do najprostszych rzeczy. Wydaje mi się, że obecnie to problem dostosowuje się do rozwiązania, a nie odwrotnie…

Tym bardziej, że jak pokazuje Yandex ze swoim BEM całkowicie odwrotne podejście do problemu (czyli super ścisła izolacja poszczególnych warstw) również sprawdza się at scale. I jest na pewno o wiele przyjemniejsza w modyfikacji.

Osobiście z podejściem Reacta widzę jeszcze jeden problem: jest nieprzyjazne w stosunku do CSP (Content Security Policy) i wymaga pozwolenia na style inline - co jest po prostu obniżaniem bezpieczeństwa. Akurat miałem do czynienia z tego typu projektem kiedyś i szło się pociąć próbując lawirować między CSP, a raportami wydajności przedstawianymi przez PageSpeed

Patrzę na nagłówki FB właśnie i potwierdzają się moje przypuszczenia: FB stosuje CSP, ale musi też stosować unsafe-inline i unsafe-eval dla skryptów i stylów. Myślę, że nazwy tych opcji mówią same za siebie CSP z założenia ma chronić przed XSS właśnie wycinając wszystkie atrybuty [on…] (może stąd Polymer ma [on-click]? ) i [style]. Wyłączenie tego w CSP (przed czym przestrzega nawet specyfikacja; inna rzecz - po co pozwalać na coś, przed czym się przestrzega?) jest IMO śmieszne i całkowicie neguje sens używania CSP na pierwszym miejscu.

a od czego są klasy, style jako tako się raczej nie używa, nawet w php inline się nie zalecało, choć tak było łatwiej.

a Angular co robił tak samo pakowało się je do ng-style albo do style inline. Co do unsafe-inline to przecież można spotkać niemal wszędzie bo kto nie używa js. Rozumiem jesteś na nie ale to już takie czepianie dla samego czepiania się

No właśnie o to chodzi, że teraz best practice to wciskanie wszędzie stylów inline!

Dlatego spotkał się z tak dużą krytyką, która IMO jest w pełni zasłużona (obadaj link do webkrytyka w tym temacie - tam wyjaśniam to dogłębnie)

Chyba nie zajrzałeś do CSP unsafe-inline w stosunku do JS oznacza:

co od dość dawna nie uchodzi za najlepszą praktykę. No i jest doskonałym miejscem do rozplenienia się XSS. Natomiast jeśli mówimy o skryptach inline'owanych w nagłówku strony dla zwiększenia wydajności, to CSP 2.0 ma na to odpowiedź: http://www.w3.org/TR/CSP2/#source-list-valid-hashes → czyli coś jak checksumy dla plików. Problem w tym, że obecnie interpretuje to głównie Chrome i Firefox i jeszcze 2 miechy temu nie dało się tego używać, bo… Googlebot się wykrzaczał (co ciekawe user agent PageSpeeda nie - dziwi mnie, że utrzymują u siebie boty na różnych wersjach Chromium). Nie wiem jak obecnie sytuacja wygląda.

Ustanowione przez kogo?

No właśnie nie tylko bo to również:


A te ostatnie to nwm o czym mowa

Przez z jednej strony Reacta, z drugiej przez Angulara, a trzeciej przez środowisko webdevów, które bezrefleksyjnie podąża za tym, co proponują duzi. Jeszcze raz odsyłam do CSS Modules tutaj już zalinkowanych - to jest najlepszy pokaz tego.

No właśnie o

Owszem, brak wsparcia tego w CSP 1.0 był dużym błędem, ale CSP 2.0 to naprawia. Teraz trzeba czekać na szerszą adopcję. Chrome i Firefoks mają od ok. 5-6 wersji (więc Opera też). Problemem może być obecnie Safari i IE - one po prostu nie przepuszczą tego typu skryptów, więc zostanie albo przerzucenie tego do zewnętrznych skryptów i ładne ładowanie przy pomocy [defer][async], albo dostawienie tego nieszczęśliwego unsafe-inline.

to że oni dają taka możliwość nie oznacza, że trzeba tego używać, html sam w sobie też daje i co z tego, wiec to nie argument. Nie linkowałeś do css modules tylko o nich napisałeś albo coś przeoczyłem, ale linka możesz rzucić. IE to w dużej mierze się wypina na to co wędruje w nagłówkach. A co do twojego pierwszego punktu z krytyki angulara to z użyciem data traci on na znaczeniu bo wtedy jest jak najbardziej poprawnym z punktu widzenia DOM. A react ma ten swój virtual DOM wiec też nie masz tego w kodzie o czym tam napisałeś, czy web componets i shadow DOM.

a całe CSP to też, tyle lat webdev bez tego sobie radził, wiec nie ma co się nad tym rozwodzić, jasne że lepiej jakby działało ale bez tego można sobie poradzić

Może dla Ciebie czy dla mnie nie… ale wystarczy się rozejrzeć trochę w światku frontu, żeby zauważyć, że dużo osób na tego typu rzeczy jest napalona.

Fakt: https://github.com/css-modules/css-modules

Problem w tym, że 1. punkt krytyki Angulara nie ma nic do poprawności HTML-a (HTML-a, nie DOM!) Chodzi o fakt przenoszenia logiki z JS do HTML-a co jest kuszące, ale niekoniecznie okazuje się czymś, co przynosi wymierne korzyści.

Jak nie? Virtual DOM to jedynie mechanizm diffowania aktualnego drzewka DOM z przyszłymi zmianami - zatem jeśli w Virtual DOM znajdzie się [style] to będzie to miało przełożenie 1:1 do prawdziwego DOM

Ale przecież Shadow DOM nic nie zmienia - wciąż jest to DOM i dotykają go dokładnie te same przypadłości, co "jawny" DOM. To drzewko po prostu nie jest wystawione publicznie

Tak można powiedzieć o wszystkim z HTML5 Po co nam np. input[type=email] - mamy regexy.
Jasne, da się bez tego poradzić, ale bardzo to sprawę ułatwia. Nie rozumiem czemu mam sobie sprawy nie ułatwiać, jeśli istnieje taka możliwość? Jeśli priorytetem jest bezpieczeństwo, to CSP sprawdzi się w tym momencie znakomicie. Jeśli jest położony nacisk głównie na wydajność to w tym momencie niekoniecznie (trza by poczekać do zmian, o jakich pisałem w kontekście CSP 2.0). Jednak czysty HTML z reguły działa z CSP bez problemu, więc nie jest to aż tak duży problem.

nie to miałem na myśli, a w zasadzie to już sam nwm co miałem

te input to wcale nie działają poprawnie

A co do samego CSP to jasne że lepiej jest mieć niż nie mieć, ale akurat bez tego można sobie poradzić, backend itak jest od tego żeby to przefiltrować

Ale częściej działają niż nie działają

Pewnie, ale wychodzę z założenia, że dwie kłódki są pewniejsze od jednej.

nwm, email można podać w stylu bodajże a@a i przejdzie

pewnie że tak, tego nigdy za wiele

admin@localhost - no przecież, że poprawny Ale fakt, to już skrajnie edge'owy przypadek

no tak, ale email na pętli zwrotnej, to chyba nie powinno tak działać że to ma domyślne

https://css-tricks.com/the-debate-around-do...ed-css-anymore/ → doskonałe podsumowanie problemów, o których wspominałem