Forum PHP.pl

Od siebie rzekłbym tak: jQuery, Angular.js i React.js są must-have jeśli szukamy pracy. Natomiast jeśli chcemy się szkolić w JS, warto na nie uważać.

Angular.js ma bardzo złą architekturę i pomysły, co podsumowałem swego czasu na blogu: http://www.webkrytyk.pl/krytyka/my-truth-about-angular-js/ (są tam linki do odpowiednich artków, warto poczytać). Zamiast niego raczej wolę Bacbkone'a czy Taunusa (https://github.com/taunus/taunus), ale on to już rozwiązanie full-stack, genialne na tzw. middleend (czy "new frontend", jak to mawia Zakas): http://www.nczonline.net/blog/2013/10/07/n...-web-front-end/ i doskonały wstęp do izomorficznych web-apps: http://isomorphic.net/

Jednak narzędzia do testowania stworzone przez Angular team, czyli Karma czy Protractor, są genialne i przyjemnie się ich używa (osobiście karmę używam z mocha), jednak ciekawie zapowiada się też praktykant: https://theintern.github.io/

Natomiast React.js jest bardzo dobry pod warunkiem, że stosujemy go tylko i wyłącznie jako view, nie kombinując z żadnymi "inline CSS-ami" i innymi dziwactwami: https://www.pandastrike.com/posts/20150311-react-bad-idea
No i jego wydajność to w dużej mierze mit: http://blog.500tech.com/is-reactjs-fast/ https://aerotwist.com/blog/react-plus-perfo...ce-equals-what/

Przy underscore.js warto od razu polecić lodash.js, który do niektórych projektów może okazać się lepszy.

Zamiast jQuery - zepto albo jeden z http://microjs.com/ (sieć idzie w stronę modularności, nie monolityczności - stąd jQuery jest już ciut przestarzały konceptualnie). Poleciłbym Better DOM (https://github.com/chemerisuk/better-dom) lub fastDOM (https://github.com/wilsonpage/fastdom czyli asynchroniczny DOM, a więc bezpośrednia konkurencja dla Virtual DOM Reacta bez niepotrzebnych udziwnień)

bower obecnie przegrywa na rzecz npm (np. jQuery przeszło na npm w pełni), a npm w niektórych projektach - na rzecz jspm

grunt przegrał na rzecz gulpa, gdyż brakuje mu streamingu i szybkości. Osobiście jednak wolę grunta z powodu jego podejścia (configuration over code).

webpack to nowy require.js, ale i tak wkrótce może wymrzeć, bo nadchodzi System.js i moduły w ES6. webpack + browserify to raczej sposób na przerzucenie kodu server-side na klienta i przyda się zwłaszcza w aplikacjach izomorficznych. Osobiście używałbym go obecnie do generowania modułów UMD, zamiast do wymuszania obsługi modułów CJS po stronie przeglądarki (asynchroniczność AMD wciąż jest tu górą): http://addyosmani.com/writing-modular-js/

Ten post edytował Comandeer 6.08.2015, 12:53:44

@up angularjs architektura nie jest najlepsza i do najszybszych nie nalezy ale jak sie go pozna to pisanie w nim to przyjemnosc

Ten post edytował marcio 6.08.2015, 13:37:42

@marcio znam, pisałem i straciłem połowę włosów Mieszanie logiki aplikacji z HTML? Sorry, ale nie. Wolę czyste rozwiązania, gdzie logika jest tam, gdzie była od zawsze (czyli w kodzie JS), a HTML jest tym, czym był: widokiem ("skompilowanym", bo trzeba zaznaczyć, że Angular.js traktuje HTML jako szablon, co właśnie powoduje to, że nie jest tak szybki, jak mógłby być). Stąd wolę tradycyjnego Bacbkone'a czy izomorficznego Taunusa.

Jak się tak bardzo uwielbia rozwiązania deklaratywne, to są jeszcze Web Components: http://jonrimmer.github.io/are-we-componentized-yet/ ? co prawda wsadzenie logiki w nie też nie jest rozsądne (router na tagach HTML? żądania Ajaksowe tagiem?), ale stworzenie GUI złożonego z niezależnych komponentów, które komunikują się między sobą eventami pozwala na bardzo dużo (IMO więcej niż React + Flux): http://www.slideshare.net/nzakas/scalable-...on-architecture + wszystko jest oparte na otwartym standardzie. Oczywiście jest do tego framework (http://polymer-project.org), najlepszy (bo de facto jedyny ), ale przy którym też mi się kilka rzeczy nie podoba. Niemniej jeśli miałbym do wyboru Angular.js + React.js i WC to poszedłbym w stronę Polymer/czyste WC + eventowy trzon jak u Zakasa.

Ten post edytował Comandeer 6.08.2015, 13:47:51

Inline css to nie dziwactwo. React proponuje lepszy DSL do styli po prostu. Patrz dokąd można to pociągnąć: https://github.com/noprompt/garden o wiele lepsze do aplikacji niż CSS, który został stworzony z myślą o dokumentach.
Porównywanie frameworka do vanilla js, no lol. React jest wydajny w tym co robi a przede wszystkim o to chodzi - widok jest funkcją danych, a nie jakieś mambo-jumbo lokalnego stanu w stylu mvc.


lodash w wersji fp, albo w ogóle lepiej ramda.js. Auto-currying, kolekcje jako ostatni argument, lepsze sygnatury metod, wsparcie dla transducerów i immutable.js.



zepto to nie jest lepsze jQuery, to ejst jQuery bez martwienia się o edge case'y starych przeglądarek. Twórcy jQuery sami mówili, że ich celem ejst, by ich projekt stał się niepotrzebny.



Wszystko zależy od punktu siedzenia. Obiektowość jest świetna w JS, nie ma po prostu bzdur w stylu klas i interfejsów - są za protokoły metaobiektowe (np. popatrz tu: http://raganwald.com/2014/04/10/mixins-for...elegation.html)

To, co podałeś nie generuje inline CSS tylko zwykły CSS - zupełnie inna bestia. A w React obecnie się zastanawiają jak dodać obsługę :hover do generowanych komponentów, bo wsadzenie wszystkiego w atrybut [style] powoduje więcej problemów niż je rozwiązuje. Polecam spojrzeć tutaj: https://css-tricks.com/the-debate-around-do...ed-css-anymore/

Idąc takim tokiem myślenia dochodzimy do GSS: http://gridstylesheets.org

Owszem, CSS ma problemy, ale React ich nie rozwiązuje, tylko udaje, że ich nie ma, zastępując CSS JS-em. Czyli najgorsze, co można zrobić.

Zepto to lepsze jQuery, bo nie ma w sobie tego crapu, co on

Co do bzdurności interfejsów - owszem, nie są potrzebne w JS, ale czy są bzdurne? Dywagowałbym

Ten post edytował Comandeer 6.08.2015, 15:29:14

No i wlasnie tego mi brakuje niby jest ES6 ale jakos tego nie potrafie opanowac, skladnia dziwna i tryb myslenia takze (no byc moze moj jest dziwny zalezy z ktorej strony na to patrzec)

Ogolnie w pracy napisalsmy aplikacje cluster tool ktora jest ogolnie mega filtrem na dane z okolo 10 stron, filtry tworzone sa na podstawie drzewa i sa dynamiczne no i teraz jak skonczylem pisac aplikacje mobilna za pomoca ionic framework (angularjs) i jako ze mi dobrze poszlo to powiedzieli zebym przepisal wszystko do angular-a bo react sie do tego nie nadawal, w angularjs za pomoca modelow drzewo moglem tworzyc na podstawie samego formularza.

Właśnie nie. Jeśli statycznie jesteś w stanie opisać style cssa to możesz je wygenerować na podstawie drzewa komponentów i dodać do strony. Celem tego wszystkiego jest możliwość manipulacji wartościami cssowymi w kontekście. Żeby nie być przywiązanym do emów, procentów i innych takich rzeczy. Wtedy constraint based layouty są proste. Gdzieś facebook pokazywał jak chce opisywać komponenty cssem - jakaś wariacja jsxa. garden używają teraz już om (wrapper do reacta). Pozwala manipulować stylami tam gdzie się powinno to robić - w obrębie jednostki logicznej a nie ze względu na rodzaj technologii.


Tak samo mogę powiedzieć, że na najnowszych przeglądarkach tylko pracuję, więc nie potrzebuję całego crapu jakim jest zepto.


Są lepsze alternatywy niż interfejsy - bardziej dynamiczne - protokoły, bardziej typowane - type class'y.


Filtr to funkcja, funkcje się ładnie komponuje, przekazuje etc. Nie potrzeba żadnych obiektów do tego. Tym bardziej klas.

Witam w klubie


Tak, w React style są przekazywane jako POJO i to nawet nie jest takie głupie (swego czasu Absurd.js mnie urzekł ), ale to, co z tymi stylami jest później robione to już nie jest fajne. Bardziej bym już szedł w kierunku ICSS: https://github.com/css-modules/icss ale IMO to też przerost formy nad treścią.

Jasne, doskonale zdaję sobie sprawę z tego, że przy tworzeniu Sieci opartej na komponentach style powinny być powiązane z konkretnym komponentem i nie istnieć w globalnym scope. Ale da się to zrobić bez urzynania wszystkich korzyści, jakie daje CSS, sprowadzając go do atrybutu [style] - style[scoped], Shadow DOM, BEM itd. Na chwilę obecną daje to o wiele więcej możliwości niż to, co proponuje React: https://speakerdeck.com/vjeux/react-css-in-js

Nie twierdzę, że problem, na który zwrócił uwagę React nie istnieje - twierdzę, że próbuje się go rozwiązać od tyłka strony. Ja bym raczej szedł właśnie w architekturę BEM (kurka, muszę wreszcie to spisać jako artykuł ) i/lub Web Components. Tym samym można operować na stylach w obrębie danej jednostki logicznej I używanej technologii

Co do constraint based layouts: jeśli chce się użyć komponentu w szerszym kontekście, to i tak się nie uniknie potrzeby jego dostosowania do reszty pod względem wymiarów. Zostawienie tego JS-owi czasami jest bardziej kłopotliwe niż zrobienie tego od razu w CSS.

To znaczy rozwin mysl.Jest funkcja ale tworzy json po stronie przegladarki i potem wysyla go do backend-u ktory odpytuje bazy danych i potem filtruje dane i mi je zwraca, wszystko dziala w tle gearman + polling.Filtr np moze wygladac tak:

Ale to taki najmniej skomplikowany

Atakujesz chochoła, nieskończoną eksperymentalną implementację. Ani bem, ani komponenty też nie pozwolą operować na stylach - będziesz uwiązany do hacków z cssa. Rozwiązanie reacta (które zostało zainspirowane innymi) pozwoli kompilować property ogólnie dotyczące stylu, z zachowaniem semantyki JSa do CSS. Dokładnie to, co robiły najpierw templaty i teraz react z htmlem. Jeśli mam uzależnić coś od pozostałych styli to wolę to napisać explicite i w sposób deklaratywny a nie liczyć na nowe funkcje w css. Do tego mogę mieć wynikowy css bardziej optymalny a przede wszystkim lepiej wyscopowany. To czy wynik będzie w inline czy skompilowanym jednym pliku per strona to sprawa wtórna.

No właśnie nie jest, bo style inline nie mają żadnych możliwości CSS-a de facto i odpadają np. kombinowania z pseudoelementami czy pseudoklasami i tym podobnymi. Stąd twierdzę, że CSS powinien zostać w CSS-ie. Inaczej piszemy w JS to, co istnieje natywnie od 15 lat. IMO nie tędy droga.

Nie rozumiem za bardzo czemu BEM czy komponenty nie mają mi umożliwić operowania na stylach? Tym bardziej nie rozumiem przeświadczenia, że CSS musi być uruchamiany w środowisku semantycznym JS-a. Wciąż stoję na stanowisku, że powinien istnieć ścisły decoupling tych dwóch.

Tak, Web Components są eksperymentalne - w lisku W Chrome jest to już ustabilizowana technologia.

Na podobnym stanowisku stali wszyscy przeciwnicy szablonów htmla i wszystkich pochodnych. Stylem trzeba manipulować w aplikacji. CSS ze swoimi ubogimi selektorami i protezami w postaci procentów, emów i calca nadaje się do dokumentów a nie do aplikacji.

Co rozumiesz pod pojęciem "szablonów HTML-a"? Bo jeśli Twiga czy wąsy, to prawdę mówiąc nie rozumiem oburzenia na CSS. Jeśli natomiast coś, co robi Angular (HTML jako widok i szablon równocześnie), to jestem tego przeciwnikiem.

A teraz inaczej: a co Ci daje wygenerowanie stylów inline przez Reacta, jak nie super ubogą protezę, która nawet nie umie reagować na takie zdarzenia jak :hover? Rozwiązujemy jeden problem, wpakowując się od razu w kolejny.

Tak, style powinny być dołączane do komponentów, ale IMO jako CSS, bo to daje największe możliwości na chwilę obecną. I czy ja wiem czy em itd są takimi protezami? https://css-tricks.com/rems-ems/ → każdy moduł się ładnie skaluje samodzielnie do całego systemu, równocześnie pozostając de facto autonomicznym. I zanim mi powiesz, że to jest strona a nie aplikacja: a czym się różni strona od aplikacji na poziomie GUI? Bo jak dla mnie niczym - to wciąż HTML + CSS. W aplikacji jedynie mamy do tego potężną logikę w JS.

Wydaje mi się, że dyskutujemy na całkowicie dwóch różnych poziomach. Ty mówisz jakie problemy próbuje rozwiązać React (i co do tego jakie to są problemy się zgadzam, natomiast nie zgadzam się ze sposobem ich rozwiązania, mimo wszystko upatrując rozwiązania w WC), ja mówię o tym jakie problemy wprowadza rozwiązanie Reacta. Mam równocześnie wrażenie, że Ty mówisz to jednak bardziej z pozycji backendowca, ja z "mocnego frontu".

Ano, backendowiec, który wrzuca projekty w clojurescripcie. Serio, pozostań przy śledzeniu blogów o tym czy em już jest ok czy nie, kiedy i gdzie będzie calc i co będzie potrafił robić. Te wszystkie problemy zostały już rozwiązane w innych technologiach, to Ty się upierasz, że należy je rozwiązywać technologią nieprzystosowaną do tego. Style w reactie mogą być aplikowane inline tak jak może być wygenerowany styl dla strony - wiem bo tak robię za pomocą gardena i reagenta. Mogę mieć hover czy cokolwiek innego dziwnego z cssa. Jedynie względem reacta mam nadmiarowe style, bo mam dla wszystkich komponentów możliwych do wystąpienia (co i tak jest małą liczbą w porównaniu do ogólnych praktyk, gdzie cssa masz tyle ile będzie potrzeba na wszystkich stronach razem). Mogę stylem dowolnie manipulować, niezależnie od implementacji przeglądarek. Mogę zrobić autolayout, mogę dobierać wymiary zależnie od stanu, mogę kolorować w dowolny sposób bez obkładania się tysiącem selektorów albo tricków w postaci :nth-last-child(n+3), etc. Przede wszystkim, styl może być zależny od danych, bez nadmiarowego kodu. Serio, to jest handlebars/mustashe po raz kolejny. Tak jak wtedy 'mocni frontendowcy' musieli napisać swój pierwszy {{#list tak teraz, muszą napisać swój pierwszy autolayout. I apropo mocnego frontu jeszcze - w clojurescripcie robimy to jeszcze lepiej. Nie mówiąc o templateach, to robimy o wiele lepiej.

@solificati ale to wszystko, o czym mówisz już jest… A generowanie CSS-a do komponentów i tak odbywa się przez preprocesory.

calc działa wszędzie od kilku lat, em był dobry od zawsze (obadałeś to demo co posłałem?)

Ale te wszystkie technologie jedyne, co robią, to odsuwają od Ciebie generowanie CSS-a, który i tak zostanie wygenerowany. Przesuwasz problem na wyższy poziom abstrakcji, nic więcej. I prawdę mówiąc czasami przez ten wyższy poziom abstrakcji frontendowcy mają problem na niższych poziomach.

Ale domyślne zalecenia FB wskazują na generowanie stylów inline: https://facebook.github.io/react/tips/inline-styles.html Dobudowanie ekosystemu do Reacta to już inna bajka. Jeśli będzie się go traktować jedynie jako view, to wówczas jest to rozwiązanie niezwykle przyjemne.

No faktycznie, tak jest w CSS-ie… z roku 2010 Na szczęście mamy rok 2015 i każda podstrona/komponent serwują tylko te style, które są im potrzebne, a reszta jest choćby zasysana asyncem

Możesz, ale ostatecznie i tak może się okazać, że apka nie działa, bo generator nie wziął pod uwagę, że Chrome 432 nie ma hologram-density. To jest po prostu przeniesienie problemu o jeden poziom abstrakcji wyżej. Zresztą - też se mogę dowolnie manipulować stylem dołączonym do WC. Mogę też używać preprocesorów, co czasami da mi większe możliwości niźli generowanie tego przy pomocy garden.

To samo mogę osiągnąć w BEM + Stylus czy sterując stanem przy pomocy JS. A :nth-last-child(n+3) nie użyłem dotąd nigdy - oprócz prezentacji na temat możliwości współczesnego CSS-a Dzięki spłaszczonej strukturze BEM jestem w stanie generować super wydajne selektory CSS.

No i dalej to osiągnę w BEM. Być może będzie ciut więcej kodu CSS niż u Ciebie, ale efekt ostateczny będzie taki sam.

Ale kosztem złamania zasady SRP de facto i przy przemieszaniu warstw aplikacji.

To bardzo dziwne, bo mam ochotę powiedzieć, że w BEM + PE robimy to jeszcze lepiej. O wiele lepiej

Myślę, że nie ma sensu tego kontynuować, bo stoimy na dwóch skrajnie różnych stanowiskach, których zgodzić się po prostu nie da. A kto miał rację - niech osądzi historia

Ten post edytował Comandeer 6.08.2015, 21:36:03

mrc to do czego platforma powstaje nie ma znaczenia, wystarczy spojrzeć na to że chociażby masz edytor Brakets stworzony w node jako aplikacja desktopowa.
Albo inny przykład C# powstał jako MSowy pomysł na Jave, po przegraniu z Sun. A używany jest np do tworzenia gier. Albo mamy czasy HTML5 to powstały silniki do gier w js.

aniolekx źle zrozumiałeś kompletnie to co napisał buliq

W node powstała masa modułow których potem używasz na client-site po upakowaniu ich przez jakiegoś gulpa/grunta czy webpacka. Node jako server site aż sie tak bardzo nie spopularyzował bo do tego musisz mieć odpowiednie serwery potem a nie shared za 10 zł.

mrc albo nie pracujesz w froncie albo zatrzymałeś się parę lat wstecz pod względem automatyzacji środowiska pracy. Bo gulp/grunt/webpack to podstawowe narzędzia frontedowca 2k15 r Prócz tego oczywiście masa innych, ale o tego zaczyna się obecnie projekty.

Ten post edytował com 6.08.2015, 22:17:29

heh, taki dziwny offtopick powstal, zderzenie backendowcow z frontendowcami byc moze autor watku wyciagnie dla siebie jakies ciekawe informacje

Ten post edytował aniolekx 7.08.2015, 08:20:02

@com

Jestem backendowcem Nie używam środowisk automatyzacji frontu 2k15