Dlaczego doświadczeni programiści porzucają React na rzecz czystego JS i HTMX

Seniorzy nie uciekają z Reacta. Zaczęli zadawać pytanie, którego przez lata nie zadawali: czy ten konkretny problem rzeczywiście wymaga pełnego frameworka SPASPA (Single Page Application) to aplikacja webowa, w której cała strona renderuje się i działa po stronie przeglądarki w jednym dokumencie HTML — typowe podejście Reacta, Vue czy Angulara bez SSR.?

React nadal jest jednym z najważniejszych narzędzi frontendu. Zmiana polega na tym, że doświadczone zespoły przestały traktować go jako domyślną odpowiedź na każde pytanie.

Syndrom "wszystko w React"

Klasyczny problem to przyzwyczajenie. Developer uczy się jednej technologii, w tym wypadku Reacta, a potem używa go do wszystkiego - naginając jego zastosowania z powodu wygody. Landing page? React. Blog firmowy? React. Formularz kontaktowy? React + React Hook Form + Zod + Server Actions.

Efekt takiego postępowania:

• 200 KB JavaScript dla strony z trzema sekcjami,
• HydrationHydration to etap, w którym React podłącza logikę JavaScript do już wygenerowanego HTML-a w przeglądarce. delay na wolniejszych urządzeniach,
• Skomplikowany build pipeline dla prostego projektu,
• Czas developmentu 3× dłuższy niż jest to potrzebne.

Framework stał się odruchem zamiast decyzją. Senior developerzy, którzy pamiętają czasy przed React, znają koszt tego odruchu z doświadczenia.

Co oferuje HTMX?

HTMX to lekka biblioteka, która pozwala tworzyć dynamiczne interfejsy za pomocą atrybutów HTML:

<!-- Ładowanie treści bez pełnego przeładowania -->
<button hx-get="/api/users" hx-target="#user-list">Załaduj użytkowników</button>
 
<div id="user-list">
  <!-- Tu pojawi się odpowiedź -->
</div>

<!-- Formularz z AJAX submit -->
<form hx-post="/api/contact" hx-swap="outerHTML">
  <input name="email" type="email" required />
  <textarea name="message" required></textarea>
  <button type="submit">Wyślij</button>
</form>

<!-- Infinite scroll -->
<div hx-get="/api/posts?page=2" hx-trigger="revealed" hx-swap="afterend">
  Ładowanie...
</div>

W najprostszym wariancie nie musisz pisać własnego JavaScriptu do obsługi requestu, podmiany fragmentu DOM i podstawowych interakcji. Serwer zwraca HTML, a HTMX wstawia go w odpowiednie miejsce.

HTMX nie jest "Reactem, tylko prostszym". To podejście HTML-over-the-wireHTML-over-the-wire to architektura, w której serwer zwraca gotowy HTML zamiast JSON — przeglądarka podmienia fragmenty DOM bez warstwy renderowania po stronie klienta.: więcej logiki wraca na serwer, frontend staje się cieńszą warstwą interakcji. Dla jednych projektów — ogromna zaleta. Dla innych — twarde ograniczenie.

Czego HTMX nie robi za Ciebie

Ten fragment najczęściej ginie w entuzjastycznych dyskusjach. HTMX upraszcza wiele rzeczy po stronie klienta, ale złożoność z projektu nie znika — przesuwa się na serwer.

Realne koszty tego przesunięcia:

• backend musi umieć renderować sensowne fragmenty HTML, nie tylko zwracać JSON
• złożony stan klienta, optimistic UI i rozbudowane interakcje są trudniejsze niż w React
• im więcej dynamicznych sekcji, tym ważniejsza dyscyplina w nazewnictwie endpointów i fragmentów
• testy E2E i kontrakty frontend–backend nadal są potrzebne — mają tylko inną formę

HTMX wygrywa tam, gdzie interakcja jest głównie serwerowa: formularze, filtry, infinite scroll, paginacja, podmiana sekcji. Gdy interfejs zaczyna żyć własnym życiem po stronie klienta, przewaga szybko maleje.

Argumenty "pro-vanilla"

1. Przeglądarki się rozwinęły

W 2015 React rozwiązywał realne problemy:

• Brak modułów ES — teraz mamy import/export natywnie
• Brak fetch — teraz jest wbudowany
• Brak template literals — teraz są standardem
• Słabe DOM APIAPI, czyli Application Programming Interface, definiuje sposób komunikacji między aplikacjami lub modułami. Tu chodzi o konwencje plików Next.js, które zamieniają eksportowaną funkcję w gotowy plik sitemap.xml lub robots.txt. — teraz mamy querySelector, dataset, classList
• Brak komponentów — teraz mamy Web Components

// Nowoczesny vanilla JS — całkiem znośny
class UserCard extends HTMLElement {
  connectedCallback() {
    const name = this.getAttribute('name')
    this.innerHTML = `
      <div class="card">
        <h2>${name}</h2>
        <slot></slot>
      </div>
    `
  }
}
 
customElements.define('user-card', UserCard)

<user-card name="Jan Kowalski">
  <p>Frontend Developer</p>
</user-card>

2. Mniejsza złożoność = mniej bugów

React wprowadza abstrakcje:

• Virtual DOM
• Hooks i ich reguły
• State management (Context, Redux, Zustand...)
• Hydration mismatch
• useEffect cleanup hell

Każda abstrakcja to model mentalny, który zespół nosi przez cały cykl życia projektu. Przy prostych stronach i formularzach ten koszt łatwo przewyższa korzyści.

// React: 15 linii, wymaga zrozumienia hooków
function Counter() {
  const [count, setCount] = useState(0)
 
  useEffect(() => {
    document.title = `Count: ${count}`
    return () => {
      document.title = 'App'
    }
  }, [count])
 
  return <button onClick={() => setCount((c) => c + 1)}>{count}</button>
}

// Vanilla: 8 linii, zero dodatkowych abstrakcji
const button = document.querySelector('#counter')
let count = 0
 
button.addEventListener('click', () => {
  count++
  button.textContent = count
  document.title = `Count: ${count}`
})

To porównanie jest celowo uproszczone. W prawdziwej aplikacji React daje przewidywalny model komponentów, aktualizacji UI i współdzielonego stanu. Przy małej skali ten narzut potrafi być nieproporcjonalny do problemu — i to jest właśnie punkt.

3. Performance by default

React i aplikacje SPA często muszą wykonać pracę, której prosty serwer-renderowany interfejs nie potrzebuje:

• Diffing Virtual DOM
• Reconciliation
• Hydration po SSRSSR, czyli Server-Side Rendering, to generowanie HTML na serwerze przy żądaniu — komponent client:only je pomija i renderuje się wyłącznie w przeglądarce.
• Re-renders (nawet z React Compiler)

React nie jest z definicji wolny, a HTMX z definicji szybki. Dobrze zbudowany Next.js osiąga świetne wyniki, a źle zaprojektowany HTMX może generować lawinę requestów i dusić serwer. Różnica tkwi w punkcie startowym: prosty HTML z minimalnym JS łatwiej uczynić szybkim niż bogatą aplikację klientową.

4. SEO bez gimnastyki

Jeśli budujesz SPA renderowane głównie po stronie klienta, faktycznie musisz bardziej pilnować renderowania pod SEOSEO, czyli Search Engine Optimization, to optymalizacja strony pod widoczność w wynikach wyszukiwania.. Dlatego w ekosystemie React tak popularne są rozwiązania typu Next.js, SSR, SSGSSG (Static Site Generation) to generowanie kompletnego HTML podczas budowania strony. Gotowe pliki serwujesz z CDN bez renderowania na żądanie — najszybszy i najtańszy model dla treści, która nie zmienia się przy każdej wizycie. i route-level rendering.

Przy HTMX i klasycznym renderowaniu po stronie serwera punkt startowy jest prostszy: Google od razu dostaje HTML z treścią. To nie zwalnia z dbania o Core Web Vitals ani strukturę dokumentu, ale zmniejsza liczbę warstw, które mogą przeszkodzić.

Argumenty "pro-React"

React ma swoje miejsce — i jest ono duże:

Złożone UI z dużą ilością stanu

Aplikacje typu Figma, Notion, Google Docs — gdzie interakcje są skomplikowane i stan jest rozproszony. Tu React błyszczy.

Duże zespoły

React wymusza strukturę. Komponenty, props, jednokierunkowy przepływ danych — to pomaga utrzymać porządek w dużych projektach.

Ekosystem

Potrzebujesz date pickera, drag & drop, rich text editora? W React znajdziesz 10 gotowych bibliotek. W vanilla JS musisz więcej robić sam.

Rekrutacja

Znajdziesz 100 React developerów na każdego, kto zna HTMX. To ma znaczenie dla firm.

Narzędzia full-stack i ekosystem React

W praktyce React to dziś nie tylko biblioteka do widoków. To też ogromny ekosystem wokół routingu, renderowania po stronie serwera, design systemów, testów, formularzy i komponentów UI. W wielu produktach to przewaga nie do pobicia.

Trzecia droga: podejście hybrydowe

Najlepsza odpowiedź rzadko brzmi "100% React" albo "100% HTMX". W większości realnych projektów wygrywa układ mieszany:

• serwer renderuje większość HTML
• HTMX albo zwykły JS obsługują proste interakcje
• React trafia tylko tam, gdzie faktycznie potrzeba bogatego stanu i złożonego UI

Strona marketingowa może być statyczna, mieć formularz newslettera na HTMX i jeden interaktywny konfigurator w React. Taki układ daje lepszy kompromis niż wtłaczanie całego projektu w jeden paradygmat.

Dokładnie ten model formalizuje Astro — framework zbudowany wokół Islands ArchitectureIslands Architecture to wzorzec, w którym większość strony pozostaje statycznym HTML-em, a tylko wybrane interaktywne fragmenty są hydratowane w przeglądarce.. Domyślnie generuje czysty HTML bez żadnego JavaScriptu po stronie klienta. React, Vue czy Svelte wchodzą tylko jako "wyspy" — tylko tam, gdzie interaktywność jest faktycznie potrzebna. To architektonicznie najbliższy sąsiad idei HTMX w świecie nowoczesnych frameworków.

Kiedy vanilla/HTMX ma sens?

Przed wyborem HTMX albo vanilla JS trzy pytania decyzyjne:

• Czy backend może renderować fragmenty HTML, nie tylko JSON?
• Czy interakcje to głównie formularze, filtry, taby i podmiana sekcji?
• Czy zespół akceptuje prostszy frontend kosztem większej odpowiedzialności po stronie serwera?

Trzy razy "tak" — HTMX ma sens. Aplikacja żyje po stronie klienta z dużym lokalnym stanem — React pozostaje naturalnym wyborem.

Mój stack dla prostych projektów

Dla landing page'y, blogów i prostych stron często wystarcza mi:

Astro + Tailwind CSS + HTMX + Alpine.js (opcjonalnie)

• Astro — statyczny HTML z zerowym JS by default; React/Vue trafia tylko jako wyspa
• Tailwind — style bez osobnych plików CSS dla każdego komponentu
• HTMX — dynamiczne ładowanie, formularze
• Alpine.js — drobne interakcje (dropdown, modal)

Astro rozwiązuje jeden z problemów czystego HTML+HTMX: daje normalny model komponentów, routing i wsparcie dla szablonów — bez pakowania całego SPA do przeglądarki. To naturalne środowisko dla podejścia "web standards first".

Przykład: prosty newsletter form

<form hx-post="/api/subscribe" hx-swap="outerHTML" class="flex gap-2">
  <input
    type="email"
    name="email"
    required
    class="flex-1 rounded border px-4 py-2"
    placeholder="Twój email"
  />
  <button type="submit" class="rounded bg-blue-600 px-6 py-2 text-white">
    Zapisz się
  </button>
</form>

Serwer zwraca:

<p class="text-green-600">✓ Zapisano! Sprawdź swoją skrzynkę.</p>

Jeśli jeden fragment produktu urośnie ponad ten model, wydziel tam osobny island z Reactem. To nie musi być decyzja zero-jedynkowa dla całego projektu.

React jest zły?

Nie. React jest świetny do tego, do czego powstał: złożonych, interaktywnych aplikacji z dużą ilością stanu.

Problem zaczyna się, gdy framework staje się odruchem zamiast decyzją. Blog firmowy nie potrzebuje Virtual DOM. Landing page nie potrzebuje hydration. Formularz kontaktowy nie potrzebuje klientowego state management.

Trend "web standards first"

Dane z 2025 roku pokazują powrót do pytania: "Czy mogę to zrobić bez frameworka?"

Nie z powodu puryzmu — z powodu kosztów:

• Mniej zależności = mniej luk bezpieczeństwa
• Mniej abstrakcji = łatwiejszy debugging
• Mniejszy bundle = szybsza strona
• Prostszy stack = niższy koszt utrzymania

Seniorzy, którzy spędzili lata walcząc z konfiguracją builda, hydration issues i nadmiarem abstrakcji, doceniają prostotę nie dlatego, że są antyframeworkowi. Dlatego, że znają koszt źle dobranego narzędzia — z pierwszej ręki.

Więcej o nowoczesnym JavaScript: praktyczne wzorce czytelniejszego kodu.