Next.js vs htmx + Rust. Čo použiť a kedy

Rozhodnutie medzi Next.js a kombináciou Axum, Askama a htmx nie je súboj moderného JavaScriptu proti rýchlemu Ruste. Ide o voľbu vlastníka používateľského rozhrania.

Next.js dáva veľkú časť zodpovednosti komponentovému modelu Reactu a podľa potreby prehliadaču. htmx ponecháva rozhodovanie o výslednom HTML na serveri a v prehliadači vymieňa presne určené fragmenty.

Náš stručný verdikt je preto jasný. Next.js je dobrý štandard pre klientské produkty a rozhrania s bohatým lokálnym stavom. Axum, Askama a htmx sú silná voľba pre serverové CRUD, administračné a workflow aplikácie. Rust API s Next.js má zmysel až vtedy, keď produkt preukázateľne potrebuje bohatý klient aj osobitne výkonný alebo bezpečnostne citlivý backend.

1. Next.js

   Bohatý lokálny stav, editor, mapa alebo okamžité interakcie v prehliadači.

2. Axum + htmx

   Formuláre, tabuľky a postupné workflow, ktorých pravdu vlastní server.

3. Rust API + Next.js

   Bohaté UI spolu s preukázanou výpočtovou, paralelnou alebo viac-klientskou backendovou potrebou.

Overený stav k 22. júlu 2026

Overené verzie

• Next.js 16.2.x
• htmx 2.0.10 ako stabilná vetva
• htmx 4.0.0-beta5 iba ako preview

Nepotvrdené tvrdenie o patchi Next.js 16.2.11 nepoužívame. Pred realizáciou treba verzie znovu zamknúť, prečítať poznámky k vydaniu a preveriť aktuálne bezpečnostné oznamy.

Rust v tomto texte znamená Axum pre HTTP vrstvu, Askama pre typované šablóny a htmx pre cielené požiadavky a výmenu HTML. Nejde o Leptos, Yew ani o Rust SPA. Také riešenia majú iný model a patrili by do samostatného porovnania.

Ako fungujú oba modely

React Server Components a HTML fragmenty

React Server Component sa vykoná na serveri. Výsledok sa prenesie v dátovom formáte Reactu a klient ho spojí s existujúcim komponentovým stromom. Server Component môže načítať dáta blízko zdroja a neposiela svoj JavaScript do prehliadača.

Interaktivita však vyžaduje hranicu Client Component, hydratáciu a klientsky stav tam, kde sa rozhranie správa ako aplikácia.

HTML fragment v htmx je obyčajná serverová odpoveď. Tlačidlo môže mať hx-post, cieľ hx-target a spôsob výmeny hx-swap. Server spracuje pravidlo, Askama vyrenderuje nový riadok alebo panel a htmx ho vloží do DOM.

Verejným kontraktom nie je strom Reactu ani JSON objekt. Je ním HTTP požiadavka a HTML, ktorého štruktúra musí sedieť na cieľ.

Ani jeden model nie je automaticky jednoduchší. Next.js centralizuje skladanie zložitého UI v komponentoch. htmx centralizuje výsledný pohľad na serveri. Komplexita sa nestratí, iba sa presunie na miesto, ktoré môže lepšie zodpovedať produktu a tímu.

Next.js

1. Next.js požiadavka

   Prehliadač žiada trasu alebo spustí Server Action.

2. Komponentový výsledok

   Server vyrenderuje komponenty a klient zlúči prenesený výsledok so svojím stavom.

Axum + htmx

1. htmx udalosť

   Kliknutie alebo formulár odošle bežnú HTTP požiadavku z atribútu v HTML.

2. HTML fragment

   Axum overí pravidlá, Askama vyrenderuje výsledok a htmx nahradí určenú časť stránky.

Rovnaké schválenie faktúry

Implementácia v Next.js

Predstavme si zoznam faktúr. Oprávnený používateľ stlačí Schváliť, server overí organizáciu a stav dokladu, zmenu zapíše a používateľ uvidí nový stav. V Next.js môže formulár zavolať Server Action.

'use server';

import { revalidatePath } from 'next/cache';

export async function approveInvoice(formData: FormData) {
  const invoiceId = String(formData.get('invoiceId') ?? '');
  const user = await requireUser();

  await invoices.approve({
    invoiceId,
    organizationId: user.organizationId,
  });

  revalidatePath('/invoices');
}

Reálny handler ešte potrebuje validáciu identifikátora, autorizáciu konkrétnej operácie, ochranu proti opakovaniu a auditnú stopu. Server Action treba chápať ako verejne dosiahnuteľný serverový vstup, nie ako dôveryhodné interné volanie.

Po úspechu môže Next.js obnoviť trasu alebo konkrétny cache tag. Klient môže medzitým zobraziť optimistický stav a po chybe ho vrátiť.

Silnou stránkou je plynulé používateľské správanie. Ten istý zoznam môže mať lokálne filtre, hromadný výber, klávesové skratky, bočný detail a okamžité prepočty. React má pre takú koordináciu jasný model.

Cena vzniká v hraniciach medzi serverovým a klientskym komponentom, v invalidácii cache a v kontrole toho, koľko JavaScriptu skutočne posielame.

Implementácia v Axum, Askama a htmx

V serverovom variante odošle tlačidlo POST /invoices/{id}/approve. Axum získa prihláseného používateľa, aplikačná služba overí organizáciu aj prechod stavu a Askama vráti aktualizovaný riadok tabuľky.

use askama::Template;
use axum::{extract::{Path, State}, response::Html};
use uuid::Uuid;

async fn approve_invoice(
    State(state): State<AppState>,
    user: AuthenticatedUser,
    Path(invoice_id): Path<Uuid>,
) -> Result<Html<String>, AppError> {
    let invoice = state
        .invoices
        .approve(invoice_id, user.organization_id)
        .await?;
    let html = InvoiceRowTemplate { invoice }.render()?;
    Ok(Html(html))
}

Riadok môže používať hx-post, hx-target="closest tr" a hx-swap="outerHTML". Po odpovedi sa vymení iba tento prvok. AppError pritom musí previesť aj chybu šablóny a chybová odpoveď má vrátiť fragment vhodný pre používateľa.

Doménové pravidlo patrí do služby, nie do šablóny ani atribútu htmx.

Tento prístup je priamy pri formulároch a tabuľkách. Server po každom kroku vlastní pravdu aj prezentáciu. Pri hromadnom výbere, práci bez siete, náročnom drag and drop alebo viacerých súbežných paneloch však začne DOM niesť skrytý stav.

Vtedy treba buď pridať malú ostrovnú JavaScript vrstvu, alebo priznať, že rozhranie už zodpovedá klientskému aplikačnému modelu.

Prevádzkové rozhodnutia

Stav v prehliadači

Zoznam s filtrom v URL a jedným otvoreným dialógom zvládnu oba stacky. Rozdiel sa ukáže pri stave, ktorý musí reagovať okamžite a nezávisle od servera.

Editor s históriou krokov, mapa s tisíckami prvkov, plánovač s presúvaním položiek alebo konfigurátor s priebežným výpočtom majú prirodzený klientsky model. Next.js umožní serverové načítanie skombinovať s izolovanými klientskymi ostrovmi.

htmx je silný, keď je stav bezpečne reprezentovaný databázou, URL, formulárom alebo aktuálnym HTML. Namiesto synchronizácie klientského store po každej mutácii server pošle nový pohľad na pravdu. Menej duplicity často znamená menej tried chýb.

Ak však začneme ukladať významné dáta do data-* atribútov, písať vlastný event bus a ručne koordinovať päť fragmentov, pôvodná výhoda mizne.

API kontrakty a mobilné klienty

Serverom renderované HTML nie je nedostatok, ak je web jediný klient. Pre interný schvaľovací systém môže byť HTML najhodnotnejším kontraktom. Formulár, chyba validácie a aktualizovaný riadok sú jeden konzistentný výsledok bez paralelného mapovania DTO a šablóny.

Situácia sa mení, keď rovnakú schopnosť potrebuje natívna mobilná aplikácia, partner alebo verejné API. HTML fragment nie je vhodný všeobecný doménový kontrakt. Môžeme pridať JSON endpointy vedľa HTML handlerov, no nesmieme skopírovať pravidlá do dvoch ciest.

Obe majú volať rovnakú aplikačnú službu a mať kontraktové testy.

Next.js tiež automaticky nevyrieši API dizajn. Server Action je pohodlný kontrakt pre konkrétne React rozhranie, nie stabilné partnerské API. Pri viacerých klientoch potrebuje produkt explicitný kontrakt bez ohľadu na frontend. Rozhodnutie o API preto oddeľte od rozhodnutia o spôsobe renderovania.

Cache a nasadenie

Next.js poskytuje viac vrstiev cache a invalidácie. To je výhoda pre obsahové alebo dátovo náročné trasy, ale tím musí vedieť, čo je statické, čo sa znovu validuje a čo je osobné. Chyba často nevznikne preto, že cache nefunguje. Vznikne preto, že dve časti tímu predpokladajú odlišnú životnosť dát.

htmx samo cache politiku neurčuje. Používa HTTP. Plné stránky a bezpečné GET fragmenty môžu využívať hlavičky, reverzný proxy server alebo CDN.

Personalizované fragmenty musia mať správne Cache-Control a Vary. Mutácie majú vrátiť čerstvý pohľad alebo spustiť následné načítanie. Jednoduchší model neodpúšťa nesprávne HTTP pravidlá.

Pre oba stacky platí rovnaká zásada. Najprv pomenujte vlastníka čerstvosti dát a prípustnú starobu. Až potom vyberte mechanizmus. Cache nie je výkonová dekorácia. Je to súčasť konzistencie produktu.

Next.js sa dá prevádzkovať na spravovanej platforme aj vo vlastnom Node.js alebo kontajnerovom prostredí. Vlastný hosting potrebuje riešiť kompatibilný reverse proxy, statické aktíva, viac inštancií, cache koordináciu a konzistentné build identifikátory.

Framework zjednodušuje veľa vecí, no produkčný model treba stále navrhnúť.

Axum aplikácia môže byť jeden Rust binárny súbor so šablónami vloženými pri kompilácii a statickými aktívami. To je príjemný prevádzkový tvar. Kompilácia, cross build, správa databázových migrácií, telemetry a pohotovostné postupy však zostávajú.

Menší počet runtime vrstiev neznamená nulovú prevádzku.

Rust vie priniesť predvídateľnú spotrebu zdrojov a dobrú kontrolu nad paralelnou prácou. Bez reálnych meraní však nemožno tvrdiť, že celý produkt bude lacnejší. Databáza, externé API, obrázky a nesprávny dotaz často dominujú latencii.

Preto tu neuvádzame syntetické RPS čísla z neporovnateľných aplikácií.

Bezpečnosť a odovzdanie

Next.js aj htmx používajú bežné webové bezpečnostné hranice. Server musí po každej mutácii overiť identitu, organizáciu, oprávnenie a aktuálny stav objektu. Skrytý input, React prop ani DOM atribút nie sú dôveryhodné.

Výstup treba bezpečne escapovať a pri vedomom vkladaní HTML musí existovať presná sanitizácia.

Pri cookie autentifikácii treba posúdiť CSRF podľa metódy, pôvodu požiadavky a cookie politiky. htmx hlavička ani Server Action samy osebe nenahrádzajú autorizačné pravidlo.

Rust ownership chráni veľkú triedu pamäťových problémov, nie chyby prístupu medzi tenantmi, chybné SQL ani únik citlivých údajov v logoch.

Bezpečnejší stack je ten, v ktorom tím dokáže udržať jednu autoritatívnu doménovú cestu, kontrolované závislosti, aktualizácie a pozorovateľnosť. Framework môže poskytnúť bezpečné predvolené správanie, ale nevie domyslieť firemné pravidlá za nás.

Next.js má veľký trh React vývojárov a klient si ľahšie zostaví tím pre ďalší rozvoj. To neznamená, že každý React vývojár rozumie Server Components, cache alebo produkčnej prevádzke. Handover potrebuje dokumentované hranice, rozhodnutia a merateľné kontrolné postupy.

Rust tím býva menší a nábor náročnejší. Na druhej strane silný typový systém, explicitné chybové cesty a kompilátor znižujú priestor pre niektoré neúmyselné zmeny. Ak budúci vlastník Rust nepozná, elegantný binárny súbor sa môže stať organizačným rizikom.

Technická vhodnosť bez dostupného vlastníka nie je udržateľná voľba.

Pri vývoji softvéru na mieru preto hodnotíme aj schopnosť klienta systém po odovzdaní prevádzkovať, nie iba rýchlosť prvého vydania. Dokumentácia lokálneho prostredia, migrácií, incidentov a aktualizácií závislostí patrí do architektúry.

Zlyhania, hybrid a výber stacku

Kde zlyhávajú oba prístupy

Next.js je slabá voľba, ak tím vytvorí veľkú klientsku aplikáciu pre jednoduché formuláre iba preto, že pozná React. Zbytočná hydratácia, duplicitný stav, komplikované invalidácie a hranice Server Action môžu prekryť jednoduchý obchodný proces.

Framework sa tiež rýchlo mení a upgrade vyžaduje pravidelnú pozornosť.

Ďalšie zlyhanie vznikne, keď sa Next.js použije ako náhodná integračná vrstva aj doménový backend bez jasných modulov. UI, autorizácia, volania dodávateľov a dlhé úlohy sa premiešajú v trasách. Produkt potom nemá jasný kontrakt pre mobil ani miesto, kde sa dá bezpečne testovať obchodné pravidlo.

Kde zlyháva htmx + Rust

Rust môže spomaliť tím, ktorý ešte len hľadá produkt a nemá skúsenosť s jazykom. Kompilátor odhalí technické nezhody, ale nerozhodne, či je obrazovka užitočná. Pri veľmi rýchlom prototypovaní môže byť cena typov a kompilácie vyššia než aktuálne riziko.

htmx zlyháva, keď sa z fragmentov stane neviditeľná klientská stavová architektúra. Viac cieľov jednej odpovede, udalosti spúšťajúce udalosti a veľa vlastného JavaScriptu vytvoria systém, ktorý sa ťažko sleduje. V takom bode React nepredstavuje prehru. Je to pomenovanie skutočnej povahy rozhrania.

Ďalším rizikom je menší trh ľudí, ktorí rozumejú zároveň Ruste, serverovým šablónam, progresívnemu vylepšeniu a prístupnosti. Jednoduchý runtime môže zakryť drahé odovzdanie.

Kedy zvoliť hybrid Rust API + Next.js

Hybrid je vhodný vtedy, keď existujú dve samostatne preukázané potreby. Frontend má bohatý stav a potrebuje React ekosystém. Backend má výpočtovo náročné úlohy, nízku toleranciu latencie, silnú paralelnú záťaž alebo vlastní samostatný kontrakt pre viac klientov.

Tímy musia vedieť nezávisle testovať, verziovať a prevádzkovať hranicu.

Hybrid nie je poistka proti rozhodnutiu. Prináša dva toolchainy, sieťové zlyhania, schému API, autentifikáciu medzi vrstvami, koreláciu logov a koordináciu zmien. Ak Rust API iba posunie jeden formulár do databázy a jediným klientom je Next.js, získali sme cenu distribúcie bez jej prínosu.

Najprv možno začať v jednom stacku a zachovať doménové hranice. Rovnaký princíp rozoberá porovnanie modulárneho monolitu a mikroslužieb. Samostatné API treba vyčleniť na základe vlastníctva a merania, nie pre symetriu architektonického diagramu.

Rozhodovacia matica a odovzdanie

Na Rise používame praktickú heuristiku. Ak približne 80 percent obrazoviek tvoria formuláre, tabuľky a postupné workflow a stav prirodzene žije na serveri, Axum, Askama a htmx si zaslúžia vážne posúdenie. Nie je to vedecký prah ani univerzálne pravidlo.

Je to signál, že React môže riešiť problém, ktorý produkt v skutočnosti nemá.

Ak podstatná časť hodnoty vzniká okamžitou manipuláciou v prehliadači, Next.js je bezpečnejší štandard. Ak potrebujete obe vlastnosti, najprv oddeľte skutočný doménový kontrakt a až potom zvažujte hybrid.

Kontrola pred rozhodnutím

Pred vertikálnym rezom si spíšte rozhodovacie vstupy.

• tri najzložitejšie interakcie,
• všetkých budúcich klientov,
• prevádzkové obmedzenia.

Pre jeden reprezentatívny workflow vytvorte tenký vertikálny rez.

Zmerajte množstvo klientského stavu, počet sieťových krokov, spôsob chýb, veľkosť prenesených aktív a čas potrebný na bezpečnú zmenu. Toto poskytne lepší podklad než všeobecný benchmark.

Overte aj vlastníctvo. Kto aktualizuje framework, kto rieši incident, kto pozná databázové migrácie a kto dokáže prijať projekt o dva roky. Pri výbere IT partnera má byť odpoveď súčasťou ponuky aj odovzdávacieho plánu.

Rozhodnutie uzavrite až po vertikálnom reze a dohode o vlastníkovi. Architektúra je obhájiteľná vtedy, keď budúci tím vie vysvetliť jej hranice, zmerať ich a bezpečne ich meniť.