Świat web developmentu spędził większą część dekady na przekonywaniu samego siebie, że to przeglądarka powinna wykonywać najcięższe zadania. Zaczęliśmy od dokumentów i formularzy, a następnie stopniowo przenosiliśmy każdą możliwą operację na klienta. Routing, zarządzanie stanem, pobieranie danych, logika renderowania, a nawet orkiestracja zapytań do bazy danych poprzez GraphQL — wszystko to trafiło do pakietów JavaScript, które stawały się coraz cięższe z każdym wydaniem. Liczba frameworków rosła, potoki budowania (build pipelines) stawały się coraz bardziej złożone, a to, co zaczęło się jako sposób na zapewnienie aplikacji responsywności, zmieniło się w architekturę, w której strona nie mogła wyrenderować ani jednego znaczącego piksela, dopóki megabajty kodu nie zostały pobrane, przeanalizowane i wykonane.
Ta zmiana rozwiązała realne problemy. Strony renderowane po stronie serwera z odrobiną jQuery miały trudności z zapewnieniem płynnych, przypominających aplikacje przejść, których oczekiwali użytkownicy. Aplikacje typu Single Page Application (SPA) dały nam natychmiastową nawigację, trwały stan i bogate interakcje. Jednak koszt tych rozwiązań rósł. Zespoły muszą teraz zarządzać złożonymi magazynami stanu po stronie klienta, uporać się z ogromnymi pakietami JavaScript, utrzymywać kapryśne warstwy synchronizacji danych i debugować potoki budowania, które czasem wydają się osobnym, pełnoetatowym zajęciem. Zamieniliśmy jeden zestaw problemów na inny i wielu programistów zadaje sobie teraz pytanie, czy każda aplikacja musi płacić ten podatek.
Istnieją dwa kierunki rozwoju, które ułatwiają odpowiedź na to pytanie.
HTMX i powrót hipermediów
Pierwszym z nich jest HTMX. Na pierwszy rzut oka wygląda jak mała biblioteka, ale jego implikacje architektoniczne są ogromne. HTMX traktuje HTML jako natywny format logiki aplikacji, zamiast traktować go jako statyczną powłokę, którą JavaScript musi „nadmuchać”.
Oto co zmienia się w praktyce. Tradycyjnie, gdy użytkownik klika przycisk, aby załadować więcej komentarzy, frontend wysyła żądanie fetch, otrzymuje ładunek JSON, normalizuje go w magazynie po stronie klienta, przepuszcza przez szablon komponentu, wykonuje diff na wirtualnym DOM, a na końcu aktualizuje (patchuje) stronę. HTMX skraca ten łańcuch. Sam przycisk zawiera atrybuty, które informują przeglądarkę, dokąd wysłać żądanie i który element strony zastąpić. Serwer zwraca fragment HTML — tylko nowe komentarze, zamknięte w znaczniku div. Przeglądarka podmienia go w miejscu. Nie ma JSON-a, nie ma drzewa stanu frontendu, nie ma algorytmu uzgadniania (reconciliation) ani imperatywnego JavaScriptu, który musiałby synchronizować interfejs z serwerem.
Nie jest to odrzucenie nowoczesnego rozwoju. To odrzucenie zbędnej abstrakcji. HTMX udowadnia, że hipermedia — styl architektoniczny, który napędzał wczesny web — wciąż mogą wspierać zaawansowane interfejsy, gdy zostaną połączone z nowoczesną ergonomią. Każdy element może wysyłać żądania, nie tylko formularze i linki. Każde zdarzenie może wyzwolić aktualizację. Serwer pozostaje źródłem prawdy (source of truth) zarówno dla danych, jak i dla prezentacji.
Deklaratywne częściowe aktualizacje w Chrome
Drugi trend jest nowszy i znajduje się bezpośrednio w przeglądarce. Chrome wprowadza funkcję Declarative Partial Updates (DPU). Funkcja ta pozwala przeglądarce strumieniować HTML i wstawiać go bezpośrednio do wybranych części strony w miarę napływania bajtów.
Przed wprowadzeniem DPU, jeśli chciałeś strumieniować dane na żywo do strony internetowej, zazwyczaj sięgałeś po WebSockets, Server-Sent Events lub long-polling w połączeniu z manualną manipulacją DOM. Frontend musiał zarządzać połączeniem, analizować ładunek i decydować dokładnie, jak i gdzie wstrzyknąć znaczniki. DPU zmienia tę sytuację, czyniąc proces deklaratywnym. Programista określa docelowy kontener, a przeglądarka zajmuje się resztą: odbieraniem strumienia, analizą fragmentu i umieszczeniem go dokładnie tam, gdzie powinien, nawet zanim pełna odpowiedź zostanie zamknięta.
Wyobraźmy sobie panel monitorujący wyświetlający logi serwera lub kolejkę wsparcia aktualizującą się w czasie rzeczywistym. Dzięki DPU backend wysyła zwykłe fragmenty HTML w miarę ich generowania. Przeglądarka strumieniuje je do ciała tabeli lub kontenera kanału informacyjnego bez ani jednej linii logiki strumieniowania po stronie klienta. Montaż odbywa się natywnie.
Model Server-First
Łącząc HTMX i DPU, otrzymujemy spójną architekturę, w której serwer zarządza stanem i generuje interfejs użytkownika, podczas gdy przeglądarka zajmuje się wyświetlaniem i obsługą wejścia użytkownika. Frameworki backendowe, takie jak Rails, Laravel, Django, szablony Go czy ASP.NET, ponownie stają się główną warstwą interfejsu. Frontend nie jest osobną aplikacją konsumującą API. Jest interfejsem hipermediów, który produkuje serwer.
This model fits a surprisingly wide slice of software. Consider the typical SaaS application. It is dashboards with sortable tables. It is admin panels with forms and filters. It is internal tools that move records from one state to another. It is CRUD workflows that show a list, expose a detail view, and let the user edit fields. It is even AI interfaces where a language model streams tokens back to the user, and each token or paragraph can be wrapped in HTML and appended to the conversation thread. For all of these, a thick JavaScript client is often overkill.
The benefits are immediate and practical. Initial page loads are faster because the first meaningful paint arrives as HTML, not after a hydration cycle completes. JavaScript payloads shrink because there is no virtual DOM, no client-side router, and no state management library to ship. Search engines see complete content without executing bundles, so SEO works by default. Complexity drops because one codebase handles routing, business logic, and rendering. Debugging gets easier. When something looks wrong, you inspect the Network tab and see exactly what HTML the server sent. There is no opaque client-side state object to reverse-engineer.
What About React and Heavy Clients?
None of this means React is dead, or that SPAs are a mistake. Complex, editor-grade applications still need a thick client. Figma runs a C++ engine compiled to WebAssembly inside the browser because server round-trips would make drawing impossible. Canva manipulates the canvas at sixty frames per second with client-side geometry. Google Docs uses operational transforms to resolve editing conflicts in milliseconds. These tools are essentially desktop applications delivered through a browser tab. They are not going back to server-rendered forms.
But most software is not Figma. Most software is not a real-time graphics editor. Most software is a reporting screen, a configuration panel, a booking flow, or a content management form. For that long tail of applications, shipping hundreds of kilobytes of JavaScript framework just to toggle a modal or fetch a list of records never made much sense. The economics of the stack are shifting. We are rediscovering that the server can be close to the user thanks to the edge, and that the browser itself has grown capable enough to update fragments without a framework intermediating every byte.
The Pendulum Finds a Balance
The arc of web architecture is swinging back toward simplicity, but it is not a naive return to the nineties. The browser is becoming smarter. Features like DPU do not replace developer ingenuity; they absorb the patterns we used to implement by hand — streaming, partial updates, targeted DOM insertion — into the platform itself. HTMX gives us the vocabulary to express those behaviors without reconstructing a miniature operating system in the frontend.
You no longer have to choose between a simple architecture and a responsive user experience. You can have both. The server can drive the interface, the browser can assemble it, and the JavaScript you write can focus on genuine interactivity rather than plumbing.
For the next generation of dashboards, admin tools, and AI-powered interfaces, the smartest client might be the one that does less.