Zbyt szybki rozwój technologi wokół JavaScript

8

Celowo nie napisałem o szybkim rozwoju samego języka, bo fajnie, że język ewoluuje. Powstaje jednak taka masa bibliotek, frameworków, rozwiązań, że człowiek nie idzie nadążyć. To jest nie do opanowania ;)

Na ubuntu, chcąc zainstalować node.js (apt-get install nodejs), instaluje się wersja - bodajże 0.10. Natomiast już jest node.js w wersji 7. Szaleństwo.

Do napisania tego wątku skłoniła mnie walka z webpackiem. Mam webpacka + gulp + bootstrapa. Do tego jeszcze potrzebowałem babela aby skonwertować kod ES6. Instalowałem to poprzez npm i zajęło mi to ponad 100 MB! Po udanej walce, udało się webpackowi "wyprodukować" wyjściowy plik JS. Niestety na IE11 nie działa, bo krzyczy, że nie rozpoznano Promises. Babel nie radzi sobie z z tym. Znalazłem wiele różniących się rozwiązań tego problemu, ale żadne nie działało. Podejrzewam, że dlatego iż miały one kilka miesięcy, a od tego czasu wydano kilka nowych wersji różnych pakietów, które są ze sobą niekompatybilne :| Okazało się, że trzeba doinstalować jeszcze jeden pakiet - babel-polyfill, następnie dołączyć import 'core-js/fn/promise'; na samej górze pliku JS. Pomijam, że plik wynikowy staje się przez to większy, ważne, że działa. Uff.

Testy akceptacyjne się teraz wysypują, PhantomJS rzuca błędami JS (na Chrome czy FF jest ok). Po wielu godzinach okazuje, że się, że trzeba importować jeszcze jeden moduł: import 'core-js/modules/es6.function.bind';.

Jednym słowem: mordęga. Jak tu napisać - np. w node.js jakąś aplikację. skoro za kilka miesięcy zostaną wydane nowe wersje pakietów, niekompatybilne ze sobą. Utrzymywanie takiego softu jest bardzo ciężko.

Cóż, kończę już te gorzkie żale... jestem ciekaw Waszych opinii co do JavaScript, Node, szybkiego rozwoju, niekompatybilności itp...

13

Co do Node'a:

  • dystrybucje linuksa mają przestarzałe wersje, z czego to wynika - nie wiem (być może dużo tooli linuksowych jest oparte o te wersje),
  • Node stosunkowo niedawno przeszło na SemVer i połaczyło się z io.js, stąd ten dziwny przeskok z 0.1x na 4.x.x+. Obie te rzeczy są dobrą zmianą - dwa konkurencyjne projekty zostały połączone, a nzawy wersji wreszcie coś mówią (ostatnio ludzie panikowali bo Angular też przeszedł na SemVer i się dziwili, że planują już ng3 i ng4 ;) )
  • Node ma jasny plan wydawniczy i wersje LTS wspierane 3 lata
  • z racji SemVer każda najmniejsza zmiana łamiaca kompatybilność wsteczną wymusz nowy numerek z przodu, patrząc na zmiany między Node6 a Node7 to większość dotyczy rzeczy których zwykle nie używam, więc nie jest źle - najczęściej używane API jest raczej stałe,
  • tu więcej o wersjonowaniu Node'a: https://medium.com/@nodesource/node-js-is-semver-8b3938ae8d24#.vvl406yyo

Co do Webpacka, Babela itp:

  • w Node nie jest to wielki problem, na backendzie nie używasz Webpacka (no chyba, że robisz SSR, wtedy sie przydaje), właściwie to transpilacja ES6 i ES7 w aktualnych wersjach nie jest potrzebna, ja u siebie stosuję dokładnie jeden plugin transpilujący ES6 modules na Common.js,
  • jak potrzebujesz odpalić nowoczesny kod na starszej wersji Node'a to dodajesz presety i babel-polyfill - tu nie trzeba dbać o rozmiar plików, więc nie ma potrzeby zaciągać pojedynczych polyfilli,
  • jeśli chodzi o środowisko przeglądarki to tu mamy nowy-stary problem, podobny do tego, który rozwiązywało kiedyś jQuery - nie jest to wina języka czy narzędzi, tylko róznic w przeglądarkach - o ile na serwerze możesz sobie wymienić wersję Node'a, to nie zmusisz użytkowników do uzywania tylko najnowszego Chroma. Narzędzia jak Webpack starają się rozwiazać ten i inne problemy, być może nie są idealne (na pewno nie są), ale zmiany (które na pewno nadejdą) kłócą się z Twoją awersją do nowych narzędzi ;) Podsumowując - narzędzia te powstają i ewoluują z powodu rozwoju języka, który jak sam piszesz jest dobrą rzeczą.
  • rule of thumb dla Babela: jak chcesz zrobić transformację kodu z nowej składni to dodajesz pluginy lub całe presety w zależności od potrzeb, jak chcesz dodać brakujące biblioteki dla starych przeglądarek to uzywasz polyfilli, wg mnie jasny podział. Modularność Babela jest zaletą, bo rozmiar bundla jest bardzo istotny. W sumie trzeba było zacząć od strony https://babeljs.io/ - tam masz zawsze aktualną dokumentację (choć mogłaby być lepsza) ;) W szczególności, jeśli masz wątpliwości czy dana rzecz to transpilacja czy nowa funkcja, możesz spojrzeć na listę pluginów presetów: https://babeljs.io/docs/plugins/preset-es2015/ od razu wszystko jasne - nie ma promisów na liscie? -> trzeba dodać polyfill (lub nie, zalezy jakie przeglądarki obsługujesz -> https://kangax.github.io/compat-table/es6/ ) - nie musisz czekać na błedy w runtime.

Co do Frameworków:

  • na froncie "standardem" jest Angular i React (no i jQuery, choć traci na znaczeniu), "dziesięć nowych frameworków na tydzień" nie jest wg mnie niczym złym - nikt ni każe ich stosować, a jest szansa, że część z nich wypromuje nowe, lepsze rozwiązania (też nieobowiązkowe w stosowaniu),
  • na backendzie jest podobnie - większość stoi na Expressie.

Co do rozmiarów plików:

  • rozmiar dev-dependencies nie ma większego znaczenia, miejsce na hdd do żeden problem obecnie,
  • rozmiar bundli - no cóż, jak korzystasz z nowych funkcji i chcesz to odpalić na starych przeglądarkach to cudów nie ma - trzeba te funkcje dodać, gdyby Babel nie wymagał polyfilli tylko sam je doklejał podczas transpilacji nie zmniejszyłoby to rozmiaru bundla.

Co do task-runnerów typu Grunt, Gulp:

  • nie używaj ich - to dodatkowa, niepotrzebna warstwa abstrakcji (w dodatku leaky abstraction), wystarczą Ci npm scripts - używasz tooli bezpośrednio, masz największy wybór, najaktualniejsze wersje i pewność, że zadziała.

Co do pakietów:

  • no tu niestety częściowo wychodzi brak obszernej biblioteki standardowej JSa, choć ona też rosnie powoli,
  • liczba pakietów na npmie jest ogromna, co nie znaczy, że trzeba zaciągać paczkę do wszystkiego, często lepiej napisać sobie helper (ja tylko lodasha i moment.js traktuję jako takie rozszerzenie biblioteki standardowej - przy reszcie się trzy razy zastanawiam),
  • dla libek które warto zaimportować pisz adaptery - wtedy zmiany nie są Ci tak straszne - w razie problemu przerabiasz tylko adapter, nie całą apkę,
  • zwracaj uwagę na to czy biblioteka używa SemVer, ma plan wydawniczy, ile osób ją maintainuje, ile ma gwiazdek, czy ma pełne pokrycie testami.

Fakt faktem - ekosystemowi baaardzo daleko do ideału, może przytłaczać kogoś kto nie wie na co zwracać uwagę, jednak z czasem wszystko się ustandaryzuje, już zaczęło (dla tych co nie podążają za hypem). A gdyby nie ta aktywność społeczności pisalibyśmy SPA w jQuery ;)

Powyższe to raczej lista porad jak sobie radzić z obecnym stanem rzeczy - jak najbardziej rozumiem i nie neguję, że ktoś może mieć trudności.

0

Node jest krótko mówiąc "opasłe" instaluje się mnóstwo niepotrzebnych zależności, do małej apki. ta przelotna moda na Node też raczej przeminie. JavaScript nawet w wersji ES6 nie jest znowu takim pięknym językiem, aby korzystać też z niego po stronie serwera. O wiele lepiej to przemyślano w Django, masz tylko to co potrzebne, bez pobierania multum modułów. Ale fanatyków JS nie brakuje, chyba tylko Ci od Javy im dorównują.

2

Na ubuntu, chcąc zainstalować node.js (apt-get install nodejs), instaluje się wersja - bodajże 0.10. Natomiast już jest node.js w wersji 7. Szaleństwo.
możesz skorzystać z nvm i doinstalowywać oraz zmieniać sobie na poczekaniu wersje Node jak rękawiczki.

Niestety na IE11 nie działa,
problemem jest w takim razie zbyt wolna adaptacja nowych technologii (skoro jeszcze ludzie korzystają z IE11, skoro już jest Edge), a nie zbyt szybki ich rozwój. Ciężko winić JavaScript za długoletnie zaniedbania firmy Microsoft, która dopiero od niedawna zaczęła nadążać za standardami webowymi.

1

@Maciej Cąderek: dzięki za obszerny post. Po przespanej nocy trochę ochłonąłem, poczytałem i pewne rzeczy się rozjaśniły. Po prostu ciężko nadgonić za rozwojem technologii jeżeli nie jest się na bieżąco. Wiadomo - jeżeli chcemy być na czasie (w obojętnie jakiej technologii), to cały czas trzeba się edukować; mam jednak wrażenie, że za JS po prostu nie nadążam ;)

Webpacka używam po stronie klienta. gulp watch natomiast do rzeczy pobocznych - np. konwersja SASS => CSS. Pewnie samym webpackiem też da się to osiągnąć.

Wcześniej używałem Gulp + babel i było to po prostu prostsze. Ale coś za coś: teraz chciałem skorzystać z dobrodziejstwa webpacka, tak więc używam require.ensure() i pewnie webpack gdzieś w pliku wynikowym "wypluł" użycie Promise. Jak się domyślam, babel bez polyfill nie był w stanie zamienić tego, stąd IE11 wyrzucał błąd. Wszystko układa się w całość :)

2

@Adam Boduch: nikt nie nadąża. Ja nie nadążam, @Maciej Cąderek nie nadąża, @LukeJL nie nadąża. To normalne.

Why I’m Thankful for JS Fatigue. I know you’re sick of those words, but this is different.:

From this point going forward, no single human being is ever going to have a completely full grasp of every corner of JavaScript, CSS, and Web APIs. Nobody is ever going to know everything there is to know about modern web architecture, Node, GraphQL, SQL, NoSQL, async control flows, functional programming, build pipeline tools, debuggers, memory profilers, paint profilers, flame graphs, React, Angular 2, TypeScript, Redux, ngrx/store, RxJS, Axios, Webpack, Browserify, Elm, Clojure, and every other exciting, scary, new, hipster Haskell thing that exists in the web dev world today.
**It’s never going to happen. I can’t keep up. Dan Abramov isn’t keeping up. Brendan Eich isn’t keeping up. Don’t stress out because you can’t, either. **

Jeżeli chodzi o naukę samego webpacka to mi bardzo pomogło:

  • przeczytanie dokumentacji i komentarzy pod dokumentacją. Webpack 2 już ma lepszą dokumentację.
  • przeczytanie książki Become a Webpack master. Mozna ją dobrowolnie kupić, albo przeczytać w necie za darmo.
0

mam wrażenie, że to po części jest spowodowane utrzymaniem zainteresowania wokół frameworka czy biblioteki, nowa wersja=wizyty,ruch na stronie=ściąganie wersji=rozwój, wąż zjada swój własny ogon

1

@Maciej Cąderek dobrze w sumie zarysował temat. Od siebie dodam, że warto wyrobić sobie nawyk przeglądania twittera/reddita/medium raz dziennie przez pół godziny chociaż. Wtedy przynajmniej człowiek wie, co się dzieje w branży. Może w ten sposób nie ogarniesz wszystkiego, ale przynajmniej w jakimś stopniu "nadgonisz". Pamiętajmy też, że niektóre narzędzia są w zupełności niepotrzebne większości i służą do rozwiązania problemów, których większość ludzi nie ma (ale najwyraźniej trzeba to nadal jak mantrę tłumaczyć, stąd posty np. Abramova o tym, że właściwie to nie potrzebujesz Reduxa). I tu można wymieniać dalej, chociażby Relay, Falcor, RxJS, itd nie dadzą wielkich benefitów w większości przypadków, bo były tworzone z myślą o tych nietrywialnych case'ach, np. efficient data fetching w połączaniu z optimistic updates na mobile, co jest dość skomplikowanym zagadnieniem im głębiem człowiek w to wchodzi. Tak naprawdę środowisko JS-a powoli dojrzewa, ludzie zaczynają wykorzystywać wzorce znane od lat (stąd np. popularyzowanie idei małych komponentów, czy unidirectional architecture), ale pod względem "przełomu" we frontendzie jest tylko kilka wartych wzmianki tworów, reszta to wciąż to samo (btw sama idea małych komponentów w Polsce popularna staje się od 2 lat, na świecie już pisze się tak od ilu? 6, czy nawet 7 lat? - weźmy też na to poprawkę). Nie przesadzajmy z tym szybkim rozwojem. ;) Kolejny etap to pogrzebanie REST-a, u nas jeszcze do tego kawałek, ale u kolegów w Stanach na GraphQLa jest co raz większy hype i nawet spotkałem się już na rozmowie kwalifikacyjnej z tym.

0

popularyzowanie idei małych komponentów

Z małymi komponentami też można przedobrzyć. 100 małych komponentów niekoniecznie będzie lepsze niż 10 średnich.

Moim zdaniem należy dążyć do całościowej prostoty przede wszystkim. Jeśli podzielisz komponenty na jak najmniejsze to owszem komponenty będą prostsze, ale cała aplikacja niekoniecznie stanie się prostsza - bo mniejsze komponenty to często więcej komponentów, a jeśli więcej komponentów to często więcej zależności, więcej przesyłania różnych danych z jednego komponentu do drugiego, więcej zamieszania przy apdejtach widoku itp.

Oczywiście to wszystko zależy - czasami faktycznie małe komponenty dużo uproszczają (i jeśli bym miał wybierać w ciemno między monolitami a małymi komponentami, to wybrałbym małe komponenty jak najbardziej - komponenty-monolity mnie często i gęsto wkurzają), ale jednak też nie jest to wcale takie różowe jak się wydaje. Czasem zgrupowanie czegoś większego w jedną całość pozwala na większą prostotę i transparentność (bo masz wszystko w jednym miejscu a nie podzielone na kilkanaście różnych komponentów, które się ze sobą komunikują).

Wydaje mi się, że dobrze podążać zasadą Keep it simple, stupid - jak coś podzielone na małe komponenty jest proste, czytelne, łatwe w debugowaniu to tam stosować małe - ale jeśli jakiś komponent potrzebuje być większy (np. layout głównego widoku na stronie) i zrobienie go większym wcale nie zmniejszyłoby prostoty, to czemu tak nie zrobić.

1

@LukeJL: sam Facebook rekomenduje podział na jak najmniejsze komponenty i w swojej bazie mają już ponad 20 tysięcy komponentów. ;) Uważam, że wszystko zależy w większości od architektury. Podział na małe komponenty właśnie sprzyja zasadzie KISS, w tym ułatwia znacznie testowanie kodu (nie tylko jednostkowo). To, o czym mówisz to nie problem granulacji samej w sobie, a tego, że ktoś ŹLE te komponenty dzieli, stąd pojawia się tight coupling. Im mniejszy podział, tym generalnie mniejsza reużywalność. Co do Twojego ostatniego pytania to tworzy to niespójną architekturę i takie wyjątki od reguły tworzą w konsekwencji dług publiczny. Wierz mi, byłem w takiej sytuacji. ;) W większych komponentach zawsze pojawia się problem już przy testowaniu. Piszesz 10, 20, może nawet 30 testów do takiego komponentu i okazuje się, że wszystkie są bezużyteczne, bo przy takiej złożoności komponentu jesteś w stanie pominąć 5 krytycznych, z których niech 1 wypali na produkcji, to jesteś w czarnej dupie. No po prostu nie jestem w stanie się z Tobą zgodzić mając na produkcji aplikacje, z których korzysta kilka milionów userów (a i to nie są jeszcze ogromne twory).
Btw żeby była jasność, bo mały, średni, duży to mgliste pojęcia, więc operujmy konkretami: mały komponent to dla mnie taki na max 100 linijek kodu i 10 w przypadku samego JSX. ;) W przypadku containerów, które zwykle nie są przeznaczone do renderingu markupu czasem można to nagiąć, ale zwykle przerośnięte containery to znów lampka ostrzegawcza, że być może jest skopany dostarczony design.

0

Btw żeby była jasność, bo mały, średni, duży to mgliste pojęcia, więc operujmy konkretami: mały komponent to dla mnie taki na max 100 linijek kodu i 10 w przypadku samego JSX.

No to ja jestem bardziej radykalny. Mały komponent to taki, który robi jedną rzecz i który ciężko podzielić na mniejsze. Czyli zwykle pewnie od jednej do około 40 linijek kodu. Generalnie lubię jak najmniejsze komponenty. Jak widzę komponent, co ma 100-200 linijek kodu, to się zastanawiam czy na pewno musi być taki duży (zwykle nie musi).

Jednak to, że lubię małe komponenty nie znaczy to, że nie mam z nich problemów.

@LukeJL: sam Facebook rekomenduje podział na jak najmniejsze komponenty i w swojej bazie mają już ponad 20 tysięcy komponentów

Może to się im sprawdza na produkcji, ale jako developer nie chciałbym musieć ogarniać 20 tysięcy komponentów, bo ogarnięcie takiej bazy kodu byłoby raczej trudne (chociaż Dan Abramov na Twitterze pisał, że mają jakąś przeglądarkę komponentów).

Poza tym sama liczba nic nie mówi - nie wiadomo, czy potrzebują tyle komponentów. Chyba nigdy nie mówili dokładnych powodów, dla których mają tyle komponentów, nie napisali żadnego case study na ten temat. Więc kierowanie się tym to może być trochę jak wybieranie PHP dlatego, że Facebook napisany jest w PHP.

Tylko, że wg mnie problem jest z czym innym trochę - to nie jest kwestia dużo małych vs. mało dużych komponentów, ale o to, czy interfejsy mają być proste czy skomplikowane, czy architektura (nie tylko komponenty, ale cała architektura projektu) jest prosta czy skomplikowana. To z czym mam problem to nie małe komponenty (bo je lubię), tylko raczej hierarchiczna ich struktura, coś w tym stylu:

<A>
   <B/>
       <D>
          <E />
          <E />
              <F />
                 <G/>
                 <G>
                        <H>
                               <I />
                               <I />
                       </H>
                   </G>
          <E />
       </D>
   <C/>
    <G>
       <H/>
       <H/>
    </G>
</A>

z tym mam problem, bo:

  • dużo komponentów - większy ból dla programisty, żeby to ogarnąć wszystko, dużo plików, nie wiadomo co jest od czego zależne w jaki sposób, co się w sobie zawiera (chyba, że firmy korzystają z jakichś sensownych styleguidów). Ale i tak - jeśli tego jest za dużo, to nawet jak będziesz miał narysowany graf zależności, to może być to cięzko ogarnąć.

  • cięzko zapanować na przepływem danych, generuje to albo potrzebę przekazywania danych jawnie przez propsy albo jakąś magię w stylu kontekst czy connect z Reduxa albo przez samodzielne odpytywanie store'ów/innych źródeł danych przez komponenty (tyle, że im więcej magii, tym cięzej zapanować nad wszystkim).

  • więcej komponentów to często głębsza hierarchia, a wtedy cięzej zapanować nad wydajnością, a React potrafi być bardzo powolny przy aktualizowaniu głębokiego drzewa (tu można oczywiście powiedzieć, że to kwestia doświadczenia w React, ale dla mnie konieczność pamiętania co się gdzie aktualizuje na którym poziomie hierarchii i rozkminy czy podłączyć connect z Reduxa na tym poziomie hierarchii czy na innym i pamiętanie o shouldComponentUpdate czy szukać przyczyn dla którego dane poddrzewo się odmontowuje i zamontowuje z powrotem sprawia, że sam React jako biblioteka z połączeniu z Reduxem* stają się dość nieprzyjazne w użytkowaniu). Zastanawiam się jak to będzie w nowej implementacji Reacta, bo coś z tym robią, jakiś Fiber, ale nie wnikałem w to za bardzo.

*wspominam o Reduxie, bo nie znam za bardzo innych rozwiązań fluxowych i nie wiem jak to gdzie indziej jest rozwiązane.

czyli generalnie mam podobne odczucia jak z czystym HTMLem, wolę coś takiego:

<ul>
<li>Abc
<li>Abc
<li>Abc
</ul>

od czegoś takiego:


<div class="wrapper-list">
   <ul class="list-cool">
        <li class="list-cool-item green">
              <div class="content-wrapper-special content-normal blue">
                      <span class="content-letters> 
                                Abc
                     </span> 
              </div>
         </li>
          <li>
          <!-- i tak dalej -->
          </li>
    </ul>
</div>

biblioteki komponentów typu Angular czy React miały w założeniu uprościć markup, a często po prostu spychają go pod dywan oraz dokładają własną zamotaną hierarchię (tyle, że hierarchię abstrakcyjnych komponentów a nie divów).

Nie mam niestety gotowej recepty na problemy, które tu poruszyłem (reużywalność komponentów się przydaje, z drugiej strony jak uniknąć ravioli code http://wiki.c2.com/?RavioliCode ?).

0
LukeJL napisał(a):

No to ja jestem bardziej radykalny. Mały komponent to taki, który robi jedną rzecz i który ciężko podzielić na mniejsze. Czyli zwykle pewnie od jednej do około 40 linijek kodu. Generalnie lubię jak najmniejsze komponenty. Jak widzę komponent, co ma 100-200 linijek kodu, to się zastanawiam czy na pewno musi być taki duży (zwykle nie musi).

Z tą 1 linijką to nieźle pojechałeś. Totalna skrajność. Komponent jednolinijkowy da się uzyskać jedynie przez użycie tak zwięzłej konstrukcji jak:

 export default () => <div>Hello World!</div>;

Tylko co takie coś wnosi? A co ze stylami (które u mnie np. pisze się w JS-ie)? To już nie jest część komponentu? A co jeśli masz kontener Relaya? To nadal jest w jednym pliku i jest to niemalże integralna część komponentu i powinien ten kod leżeć w tym samym miejscu. I gdzie wtedy ta 1 linijka? Ba, nawet w 40 tego pewnie nie zmieścisz. Pomijam już smart komponenty, gdzie dochodzi obsługa zdarzeń chociażby.

Nie wszystkie komponenty mogą być tzw. commonsami (np. Avatar) i mieścić się w kilku, może kilkunastu linijkach. Po zbudowaniu odpowiedniej codebase z takich komponentów tworzysz inne (kompozycja) i wtedy nie ma szans, żeby uzyskać tak skrajne wyniki. Bycie radykalnym jest złe.

LukeJL napisał(a):

Może to się im sprawdza na produkcji, ale jako developer nie chciałbym musieć ogarniać 20 tysięcy komponentów, bo ogarnięcie takiej bazy kodu byłoby raczej trudne (chociaż Dan Abramov na Twitterze pisał, że mają jakąś przeglądarkę komponentów).

Storybook, Atellier chociażby? Poza tym odpowiednia modularyzacja i nikt nie każe skakać Ci między 20 tysiącami komponentów. Zdajesz sobie sprawę, że w dużych teamach są różne odpowiedzialności i prawdopodobnie nie ma jednej osoby, która przejrzała cały codebase złożony z tych 20 tysięcy komponentów?

LukeJL napisał(a):

Poza tym sama liczba nic nie mówi - nie wiadomo, czy potrzebują tyle komponentów. Chyba nigdy nie mówili dokładnych powodów, dla których mają tyle komponentów, nie napisali żadnego case study na ten temat. Więc kierowanie się tym to może być trochę jak wybieranie PHP dlatego, że Facebook napisany jest w PHP.

No tak, zdecydowali się na taki zabieg ot tak. ;) Podobnie z przypadku powstał GraphQL, Relay - do tej pory większość ludzi uważa to za przerost formy nad treścią. Informacja, którą przytoczyłem jest do wygooglowania na blogu Reacta chociażby, intencja o podziale komponentów na aż tak małe była tłumaczona na konferencjach (też tej oficjalnej w siedzibie FB). Odsyłam chociażby do prezentacji z cyklu o Relayu, gdzie podział na małe komponenty sprzyja w konsekwencji zmniejszenia właśnie tego całego overhead, a nie odwrotnie jak sugerujesz. Co więcej, większe komponenty komplikują w konsekwencji reprezentację modelu danych na ich poziomie (z udziałem Relaya zwykle sprowadzasz wszystko do płaskich jsonów i nie zastanawiasz się nad tym jak pod spodem klejone są zapytania - tak btw).

LukeJL napisał(a):

Tylko, że wg mnie problem jest z czym innym trochę - to nie jest kwestia dużo małych vs. mało dużych komponentów, ale o to, czy interfejsy mają być proste czy skomplikowane, czy architektura (nie tylko komponenty, ale cała architektura projektu) jest prosta czy skomplikowana.

Prostota interfejsów w dużej mierze zależy od tego, jak zostanie juz zaprojektowany z punktu widzenia designu. Ja pracuję na styku designu na szczęście, ale znam ludzi, którzy z designerami nie mają kontaktu tylko dostają gotowce, gdzie często interfejs jest przekombinowany. Dobrych designerów jest dużo mniej niż dobrych developerów niestety. A pamiętaj, że są też aplikacje, branże, gdzie problem i nomenklatura są na tyle skomplikowane, że interfejs nie będzie prosty. W dodatku zdarzyło mi się też pracować przy apce, która miała nieintuicyjny interfejs z punktu widzenia przeciętnego usera, ale była skierowana do specjalistów, którzy mieli już swoje przyzwyczajenia (nierzadko absurdalne, ale cóż poradzić) i w oparciu o nie powstał UI, nie w oparciu o best practice'y z goodui.org czy czegoś podobnego.

LukeJL napisał(a):

To z czym mam problem to nie małe komponenty (bo je lubię), tylko raczej hierarchiczna ich struktura

No to przychylam się do argumentu, że prawdopodobnie widok został źle zaprojektowany, albo nie da się tego już uprościć. ;) Niekoniecznie ma to związek z kodem aplikacji.

LukeJL napisał(a):
  • dużo komponentów - większy ból dla programisty, żeby to ogarnąć wszystko, dużo plików, nie wiadomo co jest od czego zależne w jaki sposób, co się w sobie zawiera (chyba, że firmy korzystają z jakichś sensownych styleguidów).

Wydawało mi się, że styleguide'y odnośnie kodowania (JS, React, może CSS, plus baza komponentów ala lokalny bootstrap) i designu (coś w stylu goodui + baza komponentów w invision) to standard. Cóż, w takim razie powinien być to standard w większych aplikacjach, bo potem tworzą się kwiatki jak w Spotify (polecam poczytać case study odnośnie tworzenia styleguide'a i problemów jakie do tego doprowadziły).

LukeJL napisał(a):

Ale i tak - jeśli tego jest za dużo, to nawet jak będziesz miał narysowany graf zależności, to może być to cięzko ogarnąć.

I tu znów kwestia modularyzacji i odpowiedzialności. Wiem, że to trudny problem, ale teamy sobie z tym radzą. Serio.

LukeJL napisał(a):
  • cięzko zapanować na przepływem danych, generuje to albo potrzebę przekazywania danych jawnie przez propsy albo jakąś magię w stylu kontekst czy connect z Reduxa albo przez samodzielne odpytywanie store'ów/innych źródeł danych przez komponenty (tyle, że im więcej magii, tym cięzej zapanować nad wszystkim).

Dlaczego connect to dla Ciebie magia? Tego nie rozumiem. W żadnej aplikacji nie musiałem jeszcze użyć kontekstu, ani refsów (o tym nie wspomniałeś, ale to też jest efektem często tego problemu :P). Jako inspiracje polecam materiały od Netflixa, kolesie sobie bardzo dobrze radzą z ujarzmieniem przepływu danych w bardzo skrajnych warunkach (i nie mówię o środowisku telewizorów).

Co do shouldComponentUpdate to pamiętaj o Immutable chociażby, poza tym Redux nie jest do wszystkiego. Jeśli potrzebujesz częstych aktualizacji złożonych struktur komponentów to wybierz narzędzie do tego stworzone, np. MobX. Flux to nie jest holy grail i ma też swoje słabsze strony (albo inaczej - miejsca, w których na niewiele się zdaje z punktu widzenia perf).

Co do reszty, której nie skomentowałem to ogółem się zgadzam i rozumiem ból. Ba, na co dzień każdy doświadcza podobnych problemów, ale nie są to rzeczy, nad którymi nie da się zapanować. A jako ciekawostkę odnośnie upraszczania tworzenia UI może warto poczytać o Elmie. ;)

0

To jest nie do opanowania ;)

Ja nie nadążam za samymi nazwami nowych frameworków, a co dopiero poznaniem ich.

0

Ja nie nadążam za samymi nazwami nowych frameworków, a co dopiero poznaniem ich.

this

1

Jak ktoś się zastanawia na co poświęcić czas to polecam stronkę: http://stateofjs.com/

0 użytkowników online, w tym zalogowanych: 0, gości: 0