Zbyt szybki rozwój technologi wokół JavaScript

Odpowiedz Nowy wątek
2017-01-04 22:46
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...

Przypomina mi to https://news.ycombinator.com/item?id=12758085 (Why is everything in JavaScript changing so fast?) - Krzysztof Bogdan 2017-01-04 23:30
Zbyt szybki, ale rozwój? Ty to nazywasz rozwojem? Raczej szydełkowanie i ślepe próby zrobienia lepiej. Tam chyba nic nie jest dobrze w odróżnieniu od backendu - karolinaa 2017-01-05 08:38

Pozostało 580 znaków

2017-01-05 00:56
13

Co do Node'a:

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.

edytowany 7x, ostatnio: Maciej Cąderek, 2017-01-05 02:22

Pozostało 580 znaków

2017-01-05 01:49
Mały Shinobi
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ą.

Proponuję nie instalować niepotrzebnych zależności ;) - Maciej Cąderek 2017-01-05 02:17

Pozostało 580 znaków

2017-01-05 02:00
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.

Pozostało 580 znaków

2017-01-05 07:26
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ść :)

Nie jestem na 100% pewny, ale webpack ogarnąłby chyba konwersje SASS -> CSS i zrobił przy okazji hot reloading w przegladarce, co mi sie bardzo podoba. Inna sprawa, że w gulpie jest Borwser-Sync i można osiąnąć coś podobnego. - członek zarządu 2017-01-06 15:28
Za pomocą odpowiedniego loadera webpack bez problemu ogarnie SASS -> CSS. - some_ONE 2017-01-06 15:39

Pozostało 580 znaków

2017-01-05 08:09
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.
edytowany 4x, ostatnio: Desu, 2017-01-05 08:21

Pozostało 580 znaków

2017-01-05 10:41
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

Pozostało 580 znaków

2017-01-05 15:33
Brunatny Szczur
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.

Pozostało 580 znaków

2017-01-05 21:25
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ć.

edytowany 2x, ostatnio: LukeJL, 2017-01-05 21:26

Pozostało 580 znaków

2017-01-06 12:19
Brunatny Szczur
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.

LukeJL nie mówił o problemie tight coupling malych komponentów, ale o problemie z przesyłaniem danych między nimi. Inna sprawa, że są na to rozwiązania typu Redux we front endzie, które ten problem jakoś tam rozwiązują od innej strony... (na backendzie też się czasami tak da) - członek zarządu 2017-01-06 16:17

Pozostało 580 znaków

2017-01-07 09:08
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 ?).

edytowany 1x, ostatnio: LukeJL, 2017-01-07 09:12
tak myślę, że większa ilość komponentów = dłuższy czas ładowania (większa ilość requestów)? - czysteskarpety 2017-01-07 11:24
albo większa wielkość bundle'a - chociaż równie dobrze ludzie mogą mieć dwa komponenty po napakowane co niemiara, albo mogą w ogóle nie używać Reacta i na czystym HTML i bez JavaScriptu (albo z jQuery) mają czasem po kilkamegabajtów requestów (grafika, CSS etc.), więc to też wszystko zależy. Nie ma jakiejś spójnej zależności. - LukeJL 2017-01-07 11:34

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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