Dlaczego doświadczeni programiści rzadziej wybierają React z automatu

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. Programista uczy się jednej technologii, w tym wypadku Reacta, a potem używa jej do wszystkiego — często bardziej z wygody niż z realnej potrzeby. Strona landingowa? React. Blog firmowy? React. Formularz kontaktowy? React + React Hook Form + Zod + Server Actions.

Efekt takiego postępowania:

• setki KB JavaScriptu dla strony z kilkoma sekcjami,
• opóźnienie hydrationHydration to etap, w którym React podłącza logikę JavaScript do już wygenerowanego HTML-a w przeglądarce. na wolniejszych urządzeniach,
• skomplikowany pipeline builda dla prostego projektu,
• dłuższy czas developmentu niż wynika z faktycznej złożoności zadania.

Framework stał się odruchem zamiast decyzją. Doświadczeni programiści, którzy pamiętają czasy przed Reactem, 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>

<!-- Wysyłka formularza przez AJAX -->
<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.

Kiedy HTMX zaczyna boleć?

HTMX jest prosty, dopóki przepływ jest prosty: użytkownik robi akcję, serwer zwraca fragment HTML, strona podmienia sekcję. Problemy zaczynają się, gdy aplikacja wymaga wielu równoległych stanów klienta.

Najczęstsze pułapki:

• dużo drobnych interakcji może oznaczać dużo requestów do backendu,
• cache'owanie fragmentów HTML bywa trudniejsze niż cache'owanie danych,
• optimistic UI, undo/redo, drag & drop i edycja offline wymagają dodatkowego JavaScriptu,
• trudniej współdzielić logikę widoku między webem, mobile i API publicznym,
• bez dyscypliny endpointy zaczynają zwracać „HTML tylko dla konkretnego przycisku”, co utrudnia utrzymanie.

To nie przekreśla HTMX. To tylko przypomina, że prostszy frontend często oznacza większą odpowiedzialność po stronie serwera.

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 natywnych 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>

Web Components są standardem przeglądarek, ale nie są pełnym zamiennikiem ergonomii Reacta. Dają enkapsulację i własne elementy HTML, lecz nie rozwiązują same z siebie routingu, zarządzania stanem, formularzy, danych asynchronicznych czy konwencji dużego zespołu.

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

React wprowadza abstrakcje:

• Virtual DOM
• Hooks i ich reguły
• Zarządzanie stanem (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. Wydajność z dobrego punktu startowego

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 renderowanie na poziomie tras.

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

Znacznie łatwiej znaleźć programistów Reacta niż osoby z doświadczeniem w 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.

Warto też uczciwie powiedzieć, że „wybór Reacta” coraz częściej oznacza wybór całego frameworka: Next.js, Remix, TanStack Start albo podobnego stosu. Oficjalna dokumentacja Reacta prowadzi nowe projekty w stronę frameworków, bo produkcyjna aplikacja potrzebuje routingu, ładowania danych, dzielenia kodu, renderowania i integracji z serwerem. To nie jest wada Reacta — to informacja o realnym koszcie wejścia.

React, HTMX, Astro czy vanilla JS?

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 stos dla prostych projektów

Dla stron landingowych, blogów i prostych stron często wystarcza mi:

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

• Astro — statyczny HTML z zerowym JS domyślnie; 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 formularz newslettera

<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 e-mail"
  />
  <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 osobną wyspę 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. Strona landingowa nie potrzebuje hydration. Formularz kontaktowy nie potrzebuje rozbudowanego zarządzania stanem po stronie klienta.

Trend „web standards first”

Dyskusje w ekosystemie i dane z ankiet JavaScript pokazują powrót do pytania: „Czy mogę to zrobić bez frameworka?” Nie oznacza to końca Reacta — oznacza koniec bezrefleksyjnego wybierania Reacta do każdego problemu.

Nie z powodu puryzmu — z powodu kosztów:

• Mniej zależności = mniej luk bezpieczeństwa
• Mniej abstrakcji = łatwiejsze debugowanie
• Mniejsza paczka JS = szybsza strona
• Prostszy stos = niższy koszt utrzymania

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