iTechArt logo

Hot or not? Web development w 2022 według ekspertów iTechArt

Development & QA

Zadaliśmy specjalistom iTechArt kilka poważnych pytań dotyczących frontendu - zobaczcie, jak odpowiedzieli!

JK.png

Joanna Kupis

Senior Software Engineer & Head of Frontend Family

Senior Software Engineer i Head of Frontend Family w naszym łódzkim biurze, developerka frontend interesująca się optymalizacją kodu, wydajnością i bezpieczeństwem. Wcześniej pracowała dla branż fin-tech, geolokalizacji i telekomunikacji.

SN.png

Sergey Neprakhin

Software Engineer

Software Engineer w naszym biurze we Wrocławiu, mentor w The Rolling Scopes School, pracujący głównie jako frontend developer w ramach ekosystemu React.

Czy wśród front-endowych frameworków są jakieś wschodzące gwiazdy? 

[Joanna Kupis] Raczej nie. I chociaż pojawiają się na rynku nowe propozycje, to myślę, że ciężko im będzie pobić sukces biblioteki React czy Svelte. W ostatnim czasie przeprowadzana była popularna ankieta State of JS 2021/2022 (https://app.stateofjs.com/) i jest ona dla mnie wyznacznikiem frontendowych trendów. Z nowości wskazują oni na framework Solid (https://www.solidjs.com/). Sami twórcy przyznają, że czerpali z tego, co najlepsze w React i Knockout. Dodają też, że jeśli mieliśmy już okazję poznać React Hooki, to bez problemu odnajdziemy się i w ich rozwiązaniu. W tej chwili framework jest w wersji 1.3.6 i ciekawa jestem, czy uda im się chociaż zbliżyć do wyników topowych graczy (React, Angular, Vue czy Svelte). A jeśli mielibyśmy się skupiać na Reakcie i tym, co dzieje się wokół niego, to gdzieś w okolicach grudnia została wydana pierwsza wersja full-stackowego frameworka Remix (https://remix.run/). Przyjrzałabym się mu dokładniej, głownie ze względu na nazwiska, jakie za nim stoją. Bo twórcami są autorzy React Routera – Ryan Florence i Michael Jackson.   

[Sergey Neprakhin] O ile wiem, nie ma nowych graczy. React wyda niedługo wersję 18, ostatnio chłopaki zorganizowali konferencję, na której mówili o nadchodzących zmianach. Jest ich całkiem sporo w porównaniu z poprzednią wersją. Nagranie z konferencji jest zamieszczone na YouTube (https://www.youtube.com/channel/UC1hOCRBN2mnXgN5reSoO3pQ). Już teraz można przetestować 18. wersję w otwartej becie. Przy okazji ogłosili też nową dokumentację. Obecna wersja jest przestarzała, dlatego postanowili napisać ją od zera, sprawić, żeby była prostsza do zrozumienia i bardziej aktualna, z interaktywnymi przykładami i wbudowanym edytorem kodu, dzięki któremu można pobawić się Reactem bezpośrednio w dokumentacji. Frameworki oparte na bibliotece React ciągle zyskują na popularności, statyczny generator witryn GatsbyJS, niedawno wydana wersja 4 i Next.JS z Server Side Rendering. Niestety, nie powiem Wam o nich nic więcej, bo ostatnio pracowałem z Gatsbym w wersji 2, a z Next.js nie pracowałem wcale.

Czy mieliście okazję zobaczyć jeszcze jakieś konferencje, które powinniśmy sprawdzić? 

[SN] W ubiegłym roku odbyła się ciekawa konferencja o nazwie GRAPHQL SUMMIT. Dużo prelegentów, ciekawe tematy, wyjaśnienia skomplikowanych punktów przez programistów Apollo Client. Można obejrzeć nagranie z tej konferencji (https://www.apollographql.com/events/virtual-event/graphql-summit/). Zaprezentowali tam także Apollo Odyssey, samouczek z tutorialem, który pozwala bez bólu i strachu zostać certyfikowanym programistą GraphQl. Wydarzenia takie jak to są bardzo pomocne, ponieważ nawet jako uzależniony od React mogę powiedzieć, że trudno jest śledzić wszystkie nowości w jego ogromnym ekosystemie. 

[JK] Jest tego całkiem sporo. Ja lubię oglądać Chrome Dev Summit     (https://developer.chrome.com/devsummit/). Można tam znaleźć dużo informacji o wydajności, optymalizacji kodu, no i nowości w Chrome oczywiście. Zawsze są tam też prelekcje poruszające tematy PWA czy dostępności. Jeśli chodzi o Reacta, to poleciłabym React Summit (Remote Edition) (https://remote.reactsummit.com/). W 2021 roku z prezentacją na temat Remixa pojawił się sam jego twórca – Michael Jackson. Nie zabrakło także wystąpień na temat zyskującego popularność Next.js, ani historii i przykładów migrowania istniejących już projektów do TypeScripta. A dla fanów Angulara, bardzo polecam ngconf (https://remote.reactsummit.com/). Często pojawiają się tam członkowie Angular Team ze swoimi prezentacjami. A od kogo lepiej się uczyć jeśli nie od samych twórców? 

Czy w JS nadchodzi coś przełomowego? 

[SN] Jeśli chodzi o JS, mamy ES12 z takimi funkcjami, jak separatory liczbowe, obiecujące dowolne i logiczne operatory przypisania. Są dość wygodne, ale to ulepszenia poszczególnych mechanik, dodanie pojedynczych metod. Ogólnie rzecz biorąc, od czasu ES6 nie wydarzyło się nic przełomowego. 

[JK] Też nie powiedziałabym, że czeka nas tak wiele nowości, jak przy okazji ES6. Dodałabym na pewno, że już teraz, w niektórych przeglądarkach można korzystać z top – level await (https://github.com/tc39/proposal-top-level-await) (Status: Stage 4 – Finished). Oznacza to między innymi, że w końcu możemy doładowywać asynchroniczne moduły, czy czekać na rozwiązanie Promise, poza ciałem specjalnie przygotowanej do tego funkcji. Dobrym rozwiązaniem może się okazać globalny obiekt Temporal (https://github.com/tc39/proposal-temporal) (Status: Stage 3 – Candidate), który jak obiecują autorzy ma za zadanie ułatwić pracę z datami czy strefami czasowymi i zupełnie zmienić nasze podejście do tego jakże uciążliwego tematu. Rozwiązania takie jak np. (niewspierany już!) Moment.js mają zupełnie przestać być potrzebne. 

Kolejną nowością, która wydaje mi się interesująca jest tzw. chaining error cause (https://github.com/tc39/proposal-error-cause) (Status: Stage 4 - Finished).  Wzbogaca on obiekt błędu o dodatkowe informacje, które maja pomóc nam w procesie debbugowania kodu. I jeszcze coś, na co sporo osób czeka, bo zgodnie z danymi ze State of JS 2020 to jedno z najczęściej zgłaszanych zapotrzebowań na funkcjonalność, czyli natywny operator pipe (https://github.com/tc39/proposal-pipeline-operator) (Status: Stage 2 – Draft). Ja sama chętnie używałabym dekoratorów (https://github.com/tc39/proposal-decorators) (Status: Stage 2 – Draft). Oczywiście biorąc pod uwagę status tych funkcjonalności, będziemy musieli na nie jeszcze trochę poczekać, a może się zdarzyć, że w ogóle nie wejdą do specyfikacji.

Co nowego w wyglądzie strony? Widzisz jakieś zmiany w interfejsie użytkownika? 

[JK] Już od jakiegoś czasu zauważam powrót do prostych designów. Rezygnujemy z krzykliwych kolorów, strony mają dużo światła tj. przestrzeni między grupami treści, a elementy nie sprawiają wrażenia wypukłych. Animacje i ruch zdają się być bardziej subtelne (tzw. micro-animations). Z drugiej jednak strony designerzy próbują zapewnić swego rodzaju immersyjność i „wtopić” użytkownika w prezentowany świat, opowiedzieć mu historię, która go przyciągnie i sprawi, że zechce zostać na dłużej. Dla mnie krokiem w bardzo dobrą stronę jest wszechobecny ostatnio dark mode, zwłaszcza jeśli jest on bezpośrednio skorelowany z ustawieniami systemu operacyjnego. Czytałam, że statystycznie 8 na 10 osób preferuje ciemny motyw kolorystyczny w odwiedzanych witrynach.  

[SN] Nie jestem projektantem UI/UX, ale jeśli mówimy o stylizacji we frontendzie, CSS-in-JS mocno wkroczył w nasze życie. Atomic CSS ponownie zyskuje na popularności, a jego wspaniałym przedstawicielem jest Tailwind CSS. Moim zdaniem pomysł dodania wielu klas do JSX zmniejszy czytelność kodu i zwiększy rozmiar komponentów, jestem jednak pewien, że przy odpowiednim doświadczeniu z takim podejściem szybkość developmentu wzrośnie ze względu na fakt, że nie musisz opisywać oddzielnych plików stylów. Nadal najpopularniejszymi bibliotekami UI są Ant Design i Material UI, a CoreUI jest jednym z najpopularniejszych rozwiązań szablonów panelu administracyjnego. 

A co ze statycznymi stronami? Rzeczywiście wracają? 

[SN] To świat JAMstack i Gatsby JS, jednych z czołowych przedstawicieli rozwiązań opartych na React, które zapewniają podejście SSG. Statyczne strony właściwie nigdy nie odeszły z powodu swoich znaczących zalet. Dobre SEO, szybkie ładowanie początkowe i kolejnych stron oraz aktualna treść są kluczowe dla niektórych kategorii aplikacji webowych. 

[JK] Ja też jestem zdania, że statyczne strony nigdy tak naprawdę nie odeszły. Ostatnio temat staje się bardziej popularny, bo powstają frameworki, które nie dość, że wspierają SSG (static site generation) czy SSR (server side rendering), to dodatkowo eliminują problemy, z jakimi zmagaliśmy się w przeszłości. To właśnie dzięki procesowi hydracji jesteśmy w stanie zapewnić interaktywność strony przy jednoczesnym prerenderowaniu HTML po stronie serwera. Ale to, jakie rozwiązanie wybierzemy, zależy od rodzaju aplikacji, którą tworzymy. Strony ładowane po stronie klienta mogą być szybsze (oczywiście nie licząc pierwszego ładowania), bo nie mamy zapytań do serwera przy zmianach fragmentów stron. Same odpowiedzi są mniejsze, bo niosą mniej treści. Możemy mieć też poczucie większej responsywności strony.  

Z kolei jako dobry przykład zastosowania statycznie generowanych stron wskazałabym wszelkiego rodzaju dokumentacje. Zresztą daleko nie trzeba szukać. Dokumentacja TypeScript, GraphQL, ReactJS czy MongoDB, wszystkie tworzone są właśnie z wykorzystaniem tego konceptu przy użyciu GatsbyJS. Treść jest stała, co w tym wypadku znaczy, że nie zmienia się w trakcie korzystania, a i interakcja użytkownika ze stroną nie jest znacząca. Wykorzystujemy za to lepsze pozycjonowanie strony, zapewniając naszym użytkownikom szybkie dotarcie do sprawdzonych informacji.

Programista Fullstack czy FE? Którą specjalizację uważasz za najlepszą? 

[SN] Dobre pytanie. Wydaje mi się, że należy robić to, co lubi się najbardziej i dobrze się przy tym bawić. Myślę, że dobry frontend developer skorzystałby na wiedzy junior backend developera i odwrotnie. Jednocześnie, jak już wspominałem, śledzenie wszystkich nowości ze świata frontendu może być dość trudne, a tym bardziej wypróbowywanie wszystkich nowych wydań w celu wyrobienia sobie na ich temat uzasadnionej opinii, nie bazującej tylko na artykule, który gdzieś przeczytaliśmy. Jeśli więc przez Fullstack masz na myśli frontend developera, który potrafi napisać zapytanie SQL do bazy danych, albo backend developera, który umie zmienić kolor przycisków, to tak, Fullstack. Ale jeśli oznacza to, że programista powinien być równie biegły tak w FE, jak i BE, to myślę, że nie będzie zbyt dobry w żadnym z tych obszarów. 

[JK] Myślę, że nawet jeśli zdecydujemy się na ścieżkę FE developera to i tak prędzej czy później dopadnie nas jakiś fullstackowy framework, w którym tworzyć możemy w Reakcie (albo chociaż w JSie) i chcąc nie chcąc będziemy musieli przyswoić pewne backendowe zagadnienia. Uważam też, że nawet jeśli nie mamy aspiracji, żeby zostać fullstack developerem, to dobrze jest rozumieć choć trochę, co się dzieje na każdym etapie wytwarzania oprogramowania. Jednak, jeśli kiedyś będziemy chcieli nauczyć się więcej, to właśnie teraz próg wejścia w rolę fullstack developera jest dużo niższy niż kiedyś. Bo chociaż narzędzi jest więcej to wszystko może być pisane w JSie – języku, który znamy i który nie stanowi dodatkowej bariery. 10 lat temu nie było takiej możliwości. Ale oczywiście zgadzam się, że jest bardzo ambitny cel i duże wyzwanie.