Jaki framework / biblioteka ? Opcje

[Comandeer]

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

[viking]

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

[Comandeer]

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

[com]

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.

[Comandeer]

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 (IMG:style_emoticons/default/wink.gif)

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 (IMG:style_emoticons/default/wink.gif) 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]? (IMG:style_emoticons/default/biggrin.gif) ) 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.

[com]

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.

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ę (IMG:style_emoticons/default/wink.gif)

[Comandeer]

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.

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

a Angular co robił tak samo pakowało się je do ng-style albo do style 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)

Co do unsafe-inline to przecież można spotkać niemal wszędzie bo kto nie używa js.

Chyba nie zajrzałeś do CSP (IMG:style_emoticons/default/wink.gif) unsafe-inline w stosunku do JS oznacza:

Kod

<button onclick="zrobmyCos();">Przycisk</button>

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.

[com]

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

Ustanowione przez kogo?

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

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

jako fragment strony, pomiędzy znacznikami <script> oraz </script>

A te ostatnie to nwm o czym mowa (IMG:style_emoticons/default/smile.gif)

[Comandeer]

Ustanowione przez kogo?

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.

A te ostatnie to nwm o czym mowa

No właśnie o

jako fragment strony, pomiędzy znacznikami <script> oraz </script>

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.

[com]

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ć

[Comandeer]

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

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.

Nie linkowałeś do css modules tylko o nich napisałeś

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

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.

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

A react ma ten swój virtual DOM wiec też nie masz tego w kodzie o czym tam napisałeś

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

czy web componets i shadow 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

a całe CSP to też, tyle lat webdev bez tego sobie radził, wiec nie ma co się nad tym rozwodzić

Tak można powiedzieć o wszystkim z HTML5 (IMG:style_emoticons/default/wink.gif) 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.

[com]

nie to miałem na myśli, a w zasadzie to już sam nwm co miałem (IMG:style_emoticons/default/biggrin.gif)

te input to wcale nie działają poprawnie (IMG:style_emoticons/default/biggrin.gif)

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ć (IMG:style_emoticons/default/smile.gif)

[Comandeer]

te input to wcale nie działają poprawnie

Ale częściej działają niż nie działają (IMG:style_emoticons/default/wink.gif)

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ć

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

[com]

nwm, email można podać w stylu bodajże a@a i przejdzie (IMG:style_emoticons/default/biggrin.gif)

pewnie że tak, tego nigdy za wiele (IMG:style_emoticons/default/biggrin.gif)

[Comandeer]

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

admin@localhost - no przecież, że poprawny (IMG:style_emoticons/default/wink.gif) Ale fakt, to już skrajnie edge'owy przypadek

[com]

no tak, ale email na pętli zwrotnej, to chyba nie powinno tak działać że to ma domyślne (IMG:style_emoticons/default/smile.gif)

[Comandeer]

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