Astro vs. Next.js vs. Vite vs. TanStack Start: jaký stack zvolit v roce 2026?

Volba stacku je jedno z mála rozhodnutí na začátku projektu, které se později napravuje jen s velkou bolestí. Framework se nedá “vyměnit za odpoledne” — určuje architekturu, výkon i vývojářský zážitek na měsíce dopředu. Než se pustíme do jednotlivých nástrojů, stojí za to položit si jednu otázku, která rozhodne víc než cokoliv jiného: je tenhle web primárně dokument, který lidé čtou, nebo aplikace, se kterou lidé pracují? Blog, dokumentace nebo firemní prezentace jsou dokumenty — člověk přijde, přečte si obsah a odejde. Dashboard, e-mailový klient nebo interní nástroj jsou aplikace — člověk v nich tráví čas a generuje stav, který framework musí spravovat.

Pro rychlou orientaci — tabulka níže shrnuje doporučení podle typu projektu. Zbytek článku pak vysvětluje proč.

Astro — web, který se chová jako dokument#

Astro vychází z jednoduchého pozorování: většina webů má jen hrstku skutečně interaktivních prvků, ale klasický přístup posílá do prohlížeče JavaScript pro celou aplikaci, ať interaktivní je nebo ne. Astro to obrací — výchozím stavem je čisté HTML bez zbytečného JS, a JavaScript “přikupujete” jen pro konkrétní komponenty, které ho opravdu potřebují. Tomu se říká islands architecture (architektura ostrůvků).

Představte si stránku produktu v e-shopu: popis, obrázky a recenze jsou statický text, který se nemění. Jediné, co potřebuje interaktivitu, je třeba karusel obrázků nebo tlačítko “přidat do košíku”. Astro vyrenderuje zbytek stránky jako statické HTML a “probudí” jen tyhle dva ostrůvky. Výsledek je web, který se načte prakticky okamžitě, protože prohlížeč nemusí čekat na stažení a spuštění velkého množství JavaScriptu, než cokoliv ukáže.

Praktická výhoda navíc: Astro je frameworkově agnostické. Komponenty pro jednotlivé ostrůvky můžete psát v Reactu, Vue nebo Svelte a míchat je v jednom projektu — užitečné, když různé týmy preferují různé nástroje.

Kde Astro naráží na limity, je stav sdílený napříč celou aplikací — třeba přihlášení uživatele, obsah košíku nebo filtry, které musí žít v jednom globálním stavu dostupném na všech stránkách. Astro takové aplikace umí postavit taky, jen jeho architektura tam není vždy nejpřirozenější volba — pro tenhle typ projektu se obvykle víc vyplatí Next.js nebo Vite + SPA.

Vite + SPA — čistá aplikace bez kompromisů s renderováním#

Vite samotný je jen (velmi rychlý) build nástroj, ne framework. Když řeknete “Vite + React” nebo “Vite + Vue” bez nadstavby typu Next.js nebo Nuxt, dostanete klasickou Single Page Application: prohlížeč stáhne JavaScript, ten se spustí, a teprve pak se cokoliv vykreslí. Žádné server-side rendering, žádná serverová vrstva — celý životní cyklus stránky řeší klient.

Tahle jednoduchost je přesně důvod, proč se kombinace hodí pro interní nástroje a aplikace za přihlášením. SEO tam nehraje roli — nikdo negoogluje “admin panel firmy XY” — takže pomalejší první vykreslení, daň za čistě klientské renderování, prostě nevadí. Co naopak vadí, je zbytečná komplexita: pokud SSR nepotřebujete, nemusíte řešit ani jeho důsledky, a vývojářský cyklus zůstává jednodušší.

Cena za tuhle jednoduchost přichází, jakmile aplikace přece jen potřebuje být viditelná pro vyhledávače, nebo když chcete rychlé první vykreslení na pomalejších sítích — třeba u veřejné marketingové stránky přilepené k SaaS produktu. Tam se čistá SPA architektura obrací proti vám.

Next.js — univerzální React framework, který zvládá obojí#

Next.js je dlouhodobě nejrozšířenější React framework právě proto, že nenutí vybrat si mezi statickým a dynamickým obsahem — umí obojí v rámci jedné aplikace, klidně stránku po stránce. Blog s tisíci články se může generovat staticky při buildu, zatímco přihlašovací dashboard ve stejném projektu běží dynamicky. Novější architektura Next.js (tzv. App Router) jde v téhle granularitě ještě dál, až na úroveň jednotlivých komponent v rámci jedné stránky.

Tahle flexibilita je zároveň jeho hlavní silou i hlavním zdrojem frustrace. Next.js má silné, dost opinionated konvence — kam patří jaký soubor, kdy se co počítá na serveru a kdy v prohlížeči. Pro tým, který konvence přijme, to znamená méně rozhodování a rychlejší vývoj. Pro tým, který narazí na hranici toho, co framework “chce”, aby se dělalo jinak, může být stejná vlastnost zdrojem neintuitivního chování.

Next.js dává smysl tam, kde je potřeba jeden framework na frontend i backend a kde se mix statického a dynamického obsahu bude v čase měnit — typicky e-shopy, produkty s veřejnou i přihlášenou částí, redakční systémy. Pro malý statický web je to zbytečně těžký nástroj; tam se vyplatí Astro.

TanStack Start — explicitnost místo konvencí#

TanStack Start je nejmladší ze čtyř zmíněných stacků a staví na TanStack Router — routeru, který si získal reputaci díky důsledné typové bezpečnosti napříč celou aplikací. Je to plnokrevný framework pro React (a Solid), srovnatelný s Next.js co do funkcí — umí server-side rendering, cachování i server funkce volatelné přímo z klientského kódu.

Rozdíl oproti Next.js není ve funkcích, ale ve filozofii. Next.js řeší chování hlavně konvencemi — název souboru nebo jeho umístění určuje, co se stane. TanStack Start staví na explicitní konfiguraci, která je blíž psaní běžného React kódu bez skryté magie. Typová bezpečnost se navíc netýká jen jednotlivých funkcí, ale táhne se napříč serverovou i klientskou částí aplikace — pokud si server a frontend přestanou rozumět v tom, jaká data si posílají, TypeScript to odhalí při psaní kódu, ne uživatel v produkci.

Poznámka k aktuálnosti: v době psaní tohoto článku je TanStack Start ve fázi release candidate — tedy funkčně hotový a se stabilním API, ale ještě ne označený jako finální verze 1.0. Pro produkční nasazení to prakticky znamená o něco menší jistotu a menší ekosystém knihoven a hostingových integrací než u Next.js. Pokud zvažujete TanStack Start pro nový projekt, stojí za to si před rozhodnutím ověřit aktuální stav na tanstack.com — vývoj je tu rychlý.

Praktický důsledek: pokud váš tým už má rád TanStack Query nebo TanStack Router a chce podobný explicitní přístup i pro celý framework, TanStack Start je přirozené pokračování. Je to zároveň volba pro týmy, které si typovou bezpečnost cení víc než zavedenost a velikost ekosystému.

Co s ostatními?#

Nuxt a SvelteKit dělají pro Vue a Svelte v zásadě to, co Next.js pro React — statické i dynamické renderování v jednom projektu, směrování podle souborové struktury, serverová vrstva. Volba mezi nimi je tak většinou otázka preferovaného frontendového frameworku, ne odlišných schopností. Pokud nepotřebujete žádný JS framework a stavíte čistě statický obsah — dokumentaci, blog bez interaktivity — nástroje jako Hugo nebo Eleventy dají menší závislost na nástrojích a rychlejší build, protože negenerují žádnou klientskou aplikaci, jen hotové HTML.

Jak bych stack vybral pro váš projekt#

V praxi rozhodování většinou nezačíná u frameworku, ale u tří otázek: Kolik obsahu je statického a kolik se mění podle uživatele? Bude na webu logika, která běží “za přihlášením”? A jak moc záleží na SEO a rychlosti prvního vykreslení? Odpovědi na tyhle otázky obvykle stačí k tomu, aby se okruh vhodných stacků zúžil na jeden nebo dva — technologie je pak už jen důsledek, ne východisko.

Přesně takhle k projektům přistupuji i v SEMAKOD: nejdřív typ problému, pak technologie, ne naopak. Pokud si nejste jistí, co by pro váš web nebo aplikaci dávalo smysl, rád to s vámi proberu.

Tento článek vznikl s asistencí AI a prošel redakční kontrolou SEMAKOD, včetně ověření aktuálnosti technických informací k datu publikace.