Napisz do nas

React czy HTMX. Co wybrać do aplikacji z agentami AI

AI i Automatyzacje • Łukasz Ślusarski Łukasz Ślusarski • • 18 min czytania
React czy HTMX. Co wybrać do aplikacji z agentami AI

Do panelu, formularzy i stron publicznych wystarczy renderowanie HTML na serwerze z HTMX i odrobiną JavaScriptu. React z Next.js ma sens, gdy ekran jest ciężki interaktywnie albo zespół już zna React. W jedynym znalezionym benchmarku agenta AI stack Hono z htmx wyszedł najtaniej, ale zbudowano w nim jedną prostą aplikację.

Łukasz Ślusarski, important.is. Stan na 11 listopada 2026. Opracowane na podstawie benchmarku Nolana Lawsona z 28 października 2026, dokumentacji Next.js i htmx oraz ankiet State of JS i Stack Overflow.

Agent AI napisze frontend w prawie każdej technologii. Dlatego pytanie brzmi inaczej niż kiedyś: co z tym kodem będzie za pół roku, kiedy trzeba go przeczytać w pull requeście, zaktualizować zależności i dopisać kolejny ekran. Ten tekst jest dla osób i firm, które budują aplikacje z agentami i trzymają je na GitHubie. U nas portal klienta jest w Next.js 16, a Sherpa ma od 11 listopada 2026 plan przejścia z czystego JavaScriptu na React (opis na końcu).

To jedyny artykuł w serii z pełnym omówieniem Next.js. Wybór backendu i bazy opisuję w tekście o backendzie i bazie, bezpieczeństwo w osobnym tekście o bezpieczeństwie kodu z AI, a hosting w artykule o hostingu i wdrażaniu. Całość składa się na przewodnik po stacku do aplikacji z AI.

W skrócie: React czy HTMX

KryteriumReact z Next.jsSSR + HTMX + lekki JS
Pasuje doEkranów ciężkich interaktywnie, zespołu znającego React, gotowych bibliotek komponentówFormularzy, list, paneli, stron publicznych, treści
Co dokłada do projektuKrok budowania, granicę serwer i klient, hydratacjęSzablony na serwerze i jeden plik JavaScript
Pobrania npm tygodniowo (4 do 10.11.2026)React 253 162 799, Next.js 92 077 869htmx 433 923
Benchmark agenta (mediana kosztu, 5 przebiegów)Next.js 3,14 USD, 1539 liniiHono z htmx 2,67 USD, 1370 linii
JavaScript wysłany na stronę główną w benchmarkuNext.js 142 KiBHono z htmx 18 KiB
Główne ograniczeniaZłożoność, luki w warstwie serwerowej, pilnowanie wersjiDostępność po podmianie fragmentów, formularze wielokrokowe, brak komponentów w stylu shadcn

Poniżej rozpisuję, skąd te liczby, co z nich wynika i gdzie są granice. Opinie zaznaczam jako opinie.

Pogadajmy

Zrobić to razem?

Wdrażam takie rzeczy w firmach na co dzień. Umów 30 minut, pogadamy konkretnie o Twoim przypadku. Bez prezentacji sprzedażowej.

Umów bezpłatną rozmowę →
Łukasz Ślusarski
Łukasz ŚlusarskiTwórca important.is

Co mówią dane o popularności Reacta i HTMX?

React jest najczęściej używanym frameworkiem frontendowym, a htmx niszą. W ankiecie State of JS 2025 React miał 83,6% użycia, a Next.js 59%, przy czym o Next.js 21% opinii było pozytywnych i 17% negatywnych (InfoQ, 20.03.2026). W Stack Overflow Developer Survey 2025 React miał 44,7% wszystkich respondentów, a Next.js 20,8%. Htmx miał tam w 2024 roku 3,3%, a w 2025 pojawia się już tylko w polu własnych odpowiedzi (0%), więc trendu nie da się policzyć. W npm w tygodniu od 4 do 10 listopada 2026 pobrano React 253 162 799 razy, Next.js 92 077 869 razy, a htmx 433 923 razy, czyli React ma około 580 razy więcej. Te liczby opisują rynek i łatwość znalezienia ludzi, a nie to, czy technologia pasuje do jednej aplikacji. Przypuszczam, że pobrania npm niedoszacowują htmx, bo często ładuje się go jednym plikiem, ale tego nie mierzyłem.

Wykres pokazuje różnice w skali logarytmicznej, inaczej słupek htmx byłby niewidoczny.

Wykres słupkowy: tygodniowe pobrania z npm dla Reacta, Next.js, Vue, Astro, Svelte, Turbo, Alpine.js i htmx, stan z 11 listopada 2026

Mała skala nie oznacza porzuconego projektu. Htmx 4.0.0 wyszedł 28.08.2026, a 4.0.1 dnia 1.11.2026. Wersja 2.0.11 ukazała się 22.09.2026. Alpine.js ma wydanie 3.17.5 z 20.10.2026. Turbo z Hotwire ma ostatnie wydanie 8.0.23 z 29.01.2026. Repozytorium htmx ma 49 630 gwiazdek, Next.js 143 468, a React 252 562 (GitHub API, 11.11.2026).

Czy agenci AI lepiej piszą w Reakcie czy w HTMX?

Jedyny znaleziony pomiar to benchmark Nolana Lawsona z 28.10.2026. Agent Claude Code budował tę samą aplikację z PokéAPI (lista z wyszukiwaniem i filtrami) na 12 stackach, po 5 przebiegów na każdy. Najtańszy był Hono z htmx: mediana 2,67 USD i 1370 linii kodu. Next.js wyszedł 3,14 USD i 1539 linii, React Router 3,81 USD, a Angular 4,97 USD i 2009 linii, przy czym w 2 z 5 przebiegów Angular nie dał działającej aplikacji. Koszt to szacunek według cen API, nie faktyczny wydatek. Trzy najtańsze stacki mieszczą się w granicy błędu. Hono z htmx potrzebowało mediany 8,6 minuty i 4,26 mln tokenów, Next.js 10,9 minuty i 4,99 mln tokenów. Każdy wynik to mediana z pięciu przebiegów. Autor zastrzega, że aplikacja jest bogata w treść i uboga w interakcje, mierzył tylko stronę główną w Chromium, a koszty to ceny API, nie faktyczny wydatek, i nie traktuje wyniku jako rozstrzygnięcia.

Wykres niżej to cała tabela kosztów z tego benchmarku.

Wykres słupkowy: mediana kosztu zbudowania tej samej aplikacji przez agenta AI w 12 stackach, od Hono z htmx za 2,67 USD do Angulara za 4,97 USD

Różnica między Next.js a Hono z htmx to 0,47 USD na przebieg i 169 linii kodu. To nie jest przepaść. Większa różnica jest w wadze strony: Next.js wysłał na stronę główną 142 KiB JavaScriptu, a Hono z htmx 18 KiB. Czas LCP wyniósł 2090 ms i 978 ms (telefon emulowany, wolna sieć 4G, procesor spowolniony czterokrotnie). Lawson zaznacza jednak, że LCP bywa niestabilny między przebiegami (dla Next.js od 1028 do 2187 ms), a ocenił tylko stronę główną w Chromium.

Gumroad pisał we wrześniu 2024, że htmx ma słabsze wsparcie narzędzi AI. To opinia jednego zespołu, a w prostej aplikacji agent z htmx poradził sobie w każdym z pięciu przebiegów. Czy tak będzie przy złożonych ekranach, nie znalazłem danych.

Wolisz to zlecić? 30 minut, bez zobowiązań. Sprawdzimy czy to ma sens.
Zarezerwuj termin →

Czym jest Next.js i co dokłada do Reacta?

Next.js to framework oparty na Reakcie, który dokłada routing, renderowanie na serwerze i budowanie aplikacji w jednym projekcie. Dokumentacja Reacta zaleca dziś zaczynać nowe aplikacje od frameworka, a na liście są Next.js z App Routerem, React Router 7 i Expo. W App Routerze strony i layouty są domyślnie Server Components: renderują się na serwerze, pobierają dane z bazy lub API i nie wysyłają swojego kodu do przeglądarki. Interaktywność dokładasz w plikach z dyrektywą "use client", a taki plik razem ze wszystkim, co importuje, trafia do paczki przeglądarki. Nawigacja korzysta z RSC Payload, czyli zserializowanego drzewa komponentów, które React łączy z istniejącym DOM. Pakiet server-only pilnuje, żeby kod serwerowy nie trafił do klienta. Hydratacja to moment, w którym React podpina obsługę zdarzeń do wyrenderowanego HTML. Aktualne wersje z registry npm: Next.js 16.4.6 z 9.11.2026 i React 19.3.1 z 14.10.2026.

W tym modelu w jednej aplikacji istnieją dwa środowiska, a granicę między nimi trzeba pilnować. Dokumentacja każe na przykład używać pakietu server-only, żeby klucz API nie trafił przypadkiem do kodu klienta, a propsy przekazywane do komponentów klienta muszą dać się serializować.

Samodzielny hosting opisuje poradnik Next.js (aktualizacja 15.10.2026): serwer Node.js, obraz Docker albo eksport statyczny. Dokumentacja zaleca reverse proxy przed serwerem. Domyślny cache leży na dysku jednej instancji, więc przy kilku instancjach trzeba skonfigurować wspólny cache handler (przykład z Redisem), ten sam klucz szyfrowania Server Functions i identyfikator wdrożenia. Przy streamingu trzeba wyłączyć buforowanie w proxy. Moim zdaniem to jest cena frameworka: każda z tych rzeczy to konfiguracja, którą ktoś musi utrzymać. Ceny hostingu porównuję w artykule o hostingu.

Jakie ryzyka ma Next.js w utrzymaniu?

Ryzyko to głównie tempo zmian i luki w warstwie serwerowej. Dwa głośne przykłady z GitHub Advisory Database: CVE-2025-29927, obejście autoryzacji w middleware Next.js (CVSS 9,1, opublikowane 21.03.2025, poprawki między innymi w wersjach 15.2.3, 14.2.25 i 13.5.9), oraz CVE-2025-55182, zdalne wykonanie kodu w React Server Components (CVSS 10,0, opublikowane 3.12.2025, poprawki w 19.0.1, 19.1.2 i 19.2.1 pakietów react-server-dom). Nie porównywałem liczby luk z htmx, więc to nie dowód, że htmx jest bezpieczniejszy. To przykład kosztu bycia na bieżąco: repozytorium Next.js publikuje wydania canary codziennie (46. i 47. z 9 i 10 listopada 2026), a agent, który dopisuje kod, nie zastąpi człowieka pilnującego wersji. Obie luki dotyczyły warstwy serwerowej frameworka, nie kodu aplikacji, więc naprawia je dopiero aktualizacja zależności. Poprawki ukazały się w kilku liniach wersji naraz. Szczegóły łatania i sekretów są w artykule o bezpieczeństwie kodu z AI.

Ankietowani w State of JS 2025 mieli podobne obawy, tylko w innym języku. Jedna osoba z sześcioletnim stażem produkcyjnym napisała, że złożoność Next.js stała się absurdalna, inni obawiali się motywów biznesowych Vercela (InfoQ, 20.03.2026). To opinie respondentów, nie liczby o skali odejść, a takich liczb nie znalazłem.

Kiedy HTMX wystarcza, a kiedy przestaje?

Htmx to biblioteka JavaScript bez zależności, która podmienia fragmenty strony odpowiedziami HTML z serwera, więc logika zostaje w szablonach i handlerach. Autor htmx opisuje, kiedy to działa: aplikacje głównie z tekstu i obrazów, CRUD z formularzami, zagnieżdżone interfejsy, w których aktualizacje dotyczą wydzielonych bloków, oraz głębokie linki. Nie poleca go do interfejsów z wieloma dynamicznymi zależnościami (arkusz), pełnej pracy offline, bardzo częstych aktualizacji (ruch myszy) ani tam, gdzie chcesz używać gotowych komponentów w stylu shadcn, bo te są związane z Reactem. Dokumentacja dodaje jedno ograniczenie: jeśli wpychasz adres do historii przeglądarki, serwer musi pod nim zwrócić pełną stronę. Serwer może być napisany w dowolnym języku, bo odpowiada zwykłym HTML. Dokumentacja opisuje htmx jako bibliotekę bez zależności, więc jeden plik można trzymać w repozytorium obok kodu. Nie znalazłem w dokumentacji podanego rozmiaru pliku, więc go nie podaję. Zastrzeżenie: to opis autora narzędzia, więc źródło zainteresowane.

Najbliższy dowód liczbowy to port Contexte z Reacta na htmx, opisany przez Carsona Grossa. Kod spadł z 21 500 do 7 200 linii, zależności JavaScript z 255 do 9, czas budowania z 40 do 5 sekund, a czas do interaktywności ze strony z 2 do 6 sekund na 1 do 2 sekund. Gross pisze wprost, że to aplikacja treściowa i nie oczekuje takich wyników od każdej.

Dostępność wymaga pracy ręcznej. W analizie Wagtail z kwietnia 2025 mediana wyniku dla stron Django z htmx wyniosła 85, dla wszystkich stron Django 83, a dla Reacta 81, więc htmx nie wypadł gorzej. Ten sam tekst ostrzega przed utratą fokusu po podmianie elementów i przed hx-boost, który nie zarządza pozycją czytnika ekranu. Próba htmx to 500 stron, a to opis korelacji, nie przyczyn.

Wersja 4.0.0 przenosi SSE i WebSockety do rozszerzeń i zmienia nazwy części atrybutów i zdarzeń. Na npm tag latest to wciąż 2.0.11, a 4.0.1 jest pod tagiem next. Wersję przypnij świadomie i trzymaj plik w repozytorium.

Kiedy React wygrywa mimo wszystko?

React wygrywa przy ekranach, na których stan klienta jest głównym zadaniem, i tam, gdzie zespół potrzebuje gotowych komponentów. Gumroad (Sahil Lavingia, 30.09.2024) wybrał React i Next.js dla projektu Helper. Jako powody podał złożone formularze z dynamiczną walidacją i polami warunkowymi, zmieniające się formularze generowane z kroków oraz przeciąganie elementów, które w htmx wymagało dużo własnego JavaScriptu. Dodał też, że usługi zewnętrzne częściej mają bindingi do Reacta niż do htmx. To opinia zespołu, który znał oba podejścia, ale nie benchmark. Lavingia zaznacza, że wybór dotyczył jednego produktu, nie wszystkich. Gotowe biblioteki komponentów, takie jak shadcn, powstały pod React. Jeśli twój najcięższy ekran przypomina któryś z tych przykładów, wyspa Reacta jest bezpieczniejsza niż odtwarzanie go w szablonach. Tych powodów nie da się przenieść na każdy projekt: formularze z polami warunkowymi i przeciąganie to konkretne ekrany, a nie cała aplikacja.

Przykład z drugiej strony skali to GitHub. Zakładka Files changed została przeniesiona z widoku Rails na React, a potem zespół optymalizował już reactową wersję: przy skrajnych pull requestach sterta JavaScriptu przekraczała 1 GB, a drzewo DOM 400 tysięcy węzłów (GitHub Engineering, 3.04.2026). Strony Issues GitHub przenosi z Rails na React etapami i nie porzucił Turbo: skrócenie mediany czasu nawigacji z około 1200 do 700 ms przyniosły dołożone warstwy cache, preheating i service worker (14.05.2026). To hybryda, nie dowód, że warto przepisywać całość.

Wniosek, moim zdaniem: jeśli ciężki jest jeden ekran, osadź na nim wyspę Reacta zamiast przepisywać aplikację. Autor htmx też mówi, że wybór nie jest „wszystko albo nic”.

Co zmienia się w utrzymaniu kodu z AI na GitHubie?

Różnice w utrzymaniu dotyczą głównie liczby warstw i zależności, a nie liczby linii. W benchmarku Lawsona Next.js miał 1539 linii, a Hono z htmx 1370, więc w prostej aplikacji rozmiar kodu jest zbliżony. Różnicę widać w zależnościach: Contexte zeszło z 255 do 9 pakietów JavaScript, a dokumentacja htmx opisuje bibliotekę jako dependency-free. Wpis o Rails 8 (7.11.2024) mówi o „nowym świecie #NOBUILD” i o Propshaft jako domyślnym potoku zasobów, więc podejście bez kroku budowania ma poparcie dużego frameworka. Każda zależność to coś, co trzeba aktualizować, a narzędzia do przeglądu kodu agenta opisuję w tekście o testach, review i CI. Bez kroku budowania agent i człowiek pracują na krótszym łańcuchu narzędzi, a każde ogniwo tego łańcucha może się zepsuć przy aktualizacji. Ile czasu to oszczędza, nie znalazłem w żadnym źródle.

Moja opinia, bez pomiaru: przy podejściu serwerowym diff agenta zwykle zawiera szablon i handler, które czyta się obok siebie, a w Next.js trzeba dodatkowo sprawdzić, po której stronie granicy kod działa. Moja rada: zapisz w pliku dla agenta, gdzie mieszka logika i jak uruchomić testy, bo to zmienia czytelność diffu bardziej niż wybór frameworka. Mniejsza liczba zależności to też krótsza lista aktualizacji do przejrzenia. Każdy pakiet to potencjalny pull request, a każdy pull request ktoś musi przeczytać i przetestować. Nie mierzyłem tego, więc traktuj to jako rozumowanie, nie wynik. Jeśli agent dopisuje zależności bez pytania, warto to ograniczyć w jego instrukcji. Fragmenty HTML testuje się zwykłymi testami HTTP, a zachowanie JavaScriptu testem e2e. To moje przekonanie, nie wynik badań.

W benchmarku agent z Next.js czytał plik AGENTS.md w 2 z 5 przebiegów. Jak taki plik napisać, opisuję w artykule o AGENTS.md i CLAUDE.md.

Jak wybrać frontend do aplikacji z AI?

Zacznij od ekranu, nie od frameworka. Jeśli najcięższy ekran to edytor, arkusz, przeciąganie albo praca offline, potrzebujesz Reacta lub innego frameworka komponentowego, najlepiej jako wyspy w aplikacji serwerowej. Jeśli to formularze, listy, panele i strony publiczne, zacznij od renderowania na serwerze i htmx oraz małych wysp JavaScriptu. Jeśli to głównie treści, Astro w benchmarku wysłał na stronę główną 0 KiB JavaScriptu i miał LCP 810 ms, najlepszy wynik w zestawieniu. Zespół już znający React z biblioteką komponentów powinien zostać przy Reakcie, bo czynnik ludzki waży tyle samo co techniczny: React pobrano w tydzień ponad 253 mln razy, więc ludzi i bibliotek jest najwięcej. Dla jednej osoby z prostym panelem ten argument waży mniej. Wybór zależy od ekranów, nie od mody ani od liczby gwiazdek. To moja rekomendacja, oparta na źródłach z artykułu, a nie reguła z badań.

Schemat zbiera te pytania w jednym miejscu.

Schemat decyzyjny: czy ekran jest ciężki interaktywnie, czy zespół zna React, czy to formularze i panele, prowadzący do React lub Next.js, hybrydy, SSR z HTMX albo Astro

Niezależnie od wyboru agent potrzebuje testów i człowieka, który czyta diff. Stack tego nie zastąpi. Pozostałe decyzje (baza, architektura, hosting) są w pozostałych artykułach serii.

Czego to nie rozwiąże i kiedy ten wybór jest zły?

HTMX będzie złym wyborem, gdy aplikacja ma zachowywać się jak arkusz albo edytor graficzny, gdy musi działać offline albo gdy zespół opiera się na bibliotekach komponentów dla Reacta. Next.js będzie złym wyborem, gdy aplikacja to kilka formularzy i listy, a nikt nie chce utrzymywać konfiguracji cache, kluczy i wersji przy kilku instancjach. Obie ścieżki zawiodą, jeśli kod z agenta nie jest przeglądany i testowany, bo żaden stack tego nie naprawia. Jeśli ekran łączy oba światy, na przykład panel z edytorem tabeli, trzymaj stronę po stronie serwera, a edytor osadź jako wyspę Reacta z własnym stanem. Żaden benchmark nie mierzył takiej hybrydy, więc to moja ocena na podstawie opisów GitHuba i autora htmx. Moim zdaniem wybór da się cofnąć, bo szablony i logika serwerowa nie przepadają, gdy zmienisz warstwę widoku. Moim zdaniem brak testów boli częściej niż wybór frameworka.

Czego tu nie sprawdzałem: benchmark Lawsona dotyczy jednej prostej aplikacji, jednego modelu i przeglądarki Chromium, a ja nie znalazłem porównania dla złożonych ekranów ani niezależnych danych o długoterminowym utrzymaniu. Nie badałem też Phoenix LiveView, Livewire ani Datastar jako osobnych opcji.

Co robimy z frontendem w naszych aplikacjach?

Portal klienta to Next.js 16 z Reactem 19 i Tailwindem 4. Sherpa, nasz klient poczty w przeglądarce, zaczęła się inaczej: czysty JavaScript bez kroku budowania, z głównym plikiem index.html i kilkoma plikami pomocniczymi, aplikacja PWA z IndexedDB. Od 11 listopada 2026 jest plan przepisania jej frontu na Vite, React 19, TypeScript i bibliotekę shadcn/ui. Powód zapisany w planie: gotowa biblioteka komponentów, którą dopasowujemy do naszych potrzeb. Backend zostaje bez zmian.

Ciekawsza od samej decyzji jest metoda. Nowy front rośnie obok starego pod adresem /nowa/, a miarą postępu są istniejące testy Playwright, uruchamiane na obu wersjach. Przełączenie głównego adresu następuje dopiero po przejściu testów i przeklikaniu aplikacji na telefonie, a stary front zostaje jeszcze przez dwa tygodnie. Uwaga: to dziś plan, nie wynik, więc nie oceniam jeszcze, czy przepisanie się opłaciło. Opinia: przy zmianie frontu najpierw ustal, czym zmierzysz, że nowa wersja robi to samo co stara.

Najczęstsze pytania

Czy HTMX jest lepszy od Reacta?

Nie ma jednej odpowiedzi. Dla treści, formularzy i paneli htmx jest prostszy i lżejszy, co widać w benchmarku Lawsona. Dla edytorów, arkuszy i pracy offline lepszy jest React, co przyznaje nawet autor htmx.

Czy agenci AI piszą HTMX tak dobrze jak React?

W jedynym znalezionym benchmarku agent zbudował aplikację w Hono z htmx najtaniej ze wszystkich 12 stacków, a Next.js wyszedł o 0,47 USD drożej. To była prosta aplikacja. Nie znalazłem pomiarów dla złożonych ekranów.

Czy Next.js to domyślny wybór?

Tylko jeśli już wybrałeś React. Porównanie frameworków (React, Vue, Angular, Svelte) jest w artykule Jaki framework wybrać do własnej aplikacji w 2026. Dokumentacja Reacta zaleca zaczynać od frameworka i wymienia Next.js, React Router i Expo. Nie ma tam rekomendacji, że React jest właściwy dla każdej aplikacji.

Czy React Server Components zastępują HTMX?

Rozwiązują część tego samego problemu, czyli mniej JavaScriptu w przeglądarce i dane pobierane na serwerze. Wymagają jednak frameworka z Reactem i granicy serwer i klient, a htmx działa na zwykłym HTML. To moje porównanie, nie wynik badania.

Czy HTMX działa na produkcji?

Tak, opisany jest przypadek Contexte z 2022 roku, ale pisał o nim autor htmx. Niezależnego badania produkcyjnego nie znalazłem. Wersja 4.0.0 wyszła 28.08.2026, ale na npm tag latest to wciąż 2.0.11.

Co z dostępnością w HTMX?

Wymaga ręcznej pracy: fokus po podmianie fragmentu i unikanie hx-boost, co zaleca Wagtail. W ich próbce stron Django wyniki htmx (mediana 85) nie były gorsze niż Reacta (81), ale próba jest mała.

Czy mogę zacząć od HTMX i dodać React później?

Tak. Autor htmx opisuje podejście mieszane jako normalne: złożony komponent osadzasz jako wyspę, a resztę trzymasz w HTML. GitHub w 2026 roku pokazuje podobną hybrydę po stronie Reacta i Turbo.

Źródła

Czytaj również

Stan na 11 listopada 2026. Wersje, liczby pobrań i wyniki benchmarku zmieniają się, a wnioski o utrzymaniu kodu z AI to moje opinie oparte na wymienionych źródłach, nie wyniki badań.

raz na jakiś czas

Zostań w pętli

Nowe artykuły, narzędzia i case study prosto na maila. Bez spamu, bez sprzedaży.

To pole jest używane do walidacji i powinno pozostać niezmienione.
Zgodawymagane

Czytaj również