Jaki framework / biblioteka ? Opcje

[GreenGo]

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 ?

[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.