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-07 12:58
Brunatny Szczur
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. ;)

potem odpowiem na całość - refsy są przydatne do integrowania zewnętrznych API - np. jak osadzasz CodeMirror w komponencie. - LukeJL 2017-01-07 13:26

Pozostało 580 znaków

2017-01-10 23:35
Nadziany Lew
0

To jest nie do opanowania ;)

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

Pozostało 580 znaków

2017-01-11 07:37
Krzywy Mleczarz
0

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

this

tylko this może być wszystkim w JS, tak zwane płynne this, co odzwierciedla płynną naturę frameworków JSowych, bo przecież żyjemy w epoce płynnej nowoczesności, jak mówił Bauman. - LukeJL 2017-01-11 09:45

Pozostało 580 znaków

2017-01-11 13:14
1

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

"This survey is too damn long!" :D - Desu 2017-01-11 13:42

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