Ještě před pár lety byl frontend jedno velké bojiště. Každý nový framework sliboval revoluci, každá konference přinášela „lepší způsob“ a každé rozhodnutí o stacku mělo téměř existenční váhu.

React, Vue, Angular, Svelte… a desítky dalších. Každý s vlastní filozofií, vlastním ekosystémem a často i komunitou, která ho bránila téměř ideologicky.

Dnes je ale situace jiná. Frameworky nikam nezmizely, ale přestaly být centrem pozornosti. Válka neskončila tím, že by někdo vyhrál. Skončila tím, že přestala dávat smysl.

Jak jsme se do tohoto bodu dostali?

Frontend si za posledních deset let prošel bouřlivým vývojem. Od jednoduchých skriptů přes jQuery éru až po komplexní aplikace, které dnes běží v prohlížeči.

Každá generace frameworků řešila konkrétní problémy své doby. AngularJS přinesl strukturu, React změnil způsob uvažování o UI přes komponenty a stav, Vue zjednodušil onboarding a Svelte se pokusil odstranit runtime overhead.

To všechno dávalo smysl. Web byl omezený, standardy zaostávaly a vývojáři potřebovali nástroje, které jim umožní stavět složitější aplikace. Jenže postupně se situace změnila.

Technicky vzato: rozdíly se zmenšily

Když dnes vezmete moderní frameworky a podíváte se „pod kapotu“, zjistíte, že se v mnoha ohledech sbližují.

Například způsob práce s UI:

• React stále používá Virtual DOM a diffování
• Vue kombinuje Virtual DOM s optimalizacemi na úrovni kompilace
• Svelte přesouvá práci do build-time a generuje imperativní kód
• Solid nebo Qwik jdou cestou jemnozrnné reaktivity bez globálního diffu

Na papíře to zní jako zásadní rozdíly. V praxi ale většina aplikací narazí spíš na limity architektury než na limity konkrétního renderovacího modelu.

Podobné je to i u práce se stavem. Dříve se řešil Redux vs MobX, dnes má prakticky každý framework vlastní idiomatický způsob:

• hooks a context v Reactu
• reactive refs ve Vue
• stores v Svelte
• signals v novějších přístupech

A přestože se API liší, základní princip zůstává stejný: nějak reprezentovat stav a nějak ho propagovat do UI.

Kompilace vs. runtime: velké téma, malý dopad?

Jedním z největších technických sporů byl rozhodně přístup „runtime vs. compile-time“.

React historicky staví na runtime – aplikace obsahuje logiku pro práci s Virtual DOM a diffování. Svelte naopak přesouvá maximum práce do build kroku a výsledkem je optimalizovaný JavaScript bez framework runtime.

Vue i další nástroje dnes kombinují oba přístupy. Kompilátor analyzuje šablony a generuje optimalizace, runtime pak řeší dynamiku.

Z pohledu výkonu to přináší rozdíly. Jenže ty jsou často relevantní hlavně v extrémních scénářích. Pro běžné aplikace je mnohem důležitější kolik dat posíláte po síti, jak řešíte caching a jak strukturovaný máte kód. Samotný framework bývá až druhotný faktor.

Server rendering, streaming a edge

Jedna oblast, kde se technické rozdíly skutečně řeší, je renderování na serveru.

CSR (client-side rendering) byl dlouho standard, ale kvůli výkonu a SEO se postupně prosadily další přístupy:

• SSR (server-side rendering)
• SSG (static site generation)
• ISR (incremental static regeneration)
• streaming a partial hydration

Dnes už ale nejde jen o to jestli renderovat na serveru, ale kde a jak. Frameworky se přizpůsobily:

• React ekosystém má server components a streaming
• Vue/Nuxt nabízí hybridní renderování
• SvelteKit pracuje s univerzálním runtime
• Qwik posouvá koncept resumability

Hydration, resumability a boj o milisekundy

Hydration byl dlouho nutným zlem SSR aplikací – server pošle HTML a klient ho musí „oživit“.

To znamená stáhnout JavaScript, znovu vytvořit stav a navázat event listenery.

Novější přístupy se snaží tenhle proces minimalizovat nebo úplně obejít. Qwik například zavádí resumability, kdy aplikace pokračuje tam, kde server skončil, bez nutnosti plné hydratace.

Zní to jako zásadní průlom. A v určitých scénářích skutečně je. Ale znovu – pro velkou část aplikací je rozdíl v jednotkách milisekund. Důležitější bývá velikost bundle, síťová latence nebo způsob načítání dat.

Tooling jako skutečný game changer

Pokud se něco za poslední roky opravdu změnilo, není to ani tak samotný framework, ale tooling kolem něj.

Nástroje jako Vite, esbuild nebo Turbopack dramaticky zrychlily vývojový cyklus. Hot reload je prakticky okamžitý, buildy jsou řádově rychlejší a konfigurace jednodušší.

To má reálný dopad na produktivitu. Často větší než rozdíl mezi dvěma frameworky.

Podobně se sjednocuje i ekosystém:

• TypeScript je de facto standard
• linting a formatting jsou automatizované
• testování má ustálené nástroje

Framework tak přestává být izolovaný svět. Je jen jednou vrstvou v širším toolchainu.

Standardy vrací úder

Zatímco frameworky se postupně sjednocují, samotný web dohání, co dřív nestíhal.

Dnes máme: nativní ES moduly, fetch API místo XMLHttpRequest, Web Components nebo nové návrhy na reaktivitu (signals).

To všechno znamená, že část problémů, které frameworky řešily, už dnes řeší samotná platforma.

Výsledkem je zajímavý posun. Frameworky už nejsou jedinou cestou. V některých případech dává smysl použít méně abstrakce a víc se opřít o standardy.

AI mění priority

Do technické debaty vstupuje ještě jeden zásadní prvek: AI asistenti.

Ti mění způsob, jakým píšeme kód. Najednou není tak důležité, jestli si pamatujete přesnou syntaxi hooku nebo lifecycle metody. Důležité je umět popsat problém.

Frameworky byly dlouho optimalizované pro člověka – čitelnost, ergonomie, DX. AI ale tyhle věci nepotřebuje v takové míře. Dokáže generovat kód napříč různými přístupy.

To neznamená, že by frameworky přestaly hrát roli. Ale jejich výběr přestává být tak zásadní strategické rozhodnutí.

Takže co vlastně skončilo?

Frameworky nezmizely. Nejsou ani „mrtvé“. Jen se posunuly do jiné fáze.

Pro vývojáře to znamená jediné: přestat řešit framework jako hlavní problém.

Mnohem podstatnější je, jak je aplikace navržená, jak v ní proudí data, jak se chová pod reálnou zátěží a jak do vývoje zapojujete AI nástroje.

Framework vám v tom může pomoct. Ale pravděpodobně vás ani nezachrání, ani nezničí.

Pro více informací ohledně tématu doporučuji toto video: