Witam,

strony internetowe projektuję profesjonalnie już dobre 3 lata. Uważam, że PHP, JS, Jquery, HTML, CSS ogarniam na poziomie zaawansowanym. Pytanie co dalej?

Nie ukrywam, że zanim wezmę się za C++/C# ( podstawy już mam, doświadczenia w kodowaniu - zero ) chciałbym się jeszcze trochę rozwinąć aby mieć na czym dorabiać zanim nauczę się innych języków oraz aby nie zostać z technologią w tyle.

Stąd moje pierwsze pytanie, mianowicie w jakim celu są wykorzystywane technologie AngularJS, ASP.NET, Node.js itd. itp.? Przeglądając oferty pracy programisty front-end'u często się z tymi terminologiami spotykam, jednakże przeglądając kursy, nie widzę miejsca w którym mógłbym je zastosować. Oczywiście tych bibliotek chociażby JS'owych jest o wiele więcej.

Znajdzie się miła duszyczka które pomoże rozwiać wątpliwości w jakim kierunku się rozwijać i czy ma to w ogóle sens? ( zakładam, że ma, dlatego napisałem ten post )

Pozdrawiam,
Daniel Galas

node.js jest de facto obecnie podstawą frontendu, gdyż pod niego są de facto napisane wszystkie narzędzia: grunt, gulp, bower, npm, yeoman, Stylus, LESS itd. Nawet jak się nie lubi JS-a i pokrewnych to to niestety must-have

Mógłbyś wytłumaczyć co miałeś na myśli? Tak pytam, bo nodejs to server-side, więc z frontendem ma niewiele wspólnego.

Przecież napisał, wszystkie narzędzia używane podczas produkcji frontu w Angrular/Ember/inne są napisane pod node.js

Ember, Angular -> client side
node,js -> server side.

Wiec w przypadku Ember i Angular po stronie servera mozesz miec cokolwiek, nawet php.

Ale node.js to platforma, język cały czas ten sam. Sugerujecie, że trzeba znać szczegóły paltformy, z której się korzysta? Przed zaincludowaniem imagemagick robicie kurs C?

Zacznijmy od tego, że twierdzenie, że node.js to server-side jest bzdurą. Node-js jest środowiskiem uruchomieniowym JS poza przeglądarką. Tylko tyle i aż tyle. Nie musi być wykorzystywany do tworzenia rozwiązań server-side i często nie jest. Obecnie częściej widuję node.js w konsoli niźli na serwerze.

Wszystkie menagery pakietów dla JS są pisane jako moduły node. Tak samo jak LESS czy Stylus. Tak samo jak super przyjemne build systems takie jak gulp czy grunt. Polecam zobaczyć jakikolwiek większy projekt frontowy - build tam leci przez grunta albo gulpa: Bootstrap, MDL, Foundation… chyba nawet H5BP ostatnio na to przeszło.

Tak, wypada znać jak działa node.js, bo duża jego część (np system modułów) jest oparta na standardzie CommonJS, który jest wykorzystywany także po stronie przeglądarki i wypiera takie rozwiązania jak AMD czy UMD. Poza tym żeby użyć choćby gulpa trzeba znać podstawowe metody pracy z node i ogarniać choćby npm. A reszta to jest już czysty async JS, więc tutaj to średnio jest co ogarniać - wszak frontdev JS zna

ok, poza przegladarka i nie serwer to gdzie?

Comandeer, ale ty bzdury piszesz.

No wiesz... to samo możesz powiedzieć o php.


W konsoli u programistów.

@aniolekx no napisałem - w konsoli. Ale node w połączeniu z Chromium jest także silnikiem dla aplikacji desktopowych (nw.js czy Electron).
@Tuminure - można
@mrc, patrz 4 lata już pisuję w node i nie zauważyłem, że go źle używam… Skoro już napisałeś taką merytoryczną wypowiedź, to może ją ciut rozwiniesz i mnie oświecisz?

Comandeer: Node został stworzony z myślą o server-side, a to że używasz go inaczej to już Twoja sprawa. To, że piszesz już 4 lata, może również potwierdzać Twoją głupotę, bo używasz narzędzia niezgodnie z jego przeznaczeniem. Druga strona jest taka: jeżeli jest Ci wygodnie w tym pisać, to sobie pisz. Ale nie wypisuj tutaj takich bredni, że node nie jest stworzony do server-side, bo żal mi się robi Ciebie, a forum szkoda, że takie trolle-dzieciaki tutaj mogą dodawać posty.

Edit:

A tutaj możesz zobaczyć, że twórcy nawet w about piszą o tym, że node jest stworzony do apek webowych, a główny przykład to właśnie server-side:
https://nodejs.org/about/

@mrc czyli mówisz, że całe środowisko JS się myli? Dlatego też gulp i grunt są debilnymi pomysłami? Tak samo zatem są bezsensowne wszelkie aplikacje PHP-owe odpalane z konsoli (composer, anyone?) - dokładnie taka sama zasada…

To, że twierdzisz, że node nie jest przystosowany do innych zastosowań niż server-side (które, owszem, było głównym celem tego narzędzia) świadczy jedynie, że nigdy nie napisałeś w nim nic większego…

I nie życzę sobie nazywania mnie trollem-dzieciakiem, bo ani nie trolluję, ani nie jestem dzieciakiem. Natomiast Ty non stop próbujesz mnie obrazić - już raz mi zarzucałeś, że trolluję, by ściągnąć ludzi na swoje forum (którego nota bene nie mam), co jest czystym absurdem.

hmmm konsola, a ja myslalem ze to tylko rodzaj interfejsu dla programisty aby komunikowac sie z serwerem, a tu sie okazuje se to jakis osobny byt

@aniolekx no całkowicie osobny. Po co Ci na serwerze preprocesor CSS? Takie rzeczy robi się też w konsoli, ale na komputerze programisty

@aniolekx i @reszta

Nie ma co z chłopakiem dyskutować. Niech pisze sobie co chce, i tak nic mądrego z tego nie wyjdzie. Rozwaliliśmy kolejny temat, w którym ktoś pytał o zupełnie co innego.

Jak tu nie mówić o trolowaniu?

@mrc, bądź bardziej otwarty na nowe rozwiązania. Sam zobacz: http://electron.atom.io/#built-on-electron, nawet Microsoft zaczął interesować się tą technologią (polecam przetestować). To, że coś zostało zaprojektowaną z myślą o rozwiązaniu A, a spisuje się równie świetnie w rozwiązaniu B wcale go nie dyskwalifikuje (wręcz przeciwnie).
Developerzy dostrzegli duży potencjał i łatwość w projektowaniu interfejsu w HTML/CSS (chyba zaczęło się to od gier komputerowych?). W samym JS (ECMAScript 6) zaczyna się pojawiać (oczywiście małymi krokami) obiektowość z prawdziwego zdarzenia. Moim zdaniem minie jeszcze trochę lat zanim ta technologia wejdzie do powszechnego użytku, ale ma duży potencjał.

IMO obiektowość w JS była od zawsze - prototypy - i w sumie ES6 tego nie zmienia. Dodaje na to jedynie lukier składniowy w postaci klas. Jedyna duża zmiana to możliwość rozszerzenia natywnych klas: Array itd (było to wcześniej możliwe, ale nie w pełni, np nie działały automatyczne liczniki liczby elementów tablicy).

ES6 upodabnia JS do innych języków - mnie akurat średnio się to podoba (jestem konserwatystą JS-owym ), ale część zmian faktycznie jest genialna. Po stronie serwera i w programach desktopowych/konsolowych można to używać (dzięki io.js, czyli forkowi node.js, który… ma być nową wersją node - nie, wcale to nie jest zagmatwane ), w przeglądarkach jeszcze nie, dopóki nie wymrze IE < Edge (mam nadzieję, że nikt się nie obrazi za taki zapis).

Ale przecież @Comandeer ma rację i nawet dając linka do electron to potwierdziłeś:

[HTML] pobierz, plaintext 
npm install electron-prebuilt -g
[HTML] pobierz, plaintext 

Dokładnie o tym jest przecież mowa. A ES6 i jego "obiektowość" to póki co zabawka. ES7 ma być w tym zakresie trochę bardziej rozbudowany.

No tak obiektowosc w js troche kuleje przynamniej dla mnie nigdy z nim nie mialem wiele wspolnego od 3 miesiecy pracuje i praktycznie z back-end-em nie mialem poki co nic wspolnego i zajmuje sie front-endem z technologi ktore polecam ci sie nauczyc to:
jquery - jesli chcesz zarzadzac DOM-em
angularjs + angular ui (bootstrap dla angularjs) - jesli chcesz pisac fajne aplikacje webowe CRUD
react - przydatne i o wiele szybsze niz angularjs ale zalezy tez do czego trzeba uzyc
underscore.js - zbior przydatnych funkcji

No i obsluga przynajmniej bower na poziome tak jak potrafisz uzywac composer-a do instalowania pakietow i zaleznosci.

Potem gulp/grunt czy tam webpack to wisienki na torcie sam musze opanowac

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/

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

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

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

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

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.

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

@com

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