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]

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.

[com]

react + flux?

[Comandeer]

@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

[com]

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

[Comandeer]

patrzenie, że coś jest armata nie zawsze jest dobrym podejściem

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…

[GreenGo]

@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".

[com]

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

Ten post edytował com 21.06.2015, 22:40:46

[Comandeer]

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?

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

A Web Components to nadal drafty są

Polecam poczytać The Extensible Web Manifesto

JQuery wcale nie jest armata

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.


Ten post edytował Comandeer 21.06.2015, 22:47:22

[com]

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

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.

Podpisuję się pod tym i ja

[Comandeer]

Tylko to ciągnie za sobą naukę kolejnego sposobu tworzenia całych web aplikacji, bez wsparcia wstecznego

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?).

[com]

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.

[Comandeer]

@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

[com]

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

Web Components
W3C Working Group Note 24 July 2014
...
Authors
Dominic Cooney, Google

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ć

Ten post edytował com 21.06.2015, 23:25:09

[Comandeer]

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

Ten post edytował Comandeer 21.06.2015, 23:40:10

[com]

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

[Comandeer]

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.

Ten post edytował Comandeer 22.06.2015, 00:01:00

[com]

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

[Comandeer]

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

[com]

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.

Ten post edytował com 22.06.2015, 01:24:48