Jeżeli świat frontendu nie jest Ci obcy, to z pewnością wiesz, że frameworki są jego integralną częścią. Tworzenie stron lub aplikacji internetowych bez wykorzystania jednego z przedstawicieli tej grupy wydaje się być niemożliwe.

Skąd więc w mojej głowie wzięło się postawione w tytule pytanie i dlaczego wspominam o tym właśnie teraz?

Nie sposób odpowiedzieć jednym zdaniem. Gdyby było to możliwe, to ten artykuł prawdopodobnie by nie powstał. Zapewniam Cię jednak, że tytuł, mimo iż clickbaitowy, to porusza temat, który od pewnego czasu przewija się w moich myślach – i nie tylko moich, jak przekonasz się za chwilę.

Zanim jednak przejdziemy do sedna, to chciałbym Cię uprzedzić, że nie jest to jeden z wielu artykułów, które wytykają błędy Reacta lub innego frameworka. Zamiast tego będzie tu dużo historii, prywatnych przemyśleń i posiłkowania się wieloma osobami i instytucjami, które podzielają mój pogląd.

Żeby zrozumieć jej genezę, musimy cofnąć się do roku 2014. W tym czasie na rynku nie istniało jeszcze wiele frameworków, a przynajmniej nie w takiej formie, jaką znamy dzisiaj. Co prawda były już Backbone.js oraz Ember.js, ale ich działanie jest dalekie od tego, do czego większość z nas jest dzisiaj przyzwyczajona. Od 2010 roku istniał również AngularJS, ale dopiero pojawienie się Reacta w 2014 roku spowodowało prawdziwą rewolucję w świecie frontendu.

W czasach przed Reactem większość aplikacji korzystała z techniki, która dziś wraca do łask, a która na długi czas została zapomniana - głównie za sprawą Reacta właśnie. Mowa oczywiście o SSR, czyli renderowaniu po stronie serwera.

Zdecydowana większość stron internetowych stworzonych przed rokiem 2014 korzystała z technologii nazwanej w skrócie AJAX (Asynchronous JavaScript And XML) do wyświetlania dynamicznych treści. W uproszczeniu - klient wysyła pierwsze zapytanie do serwera, a w odpowiedzi otrzymuje gotowy HTML, który musi jedynie wyświetlić użytkownikowi. Jeżeli interakcja użytkownika sprawia, że część strony powinna się zmienić, to powtarzamy tę operację - ponownie wysyłamy zapytanie do serwera, a ten ponownie odsyła nam gotowy HTML. Jednak tym razem, zamiast odświeżać całą stronę, pobraliśmy jedynie ten element, który uległ zmianie.

Oczywiście AJAX nie wziął się znikąd. Mimo że istnieje od 1999 roku, to dopiero rok 2004 okazał się przełomowy dla jego zastosowania. Właśnie wtedy powstał Gmail, a wraz z nim początek ery aplikacji internetowych, które zachowywały się i wyglądały niemal tak samo jak natywne. Zanim jednak Google pokazało światu, jak można wykorzystać dostępne technologie, zdecydowana większość internetu była statyczna. Każda zmiana wymagała ponownego przesłania całej zawartości strony z serwera, co sprawiało, że interakcje użytkownika ze stroną były powolne, a wrażenia z użytkowania w niczym nie przypominały aplikacji desktopowych.

Jak ta krótka lekcja historii łączy się z tematem artykułu? Otóż wspomniany już wcześniej rok 2014 zmienił wszystko. Aplikacje i strony internetowe zaczęły wykorzystywać Reacta i tym samym przeniosły cały proces renderowania treści na klienta. Nadal wykonywaliśmy zapytania do serwera, ale tym razem w odpowiedzi otrzymywaliśmy niemal pustą strukturę HTML oraz całą masę JavaScriptu odpowiedzialnego za wyświetlanie treści. Aplikacje stały się znacznie bardziej responsywne, łatwiejsze w skalowaniu i w praktyce zaczęły wypierać natywne oprogramowanie. Podsumowując - same plusy. Pytanie tylko, czy na pewno?

Wątpliwości budzi fakt, że stopień zaawansowania i skomplikowania witryn internetowych rósł i stale rośnie. Rośnie także ilość kodu potrzebnego do wyświetlenia i obsłużenia wszystkich tych funkcjonalności. Oczywistym jest zatem fakt, że czas od pierwszego zapytania do pojawienia się treści na ekranie znacznie się wydłużył. Wpływ na to ma nie tylko rozmiar naszego projektu, ale także prędkość połączenia internetowego użytkownika oraz urządzenie, na którym wyświetla daną stronę. Przy czym na dwa ostatnie czynniki niestety nie mamy żadnego wpływu.

W związku z powyższym twórcy niemal wszystkich popularnych frameworków (oraz meta-frameworków, o czym opowiem w dalszej części) zaczęli szukać rozwiązania, które pozwoli skrócić czas wczytywania się strony. Problemem było także SEO, ponieważ crawlery nie były w stanie poradzić sobie z poprawnym indeksowaniem treści renderowanych dynamicznie po stronie klienta. Okazało się, że rozwiązaniem obu tych problemów jest… SSR. W ten oto sposób powróciliśmy częściowo do rozwiązania sprzed niemal dekady. Częściowo, ponieważ Client Side Rendering (CSR) nadal pozostał w użyciu w przypadku dynamicznych treści, a sam SSR korzysta z hydracji po stronie klienta, co nieco odróżnia go od tradycyjnego podejścia do tego tematu. 

Do statycznych stron, które nie zmieniają się w ogóle lub robią to niezwykle rzadko zaczęto stosować SSG, czyli statyczne generowanie treści w momencie kompilacji kodu. Powstała także inna wariacja tego podejścia - ISG. Charakteryzuje się ona możliwością ponownego zbudowania statycznych treści bez konieczności kompilacji kodu i deploymentu.

Jak się później okazało, trzy sposoby renderowania treści to zbyt mało, a użytkownik końcowy nadal musi czekać zbyt długo na treść lub możliwość interakcji ze stroną. W związku z tym powstały kolejne rozwiązania: SSR Streaming, Progressive Hydration oraz najnowsze z nich - komponenty serwerowe.

Opcji jest wiele, a wyboru nie ułatwia fakt, że niektóre z nich można ze sobą łączyć. Przykładowo: użycie komponentów serwerowych nie wyklucza możliwości użycia SSR lub SSR Streaming. Próg wejścia w świat frontendu stale rośnie, a osoby początkujące mają do nadrobienia kilka lat historii renderowania stron internetowych. Nawet dla doświadczonych programistów nadążanie za najnowszymi trendami zaczyna być problematyczne, a głosy niezadowolenia słychać zewsząd.

Za pierwszy przykład niech posłuży Marc Grabanski, założyciel niezwykle popularnej strony Frontend Masters.

Oczywiście wpis jednego człowieka można uznać za wyjątek od reguły. Okazuje się jednak, że takich osób jest znacznie więcej. David Heinemeier Hansson, twórca Ruby on Rails, w jednym z postów otwarcie opowiada się za odrzuceniem skomplikowanych rozwiązań i zachęca do samodzielnego pisania kodu, zamiast stosowania biblioteki lub frameworka, wszędzie tam, gdzie to możliwe.

Zdaniem wielu osób, w tym także moim, frameworki już dawno przekroczyły granicę, za którą stają się zbyt skomplikowane i zbyt abstrakcyjne. To właśnie skłoniło mnie do postawienia teori, że świat frontendu zmienia kierunek i zaczyna zmierzać w stronę odrzucenia frameworków lub ograniczenia ich zastosowania. Do łask zaczyna również wracać samodzielna implementacja funkcjonalności zamiast stosowania bibliotek. 

Na tym jednak argumenty się nie kończą.

Przez ostatnie 10 lat na scenie frontendowych frameworków liczyły się głównie trzy: React, Vue i Angular, przy czym ten pierwszy zdecydowanie zdominował rynek i choć w ostatnim czasie pojawiło się ich wielu nowych konkurentów (mowa tu chociażby o Svelte, Solid, Astro czy HTMX), to żaden z nich nie był w stanie zbliżyć się popularnością do Reacta.

Jednak od jakiegoś czasu widać zmianę w postrzeganiu frameworków przez programistów. W wynikach najnowszej ankiety StateOfJS można zauważyć trend podobny do opisanego przeze mnie wyżej. Niemal wszystkie frontendowe frameworki (z wyjątkiem Vue i Angulara) skręcają w kierunku negatywnych recenzji (lewa sekcja na diagramie poniżej). Co prawda ich popularność nadal rośnie, ale jest to prawdopodobnie spowodowane obecnym stanem frontendu, który wykorzystuje frameworki do tworzenia nawet prostych, statycznych stron internetowych. Naturalnym zjawiskiem jest fakt, że większość programistów wie o ich istnieniu i używała co najmniej jednego z nich.

Popularność frameworków frontendowych według ankiety StateOfJS 2024

Z wykresu dość jasno wynika, że w ciągu ostatnich dwóch lat React znacząco stracił w oczach programistów, a liczba negatywnych ocen zaczęła dynamicznie rosnąć. Przełomowy okazał się również rok 2024, ponieważ to właśnie on przyniósł spadek popularności Reacta, co nie zdarzyło się nigdy wcześniej.

Teorii, dlaczego tak się dzieje, jest kilka. Postaram się przedstawić te, które moim zdaniem są najbardziej prawdopodobne:

• Dynamiczne zmiany: w ostatnim czasie React wprowadził bardzo dynamiczne zmiany w publicznym API, dodając między innymi nowe hooki, komponenty i funkcje serwerowe. Wszystkie te zmiany są niezwykle istotne i trudno je po prostu zignorować. Oczywiście nie oznacza to, że “stare” podejście do tworzenia aplikacji w React nagle przestało działać, ale trudno oprzeć się wrażeniu, że programiści po prostu przestali nadążać za biblioteką, której używają. O ile dostosowanie małej strony internetowej do nowego API nie stanowi większego problemu, o tyle dostosowanie dużego, komercyjnego projektu jest niezwykle czasochłonne. 

• Biblioteka nie dla programistów: jeszcze kilka lat temu standardem było tworzenie aplikacji przy użyciu samego Reacta i kilku bibliotek pomocniczych (np. React Router). Ten czas mamy jednak już za sobą i wszystko wskazuje na to, że React staje się biblioteką przeznaczoną dla twórców frameworków. Samodzielna implementacja dyrektyw lub komponentów serwerowych nie należy do najłatwiejszych, a oficjalna dokumentacja otwarcie wspomina o Next.js, który wszystkie te funkcjonalności dostarczy za nas. Nieco szerzej poruszyłem ten temat w artykule, w którym omawiam [nowości w React 19](article/nowosci-i-zmiany-w-react-19).

• Wydajność: dla wielu to jeden z najważniejszych powodów, by zrezygnować z frameworków. Jest to również główny powód, dla którego powstały komponenty serwerowe, SSR, SSG i wiele innych sposobów na przyspieszenie renderowania i przeniesienie go z powrotem na serwer. Ten temat zasługuje na szczegółową analizę, dlatego poruszam go ponownie w dalszej części artykułu.

Ta lista to jedynie wierzchołek góry lodowej, a powodów do rezygnacji z wykorzystania frameworka jest o wiele więcej. Przede wszystkim należy w ogóle zacząć kwestionować słuszność pisania całego kodu w jednej technologii, która jest zależna od zewnętrznej firmy. Już sam fakt zastanowienia się da nam szansę na rozważenie wszystkich za i przeciw. Jeżeli wybierzemy Reacta, Angulara lub dowolny inny framework, nie rozważając jego zalet i wad, to istnieje duża szansa, że w przyszłości napotkamy problemy związane z niedopasowaniem technologii do projektu.

Kolejnym aspektem jest vendor-lock, czyli uzależnienie całego projektu od zewnętrznego dostawcy. O ile przeniesienie funkcjonalności ze starszej wersji języka programowania na jego nowszą wersję nie powinno stanowić wielkiego wyzwania, o tyle migracja projektu z jednego frameworka na inny może być niezwykle trudne, a w skrajnych przypadkach może nawet wymagać napisania kodu od początku.

Niestety wiele osób nie poświęca ani chwili na wybór odpowiednich narzędzi do projektu. Wybierają jedno z najpopularniejszych rozwiązań albo decydują się na wybór tego, w którym czują się pewnie. Nierzadko jest to zawsze ten sam framework, niezależnie od tego, czy właśnie budują statyczną stronę, czy dynamiczny panel administracyjny. Problem polega na tym, że uniwersalne narzędzia nie istnieją, a każda technologia ma zarówno plusy, jak i minusy. Przed rozpoczęciem projektu warto jest się zastanowić jakich bibliotek użyć i czy w ogóle należy ich użyć.

Tu jednak napotykamy kolejny problem - liczba dostępnych na rynku rozwiązań nie ułatwia podjęcia decyzji. Kolejne frontendowe frameworki wyrastają niczym grzyby po deszczu, a zdaniem ich twórców oferują coraz to nowsze i lepsze podejście. Większość z nich nie przebija się do “mainstreamu”, ale sam fakt ich istnienia wprowadza niemałe zamieszanie i dezorientuje wielu programistów, którzy w obliczu tak dużego podziału rynku nie wiedzą, czego właściwie warto się uczyć i jaki framework wybrać do kolejnego projektu.

Na szczęście z pomocą przychodzą nam meta frameworki, które ten wybór ułatwiają…

Popularność meta-frameworków jest tak duża, że trudno jest nam sobie wyobrazić dzisiejszy frontend bez nich. Jednak sam termin meta framework aż tak popularny nie jest, dlatego wyjaśnijmy go w kilku zdaniach. 

Już sama nazwa wskazuje nieco z czym mamy do czynienia. Meta framework łączy w sobie kilka rozwiązań w jedno. Opiera się na jednej z frontendowych bibliotek lub na frameworku i wzbogaca jego działanie, dodając nowe funkcjonalności. Świetnym przykładem jest Next.js, który został zbudowany w oparciu o Reacta, dając programiście do dyspozycji dodatkowe możliwości:

• Routing oparty o strukturę folderów

• Możliwość tworzenia serverless functions

• Cache

• Optymalizację assetów

• Wiele innych

Nie jest to jednak jedyny przedstawicielem tego gatunku. Wśród najpopularniejszych rozwiązań znajdziemy między innymi Nuxt.js (Vue), SolidStart (Solid), Remix (React), a na horyzoncie pojawił się także TanStack Start (React). Niektórzy zaliczają do tej grupy również Angulara, ponieważ posiada większość rozwiązań, które znajdziemy w innych meta-frameworkach.

Ta krótka definicja powinna w zupełności wystarczyć do zrozumienia dalszej treści. Zanim jednak przejdziemy dalej, rzućmy ponownie okiem na sytuację dotyczącą meta-frameworków w ostatniej ankiecie StateOfJS:

Niemal wszystkie frameworki (poza Gatsbym) zaczęły skręcać w kierunku negatywnych ocen, a Next.js zdecydowanie wyróżnia się wśród innych. Dzieje się tak przede wszystkim dlatego, że jest on zdecydowanie bardziej popularny, jednak to nie jedyny powód. 

Do 2022 roku Next.js radził sobie bardzo dobrze, a jego popularność stale rosła. Rosła także liczba pozytywnych ocen i ogólny poziom zadowolenia użytkowników. Co w takim razie stało się w 2022 roku i skąd ten nagły spadek zadowolenia programistów?

Okazuje się, że od tego momentu Next.js zaczął przechodzić dynamiczne zmiany. Częściowo jest to spowodowane kierunkiem, który wytyczył React (komponenty serwerowe, funkcje serwerowe, itd.), a częściowo wewnętrznymi decyzjami zespołu odpowiedzialnego za utrzymanie tego frameworka. Cały problem polega na tym, że podobnie jak w przypadku Reacta, decyzje te wprowadziły ogromne zmiany w sposobie budowanie aplikacji, a publiczne API dostępne dla programistów stało się skomplikowane.

W ciągu dwóch lat (2022 - 2024) zmianom uległy kluczowe funkcjonalności:

• Sposoby cache’owania: mimo iż w dokumentacji widnieje zapis, że zrozumienie działania cache’a nie jest konieczne do korzystania z frameworka, to w praktyce okazuje się to niezbędne. Przez dynamiczne i wielokrotne zmiany (6 razy w ciągu dwóch lat) w funkcjonowaniu cache’a, programiści natrafiali na trudne do zdiagnozowania problemy. Wymagało to także od programistów ciągłego uczenia się od nowa tej samej funkcjonalności.

• Routing: w 13 wersji Nexta pojawił się nowy sposób routingu i budowania layoutu aplikacji. Problem polega na tym, że w celu zachowania wstecznej kompatybilności, zespół odpowiedzialny za Nexta nie mógł od tak wywrócić do góry nogami poprzedniej wersji routingu. W efekcie mamy dwa, zupełnie różne API za pomocą których możemy budować routing. Jakby tego było mało, przeniesienie “starego” sposobu na ten z wersji 13+ jest niestety czasochłonne, a twórcy nie dostarczyli codemode’a, który mógłby to ułatwić.

• Wykorzystywana wersja Reacta: w ostatnich dwóch latach zmieniła się również wersja Reacta, wykorzystywana przez Next.js. Wymagało to dodania wsparcia dla komponentów serwerowych, funkcji serwerowych (które oryginalnie nazwane były akcjami, ale społeczność używała ich niezgodnie z pierwotnym zamysłem twórców, co poskutkowało zmianą nazwy…) i kilku innych zmian wprowadzonych w React. Zbiegło się to w czasie z pozostałymi zmianami w Next.js i jeszcze bardziej skomplikowało korzystanie z frameworka.

Podobnie jak w przypadku Reacta, tak i tu, nie jest to pełna lista zmian. W zupełności jednak wystarcza by zauważyć, że przez ostatnie 24 miesiące framework zmienił się nie do poznania. Dodatkowo jego publiczne API stało się znacznie bardziej skomplikowane, chociażby za sprawą dwóch, zupełnie różnych od siebie sposobów routingu. Dodatkowo, w efekcie bliskiej współpracy obu frameworków, zatarła się również granica pomiędzy nimi, przez co wielu programistów nie jest w stanie określić z której biblioteki pochodzi dana funkcjonalność, a spadek zadowolenia z programistów z Reacta, pociągnął za sobą również spadek ocen Nexta.

Kolejnym problemem jest wysoka warstwa abstrakcji, która stale rośnie. Już sam React stanowi znaczną warstwę abstrakcji, a Next dokłada do niego kolejny poziom. Zrozumienie tego, co dzieje się pod spodem i późniejsze debugowanie problemów, jest sporym wyzwaniem. Zauważyć można to szczególnie w  przypadku nowych programistów, którzy wiedzę na temat frameworków czerpią z kursów online, dokumentacji innych źródeł opisujących zazwyczaj najbardziej aktualną wersję danej biblioteki. 

Co w tym złego? W samej nauce oczywiście nie ma niczego złego. Po raz kolejny to dynamicznie zmieniające się środowisko stanowi przeszkodę. W momencie pisania tego artykułu, większość dużych komercyjnych aplikacji wciąż wykorzystuje starsze wersje Next.js i tym samym korzysta z poprzedniego podejścia do routingu, pobierania danych czy renderowania stron. W efekcie, nowi programiści, którzy chcą wkroczyć w świat meta frameworków, nierzadko muszą uczyć się kilku różnych wersji tej samej biblioteki, ponieważ wersje te różnią się od siebie znacząco. 

Meta frameworki frontendowe to nadal względnie nowy gatunek, ale już teraz widać, że dług technologiczny, który generują jest ogromny. Próby nadążania za tempem rozwoju jednego z nich wydają się nie mieć sensu w przypadku średnich i dużych projektów, gdyż czas (a tym samym pieniądze) który trzeba na to poświęcić jest poza zasięgiem większości firm. W przypadku starszych projektów (opartych na przykład na PHP), utrzymanie nie było aż tak kosztowne, a próba czasu okazała się być wyzwaniem, któremu udało się sprostać.

Czy w takim razie powinniśmy odejść od używania frameworków? 

Na to pytanie odpowiemy już za chwilę. Postaramy się także znaleźć alternatywę i odpowiedzieć na kilka innych, równie nurtujących pytań.

Jakiś czas temu trafiłem na stronę brytyjskiego rządu, która zawiera wytyczne dla firm i programistów tworzących oprogramowanie rządowe. W dokumencie tym możemy przeczytać między innymi, że:

• strony powinny być budowane tak, by działać również wtedy, gdy wczyta się jedynie HTML

• CSS powinien być dodawany do strony dopiero po stworzeniu struktury HTML i nie powinien wpływać na jej działanie

• powinniśmy unikać stosowania takich technik jak CSS-in-JS

• JavaScript powinien jedynie dodawać do strony interaktywności, ale strona internetowa powinna działać także wtedy, gdy z jakiegoś powodu nie uda się wczytać skryptu

• nie powinniśmy budować stron internetowych typu SPA (opierają się one całkowicie na JavaScript)

Dla wielu z nas te wytyczne mogą się wydawać absurdalne. Jesteśmy przyzwyczajeni do wykorzystywania JavaScriptu gdzie tylko się da, a znaczna część naszych aplikacji opiera się na tej właśnie technologii. Dlaczego zatem brytyjski rząd odradza stosowanie frameworków i zachęca do wykorzystania HTMLa?

Odpowiedzią jest progressive enhancement i budowanie stron z myślą o ich długotrwałym działaniu. Zacznijmy jednak od tego pierwszego - progressive enhancement oznacza, że nasza strona spełnia swoje podstawowe założenia i pozwala użytkownikom na interakcję nawet wtedy, gdy wczytany został jedynie HTML. Jeżeli przeglądarka użytkownika wspiera CSS i zostanie on wczytany poprawnie, to wzbogaci warstwę wizualną strony, ale nie wpłynie w żaden sposób na jej działanie. Podobnie sytuacja wygląda z JavaScript - możemy go wykorzystywać, ale powinien on być jedynie dodatkiem, a nie decydować o działaniu podstawowych funkcjonalności strony internetowej.

Budując aplikację w ten sposób, unikamy sytuacji w których JavaScript nie wczyta się poprawnie, a użytkownik zostanie z pustą stroną. Cytując architekta, który brał udział w tworzeniu stron brytyjskiego rządu:

A skoro już jesteśmy przy temacie dostępności i zapewnienia dostępu dla każdego - polski rząd również stosuje podobne podejście. To oczywiście ma swoje minusy, bo wiele stron wygląda na przestarzałe i z pewnością nie dorównuje graficznie najnowszym aplikacjom internetowym. Plusem jest jednak fakt, że strony te działają na niemal każdym urządzeniu, nie wymagają JavaScriptu i nie obciążają urządzenia renderowaniem po stronie klienta całej treści strony. 

Wszystko zależy zatem od powodów dla których zdecydowaliśmy się na budowę strony internetowej. Jeżeli naszym celem jest stworzenie witryny dostępnej dla każdego, odpornej na błędy i działającej nawet na starszych urządzeniach, to zdecydowanie powinniśmy zastosować progressive enhancement. Sytuacja wygląda inaczej jeśli budujemy aplikację, która powinna jak najszybciej zacząć na siebie zarabiać, MVP projektu lub po prostu nasza grupa docelowa dysponuje w zdecydowanej większości nowoczesnym i wydajnym sprzętem (przykładem może być TikTok lub Instagram).

Użyciem frameworka powinno być świadomą decyzją, a nie podążaniem za najnowszym trendem lub ulubioną technologią. Zanim zdecydujemy się sięgnąć po jeden z nich, warto jest zadać sobie kilka pytań:

• Czy zastosowanie tej biblioteki wpłynie pozytywnie na użytkowników i dostępność strony?

• Czy mogę stworzyć to samo, stosując progressive enhancement?

• Czy benefity wynikające z użycia frameworka są większe niż potencjalne problemy?

Oczywiście progressive enhancement nie jest wolny od wad. Jednym z głównych argumentów przemawiających na jego niekorzyść jest Developer Experience (DX) i produktywność programistów, a co za tym idzie koszty tworzenia strony i aplikacji internetowych. Trudno się z tym stwierdzeniem nie zgodzić - większość frameworków zapewnia proste API (przynajmniej na początku, gdy nie napotkaliśmy jeszcze żadnych problemów) i pozwala na bardzo szybkie i przyjemne budowanie kolejnych projektów.

W tym miejscu warto zaznaczyć, że frameworki i meta-frameworki również zaczęły stosować progressive enhancements, co w połączeniu z SSR lub komponentami serwerowymi może mieć pozytywny wpływ na UX i Core Web Vitals. Nasuwa się jednak pytanie, czy do tego, wydawałoby się, prostego zadania, rzeczywiście potrzebujemy tak rozbudowanego frameworka? Czy zapewni on wydajność porównywalną z renderowaniem po stronie serwera bez użycia frameworka?

React zapoczątkował nową erę w świecie frontendu, którą dzisiaj znamy pod nazwą Web 2.0. Aplikacje zaczęły być znacznie bardziej rozbudowane, interaktywne i responsywne. Biblioteki, które początkowo były proste, zapewniały przejrzysty interface i nie ważyły wiele, zaczęły rosnąć, a cenę za ten dynamiczny rozwój zaczęli płacić użytkownicy końcowi.

W dzisiejszych czasach większość ruchu w internecie pochodzi z urządzeń mobilnych, które z natury są mniej wydajne  od komputerów stacjonarny i laptopów. Nie dysponują również tak szybkim łączem internetowym i często posiadają ograniczoną ilość danych, które mogą pobrać. Jeżeli połączymy to aplikacjami w pełni opartymi na JavaScript, które wymagają pobrania niemałej ilości kodu, a następnie wykonania go, by użytkownik zobaczył treść na ekranie, to otrzymamy wyjątkowo wolną i nieresponsywną aplikację.

Oczywiście rozmiar bibliotek różni się znacznie. Przykładowo Vue zajmuje około 125kb, a po minifikacji i kompresji (gzip), wartość ta spada do 45kb. Bundlephobia świetnie obrazuje ten przykład:

Rozmiar frameworka Vue i czas jego pobierania według Bundlephobia.com

Do tej liczby należy doliczyć również kod napisany przez nas, a także inne biblioteki, które stosujemy w projekcie. Vue często idzie w parze z Pinia (biblioteka do zarządzania globalnym stanem aplikacji), która zajmuje dodatkowe 7.7kb po minifikacji i kompresji. Dodajmy do tego również Vue-router, a całość zwiększy się o kolejne 12.6kb. Pamiętać należy również, że po przesłaniu do klienta, ten kod trzeba poddać “dekompresji”, co również zajmuje dodatkowe milisekundy.

Zazwyczaj przyjmuje się, że górną granicą dla przesłanego kodu powinno być  300-500kb, choć niektóre źródła podają nawet 200kb jako ideał. Przyjmijmy jednak, że nasz kod waży około 400kb. Sieć 3g (przyjmując zakres prędkości 1.1 - 20mb/s) potrzebuje od ~0.5s do ~2.5s (w zależności od dokładnej prędkości) by pobrać ten plik. Kolejny krok to dekompresja i wykonanie kodu. Nierzadko trzeba również pobrać dodatkową zawartość, taką jak obrazki, czy czcionki. Może się zatem okazać, że użytkownik z wolniejszym połączeniem lub ktoś, kto znajduje się w miejscu bez dostępu do szybkiego internetu, będzie czekać kilka sekund nim zobaczy naszą aplikację. Niestety te kilka sekund może decydować o tym, czy skorzysta z naszego serwisu, czy opuści go niezadowolony.

Wróćmy jednak do głównego wątku. Skąd właściwie wziął się termin WebUI 2.0? Do tej pory powiedzieliśmy sobie jedynie o Web 2.0, który w dużej mierze zawdzięczamy Reactowi. Pozostało zatem pytanie: jaki związek ze sobą mają oba te terminy? Żeby to zrozumieć, wyjaśnijmy sobie pierwszych z nich. 

Za WebUI 2.0 odpowiada zespół odpowiedzialny za przeglądarkę internetową Edge. Nie będziemy się tu jednak skupiać na samej przeglądarce, a raczej na niedawnych zmianach, które w niej zaszły.

Wiele przeglądarek internetowych wykorzystuje technologie webowe (HTML, CSS, JavaScript) do tworzenia niektórych elementów interface’u. Przykładami mogą być zakładki, strona główna i wiele innych. Zazwyczaj są to po prostu treści, które można wyświetlić w ten sam sposób, co zwykłą stronę internetową. Microsoft (Edge) wykorzystywał React do wyświetlania tych właśnie miejsc.4

Od wersji 122 widzimy jednak sporą zmianę. Jeden z członków zespołu odpowiedzialnego za tę przeglądarkę, Alex Russel podzielił się informacją, że aktualnie są na etapie przepisywania funkcjonalności opartych na React, a wybraną tym razem technologią jest HTML oraz Web Components. W tym samym wpisie wspomniał także o znacznym zwiększeniu wydajności UI w miejscach w których ta zmiana już się dokonała.

Na blogu przeglądarki Edge możemy również znaleźć artykuł w którym pojawiają się takie wartości jak 42% szybszy UI dla wszystkich użytkowników oraz 76% szybszy UI dla użytkowników z mniej wydajnym sprzętem (bez dysku SSD i poniżej 8gb RAM). Liczby te brzmią naprawdę imponująco, a autorzy wpisu mówią o początku nowej ery w kwestii tworzenia aplikacji internetowych.

Jakby tego było mało, otwarcie nawołują do porzucenia frameworków i “Renderowania UI tak, jak to być powinno”, czyli za pomocą HTML i CSS. Deklarują też, że są aktualnie na etapie przepisywania pozostałych części przeglądarki i wkrótce zupełnie odetną się od Reacta.

Sam termin WebUI 2.0 ma symbolizować początek zmian podobnych do tych, które spowodował kiedyś React. Microsoft proponuje nam powrót do HTMLa i DOM API obiecując przy tym zysk w postaci niższych czasów renderowania stron. Warto w tym miejscu zwrócić uwagę, że w czasie dziesięcioletniej dominacji Reacta, kolejne specyfikacje dodawały coraz to więcej funkcjonalności do API dostępnych w przeglądarkach. Wielu programistom te zmiany mogły umknąć z uwagi na niemal całkowite przejęcie rynku przez frameworki. 

Dziś przeglądarki oferują znacznie więcej możliwości niż kilka lat temu. Historia zna już przypadki frameworków takich jak jQuery, które przestały być niemal zupełnie wykorzystywane w nowoczesnych aplikacjach internetowych, właśnie przez rozwój API dostępnych dla programistów z poziomu samego JavaScriptu, bez wykorzystywania zewnętrznych rozwiązań. Czy taki los czeka również pozostałych przedstawicieli tego gatunku? Na odpowiedź musimy jeszcze poczekać.

Gdybym musiał odpowiedzieć na pytanie postawione w tytule artykułu jednym słowem, to odpowiedziałbym NIE. Jest zbyt wcześnie by stwierdzić, że frameworki odchodzą w zapomnienie. Większość komercyjnych projektów wciąż wykorzystuje jeden z nich i prawdopodobnie nie zmieni się to zbyt szybko lub nie zmieni się w ogóle. Kluczową rolę odgrywa tu przeznaczenie projektu oraz jego grupa docelowa - strony i aplikacje rządowe powinny być dostępne dla każdego i działać niezależnie od urządzenia, natomiast aplikacje komercyjne są nastawione na jak najszybszy zysk i nie przywiązują tak dużej wagi do dostępności i wydajności.

Niemniej jednak rok 2024 przyniósł zauważalne zmiany w nastawieniu programistów do frameworków i wysokiego poziomu abstrakcji. Widać to przede wszystkim po spadających ocenach najpopularniejszych bibliotek, a także po wielu głosach krytyki w social mediach. Od frameworków zaczęły się również odwracać wielkie firmy, a efektem jest znaczne poprawienie wydajności.

Nie zmienia to faktu, że poszukując pracy nadal należy umieć przynajmniej jeden framework. Wspomina o tym niemal każda oferta pracy, dodając przy tym, że znajomość większej liczby będzie plusem. Nie oznacza to wcale, że należy pominąć naukę i zrozumienie DOM API lub Web Components, ponieważ może się okazać, że jesteśmy świadkami czegoś, co w przyszłości będzie można określić jako renesans DOM API. Żeby jednak móc to stwierdzić, przyjdzie nam jeszcze trochę poczekać.