Next.js vs htmx + Rust. Co použít a kdy

Rozhodnutí mezi Next.js a kombinací Axum, Askama a htmx není souboj moderního JavaScriptu s rychlým Rustem. Je to volba vlastníka uživatelského rozhraní.

Next.js předává velkou část odpovědnosti komponentovému modelu Reactu a podle potřeby prohlížeči. htmx ponechává výsledné HTML pod kontrolou serveru a vyměňuje přesně určené fragmenty stránky.

Náš stručný závěr je jasný. Next.js je dobrá výchozí volba pro klientské produkty a rozhraní s bohatým lokálním stavem. Axum, Askama a htmx jsou silnou volbou pro serverové CRUD, administrativní a workflow aplikace. Rust API s Next.js dává smysl až tehdy, když produkt prokazatelně potřebuje bohatého klienta i samostatně náročný nebo bezpečnostně citlivý backend.

1. Next.js

   Bohatý lokální stav, editor, mapa nebo okamžité interakce v prohlížeči.

2. Axum + htmx

   Formuláře, tabulky a postupné workflow, jejichž pravdu vlastní server.

3. Rust API + Next.js

   Bohaté UI spolu s doloženou výpočetní, paralelní nebo víceklientskou potřebou backendu.

Ověřený stav k 22. červenci 2026

Ověřené verze

• Next.js 16.2.x
• htmx 2.0.10 jako stabilní řada
• htmx 4.0.0-beta5 pouze jako preview

Nepotvrzené tvrzení o bezpečnostním vydání Next.js 16.2.11 nepoužíváme. Před realizací je potřeba verze znovu uzamknout, přečíst poznámky k vydání a ověřit aktuální bezpečnostní oznámení.

Rust v tomto článku znamená Axum pro HTTP, Askama pro typované šablony a htmx pro cílené požadavky a výměnu HTML. Nejde o Leptos, Yew ani jinou Rust SPA vrstvu. Tyto možnosti mají jiný aplikační model a zaslouží si samostatné porovnání.

Jak fungují oba modely

React Server Components a HTML fragmenty

React Server Component se vykoná na serveru. Výsledek se přenese v transportním formátu Reactu a klient ho spojí s existujícím stromem komponent. Server Component může načíst data blízko zdroje, aniž by do prohlížeče posílala vlastní JavaScript.

Interaktivní chování však potřebuje hranici Client Component, hydrataci a stav v prohlížeči všude tam, kde se rozhraní chová jako aplikace.

Fragment htmx je běžná serverová odpověď. Tlačítko může deklarovat hx-post, hx-target a hx-swap. Server ověří pravidlo, Askama vykreslí řádek nebo panel a htmx ho vloží do DOM.

Veřejným kontraktem není strom Reactu ani nutně JSON objekt. Je jím HTTP požadavek a HTML, jehož struktura musí odpovídat cíli.

Ani jeden model není automaticky jednodušší. Next.js soustřeďuje skládání složitého rozhraní do komponent. htmx soustřeďuje výsledný pohled na server. Složitost nezmizí. Přesune se na stranu, která může lépe odpovídat produktu a týmu.

Next.js

1. Požadavek Next.js

   Prohlížeč vyžádá trasu nebo spustí Server Action.

2. Výsledek komponent

   Server vykreslí komponenty a klient spojí přenesený výsledek se svým stavem.

Axum + htmx

1. Událost htmx

   Kliknutí nebo formulář odešle běžný HTTP požadavek z atributu v HTML.

2. HTML fragment

   Axum ověří pravidla, Askama vykreslí výsledek a htmx nahradí určenou část stránky.

Stejné schválení faktury

Implementace v Next.js

Představme si seznam faktur. Oprávněný uživatel vybere Schválit, server ověří organizaci a stav dokladu, zapíše změnu a rozhraní zobrazí nový stav. V Next.js může formulář zavolat 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');
}

Skutečný handler potřebuje také validaci identifikátoru, oprávnění pro konkrétní operaci, ochranu proti opakování a auditní stopu. Server Action je veřejně dostupný serverový vstup, nikoli důvěryhodné interní volání. Po úspěchu může Next.js obnovit trasu nebo přesný cache tag.

Klient může mezitím ukázat optimistický stav a při chybě ho vrátit.

Silnou stránkou je plynulá interakce. Stejný seznam může mít lokální filtry, hromadný výběr, klávesové zkratky, boční detail a okamžité výpočty. React nabízí pro takovou koordinaci srozumitelný model.

Cena vzniká na hranicích Server a Client Components, v invalidaci cache a při kontrole množství JavaScriptu odesílaného do prohlížeče.

Implementace s Axum, Askama a htmx

V serverové variantě odešle tlačítko POST /invoices/{id}/approve. Axum získá přihlášeného uživatele, aplikační služba ověří organizaci a přechod stavu a Askama vrátí aktualizovaný řádek tabulky.

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))
}

Řádek může používat hx-post, hx-target="closest tr" a hx-swap="outerHTML". Po odpovědi se změní pouze tento prvek. AppError musí převést také chybu šablony.

Chybová odpověď má vrátit fragment, který uživateli umožní situaci napravit. Doménový přechod patří do aplikační služby, nikoli do šablony nebo atributu htmx.

Tato cesta je přímá pro formuláře a tabulky. Server po každém kroku vlastní pravdu i prezentaci. Poměr se mění při hromadném výběru, práci bez sítě, náročném drag and drop nebo několika panelech, které musí reagovat společně.

Tým pak přidá malý JavaScriptový ostrov, nebo uzná, že rozhraní už má model klientské aplikace.

Provozní rozhodnutí

Stav v prohlížeči

Seznam s filtry v URL a jedním otevřeným dialogem funguje v obou stackách. Rozdíl je patrný, když musí stav reagovat okamžitě bez cesty na server.

Editor s historií zpět, mapa s tisíci objekty, plánovač s přesouváním položek nebo konfigurátor s průběžnými výpočty mají přirozený model v prohlížeči. Next.js pro tyto případy spojuje serverové načtení s oddělenými klientskými ostrovy.

htmx je nejsilnější, když stav bezpečně reprezentuje databáze, URL, odeslaný formulář nebo aktuální HTML. Místo synchronizace klientského store po každé mutaci server vrátí nový pohled na pravdu. Méně duplicit často odstraní celé skupiny chyb.

Původní výhoda mizí, pokud důležitá data přejdou do data-* atributů, stránku koordinuje vlastní event bus a pět fragmentů vyžaduje ruční aktualizaci.

API kontrakty a mobilní klienti

Serverem vykreslené HTML není nedostatek, pokud je webové rozhraní jediným klientem. Pro interní schvalovací systém může být HTML nejužitečnějším kontraktem. Formulář, validační chyba a nový řádek tvoří jeden konzistentní výsledek bez paralelního mapování DTO a šablony.

Odpověď se mění, když stejnou schopnost potřebuje nativní mobilní aplikace, partner nebo veřejné API. HTML fragment není vhodný obecný doménový kontrakt. JSON endpointy mohou existovat vedle HTML handlerů, ale obchodní pravidla se nesmí kopírovat do dvou cest.

Obě mají volat stejnou aplikační službu a získat kontraktové testy.

Ani Next.js neřeší API návrh automaticky. Server Action je pohodlná pro konkrétní React rozhraní, ale není trvalým partnerským API. Produkt s více klienty potřebuje explicitní kontrakt bez ohledu na webový renderer. Rozhodnutí o API hranici proto oddělte od rozhodnutí o renderování.

Cache a nasazení

Next.js nabízí několik vrstev cache a invalidace. To pomáhá obsahovým a datově náročným trasám, ale tým musí vědět, co je statické, co se znovu validuje a co je osobní. Chyby často nevznikají kvůli rozbité cache. Vznikají kvůli odlišným předpokladům o životnosti stejných dat.

htmx neurčuje cache politiku. Používá HTTP. Celé stránky a bezpečné GET fragmenty mohou využívat hlavičky, reverse proxy nebo CDN.

Osobní fragmenty potřebují správné Cache-Control a Vary. Mutace mají vrátit čerstvou reprezentaci nebo zahájit následné načtení. Menší abstrakce neodpouští nesprávnou HTTP sémantiku.

Pro oba stacky platí stejné pravidlo. Před výběrem mechanismu určete vlastníka čerstvosti a přijatelné stáří každé důležité hodnoty. Cache je součástí konzistence produktu, nikoli ozdoba výkonnostní prezentace.

Next.js lze provozovat na spravované platformě nebo ve vlastním Node.js či kontejnerovém prostředí. Vlastní hosting vyžaduje kompatibilní reverse proxy, statické assety, více instancí, koordinované cache a konzistentní build identifikátory.

Framework řeší mnoho aplikačních věcí, ale produkční topologie stále potřebuje záměrný návrh.

Aplikace Axum může být jeden Rust binární soubor se šablonami vloženými při kompilaci a adresářem statických assetů. To je příjemný provozní tvar. Kompilace, cross build, databázové migrace, telemetrie a incidentní postupy zůstávají. Méně runtime vrstev neznamená nulový provoz.

Rust může nabídnout předvídatelnou spotřebu prostředků a přesnou kontrolu paralelní práce. To nedokazuje nižší celkové náklady produktu. Databáze, externí API, obrázky a jeden špatný dotaz často určují latenci.

Proto neuvádíme syntetická čísla požadavků za sekundu z aplikací, které nedělají srovnatelnou práci.

Bezpečnost a předání

Next.js a htmx sdílejí běžné webové bezpečnostní hranice. Server musí při každé mutaci ověřit identitu, organizaci, oprávnění a aktuální stav objektu. Skrytý input, React prop ani DOM atribut nejsou důvěryhodné.

Výstup se musí bezpečně escapovat a vědomě vložené HTML potřebuje úzce definovanou sanitizaci.

Cookie autentizace vyžaduje posouzení CSRF podle metody, původu požadavku a pravidel cookie. Hlavička htmx ani Server Action nenahrazují autorizaci. Rust ownership brání široké třídě paměťových chyb. Nezabrání chybě v oddělení tenantů, vadnému SQL ani citlivým údajům v logu.

Bezpečnější stack je ten, ve kterém tým udrží jednu autoritativní doménovou cestu, kontrolované závislosti, včasné aktualizace a použitelnou pozorovatelnost. Framework může poskytnout bezpečné výchozí chování, ale neuhodne firemní oprávnění.

Next.js těží z velkého trhu React vývojářů, takže klient může snáze vytvořit tým pro další rozvoj. Ne každý React vývojář však rozumí Server Components, cache nebo produkčnímu provozu. Předání stále potřebuje dokumentované hranice, rozhodnutí a opakovatelné kontroly.

Trh s Rust vývojáři je menší a nábor může trvat déle. Silný typový systém, explicitní chybové cesty a kompilátor naopak snižují některé neúmyslné změny. Pokud budoucí vlastník Rust nezná, elegantní binární soubor se stane organizačním rizikem.

Technická vhodnost bez dostupného vlastníka není udržitelná.

Při vývoji softwaru na míru proto posuzujeme také schopnost klienta systém po předání provozovat. Lokální prostředí, migrace, řešení incidentů a aktualizace závislostí jsou architektonické výstupy.

Selhání, hybrid a výběr stacku

Kde selhávají oba přístupy

Next.js je špatná volba, když tým vytvoří velkou klientskou aplikaci pro jednoduché formuláře jen proto, že zná React. Zbytečná hydratace, duplicitní stav, složitá invalidace a hranice Server Action překryjí jednoduchý obchodní proces.

Framework se navíc mění tak rychle, že aktualizace vyžadují pravidelnou pozornost.

Další selhání vznikne, když se Next.js bez jasných modulů stane náhodnou integrační vrstvou i doménovým backendem. Rozhraní, autorizace, volání dodavatelů a dlouhé úlohy se promíchají v trasách. Produkt pak nemá čistý kontrakt pro mobil ani jasné místo pro bezpečné testování obchodního pravidla.

Kde selhává htmx + Rust

Rust může zpomalit tým, který současně hledá produkt a učí se jazyk. Kompilátor odhalí technický nesoulad, ale nerozhodne, zda je obrazovka užitečná. V raném období hledání mohou být typy a kompilace dražší než současné riziko.

htmx selže, když fragmenty vytvoří neviditelnou architekturu klientského stavu. Jedna odpověď mění více cílů, události spouštějí další události a vlastní JavaScript narůstá. Výsledek se špatně sleduje. React v této chvíli není prohra, ale přesný popis povahy rozhraní.

Rizikem zůstává také menší trh lidí, kteří současně rozumějí Rustu, serverovým šablonám, progresivnímu vylepšení a přístupnosti. Jednoduchý runtime může zakrýt nákladné předání.

Kdy si Rust API + Next.js zaslouží místo

Hybrid se hodí, když jsou prokázány dvě nezávislé potřeby. Frontend má bohatý stav a těží z React ekosystému. Backend vlastní výpočetně náročné úlohy, přísné cíle latence, vysokou paralelní zátěž nebo samostatný kontrakt pro několik klientů.

Týmy dokážou hranici nezávisle testovat, verzovat a provozovat.

Hybrid není pojištění proti rozhodnutí. Přidává dva toolchainy, síťová selhání, API schéma, autentizaci mezi vrstvami, korelaci logů a koordinované změny. Pokud Rust API pouze uloží jeden formulář do databáze a Next.js je jeho jediným klientem, systém platí cenu distribuce bez nezávislosti.

Produkt může začít v jednom stacku a zachovat doménové hranice. Stejné uvažování popisuje porovnání modulárního monolitu a mikroslužeb. API oddělujte podle vlastnictví a měření, nikoli kvůli symetrii architektonického diagramu.

Rozhodovací matice a předání

V Rise používáme praktickou heuristiku. Pokud přibližně 80 procent obrazovek tvoří formuláře, tabulky a postupné workflow, jejichž stav přirozeně žije na serveru, zaslouží si Axum, Askama a htmx vážné posouzení. Není to vědecký práh ani univerzální pravidlo.

Je to signál, že React může řešit problém, který produkt nemá.

Pokud podstatná část hodnoty vzniká okamžitou manipulací v prohlížeči, je Next.js bezpečnější výchozí volba. Pokud jsou potřeba obě vlastnosti, nejprve definujte skutečný doménový kontrakt a teprve potom zvažte hybrid.

Kontrola před rozhodnutím

Začněte rozhodovacími vstupy.

• třemi nejnáročnějšími interakcemi,
• všemi očekávanými klienty,
• provozními omezeními.

Potom vytvořte tenký vertikální řez jednoho reprezentativního workflow. Změřte stav v prohlížeči, síťové kroky, chování při chybě, přenesené assety a čas potřebný pro bezpečnou změnu.

Takové podklady jsou hodnotnější než obecný benchmark.

Ověřte také vlastnictví. Kdo aktualizuje framework, řeší incident, rozumí migracím a dokáže produkt převzít za dva roky. Náš návod pro výběr IT partnera vysvětluje, proč tyto odpovědi patří do nabídky i předávacího plánu.

Rozhodnutí uzavřete až po vertikálním řezu a dohodě o vlastníkovi. Architektura je obhajitelná tehdy, když budoucí tým dokáže vysvětlit její hranice, měřit je a bezpečně je měnit.