Kiedy nie wybierać Reacta? Astro, HTMX i Vanilla JS jako alternatywy

Kiedy React to zły wybór dla projektu webowego?

Klasyczny problem to przyzwyczajenie i jego przezwyciężenie, bo uczymy się jednej technologii, w tym wypadku Reacta, a potem używamy jej do wszystkiego. Często dzieje się to bardziej z wygody niż z realnej potrzeby. Strona landingowa? React. Blog firmowy? React. Formularz kontaktowy? React + React Hook Form + Zod + Server Actions.

Jakie są efekty takiego postępowania?

1. Setki KB JavaScriptu dla strony z kilkoma sekcjami,
2. Opóźnienie hydratacji na wolniejszych urządzeniach,
3. Skomplikowany pipeline budowania dla prostego projektu,
4. Dłuższy czas developmentu niż wynika z faktycznej złożoności zadania.

Framework stał się po prostu odruchem zamiast przemyślaną decyzją architektoniczną.

HTMX jako alternatywa dla React: jak działa i co daje?

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-wire, czyli więcej logiki wraca na serwer, frontend staje się cieńszą warstwą interakcji. Dla jednych projektów może być to ogromną zaletą, ale dla innych, bardziej je ograniczy.

Ograniczenia HTMX: kiedy przestaje wystarczać?

HTMX upraszcza wiele rzeczy po stronie klienta, ale złożoność z projektu nie znika, ale przesuwa się na serwer.

Realne koszty tego przesunięcia:

1. Backend musi umieć renderować sensowne fragmenty HTML, a nie tylko zwracać JSON.
2. Złożony stan klienta, optimistic UI i rozbudowane interakcje są trudniejsze niż w React.
3. Im więcej dynamicznych sekcji, tym ważniejsza dyscyplina w nazewnictwie endpointów i fragmentów.
4. Testy E2E i kontrakty frontend–backend nadal są potrzebne, tyle że mają 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 nie wystarczy w aplikacji webowej?

HTMX jest prosty, dopóki flow użytkownika jest prosty. Przykładowo, kiedy użytkownik robi akcję, serwer zwraca fragment HTML i ostatecznie strona podmienia sekcję. Problemy zaczynają się, gdy aplikacja wymaga wielu równoległych stanów klienta.

Dużo drobnych interakcji szybko generuje dużo requestów do backendu, a cache'owanie fragmentów HTML bywa trudniejsze niż cache'owanie surowych danych. Optimistic UI, undo/redo, drag & drop i edycja offline wymagają dodatkowego JavaScriptu, który trzeba dopisać obok. Trudniej też współdzielić logikę widoku między webem, mobile i API publicznym, a bez dyscypliny endpointy zaczynają zwracać „HTML tylko dla konkretnego przycisku”. To wszystko z czasem utrudnia utrzymanie całości.

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

Vanilla JavaScript zamiast React

1. Nowoczesne przeglądarki zmniejszają potrzebę frameworka

W 2015 React rozwiązywał realne problemy, bo przeglądarka była znacznie mniej kompletna jako platforma aplikacyjna. Duża część tego, co dziś uznajemy za standard, wtedy wymagała frameworka, bundlera albo dodatkowej biblioteki.

• Moduły ES nie były jeszcze powszechnie obsługiwane w przeglądarkach, podczas gdy dziś import/export działa natywnie.

• fetch nie był jeszcze dostępny wszędzie. Aktualnie są to standardowe API przeglądarki.

• Template literals dopiero wchodziły do codziennego użycia. Aktualnie są standardową częścią JavaScriptu.

• Praca z DOM była mniej wygodna i mniej spójna, podczas gdy dzisiaj mamy szeroko dostępne querySelector, dataset, classList, closest i matches.

• Natywne komponenty nie były praktyczną opcją produkcyjną, a dziś Web Components mają znacznie dojrzalsze wsparcie.

// 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ść JavaScriptu to mniej błędów

React wprowadza warstwy abstrakcji, które trzeba nosić przez cały projekt: Virtual DOM, reguły hooków, zarządzanie stanem (Context, Redux, Zustand...), hydration mismatch i 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.

3. Wydajność bez dużego bundle JavaScriptu

React i aplikacje SPA często muszą wykonać pracę, której prosty serwer-renderowany interfejs nie potrzebuje, taką jak diffing Virtual DOM, reconciliation, hydratacja po SSR, re-renderowanie (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 jest w punkcie startowym: prosty HTML z minimalnym JS łatwiej uczynić szybkim niż bogatą aplikację klientową.

4. SEO bez dodatkowej warstwy renderowania

Jeśli budujesz SPA renderowane głównie po stronie klienta, faktycznie musisz bardziej pilnować renderowania pod SEO. Dlatego w ekosystemie React tak popularne są rozwiązania typu Next.js, SSR, SSG 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ć.

Kiedy React nadal wygrywa z HTMX i vanilla JS?

React ma swoje miejsce i całą garść zalet:

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

Aplikacje typu Figma, Notion, Google Docs, czyli tam gdzie interakcje są skomplikowane i stan jest rozproszony. Tu React błyszczy i pokazuje swoje najmocniejsze zalety.

Duże zespoły

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

Ekosystem

Potrzebujesz date pickera, drag & drop albo rich text editora? W React znajdziesz 10 gotowych bibliotek, a dla porównania w vanilla JS musisz więcej robić sam.

Rekrutacja

Znacznie łatwiej znaleźć programistów Reacta niż osoby z doświadczeniem w HTMX i ma to bardzo duże znaczenie dla firm.

Narzędzia full-stack i ekosystem React

W praktyce React to dziś nie tylko biblioteka do widoków, ale także ogromny ekosystem wokół routingu, renderowania po stronie serwera, design systemów, testów, formularzy oraz komponentów UI. W wielu produktach ciężko jest znaleźć jakąś sensowną alternatywę.

Warto też uczciwie powiedzieć, że „wybór Reacta” coraz częściej oznacza wybór całego frameworka, czyli Next.js, Remix, TanStack Start albo podobnego stosu. Oficjalna dokumentacja Reacta prowadzi nowe projekty w stronę frameworków, ponieważ produkcyjna aplikacja potrzebuje routingu, ładowania danych, dzielenia kodu, renderowania i integracji z serwerem.

React vs HTMX vs Astro vs vanilla JS: porównanie wyboru

Podejście hybrydowe: Astro, HTMX i React jako wyspy

Najlepsza odpowiedź rzadko brzmi „100% React” albo „100% HTMX”. W większości realnych projektów wygrywa układ mieszany, w którym serwer renderuje większość HTML, HTMX albo zwykły JS obsługują proste interakcje, a 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 Architecture. 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 wybrać HTMX lub vanilla JS zamiast React?

Przed wyborem HTMX albo vanilla JS trzy pytania decyzyjne:

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

Jeśli wybrałeś trzy razy TAK, wtedy HTMX ma sens. W sytuacji gdy aplikacja żyje po stronie klienta z dużym lokalnym stanem, React jest dobrym wyborem.

Astro, HTMX i Alpine.js jako lekki stack 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 i to 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.

Czy React jest zły? Nie, ale nie pasuje do każdego projektu

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

Problemy tworzy odruchowe wykorzystywanie frameworka, bo przykładowo blog firmowy nie potrzebuje Virtual DOM, a strona landingowa nie potrzebuje hydratacji. Formularz kontaktowy nie potrzebuje rozbudowanego zarządzania stanem po stronie klienta. I tak dalej.

Web standards first: dlaczego część zespołów odchodzi od React?

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, ale oznacza koniec jego bezrefleksyjnego wybierania do każdego problemu.

Powodem są koszty, ponieważ mniej zależności oznacza mniej luk bezpieczeństwa, mniej abstrakcji oznacza łatwiejsze debugowanie, mniejsza paczka JS oznacza szybszą stronę i ostatecznie prostszy stos, niższy koszt utrzymania.

Doświadczeni programiści, którzy spędzili lata walcząc z konfiguracją procesu budowania, problemami hydratacji i nadmiarem abstrakcji, doceniają prostotę nie dlatego, że są antyframeworkowi. Dlatego dobrze znają koszt źle dobranego narzędzia.