💻 Nejdůležitější frontend novinky 19.07.-26.07.2026
Forntend vývoj novinky 💻
19.07.-26.07.2026
Výkonnostní rozpočty po jednotlivých trasách odhalí problémy dřív než jeden globální limit
Moderní webové aplikace nemají napříč všemi stránkami stejný výkonový profil, takže jeden společný limit často zakryje zpomalení konkrétních částí. Smysl dává nastavovat výkonnostní rozpočty podle typu trasy, například pro marketingové stránky, přihlášené sekce, datově náročná zobrazení nebo transakční kroky. Pro každou kategorii je vhodné hlídat objem JavaScriptu, počet požadavků, LCP, latenci interakce a posuny layoutu. Když některá trasa limit překročí, tým může cíleně zasáhnout třeba rozdělením bundlu, odložením integrace nebo zjednodušením prvního renderu.
- Pro frontend je to praktičtější než jeden globální budget, protože odhalí regresi třeba jen na dashboardu nebo ve vyhledávání, aniž by ji průměr celého webu schoval.
- Metoda pomáhá při rozhodování před vydáním: je hned vidět, kolik výkonu stojí konkrétní závislosti, komponenty nebo externí služby v daném workflow.
- Dlouhodobá historie budgetů funguje jako architektonický signál, který ukáže, které části aplikace se postupně stávají těžšími na udržení rychlosti a zaslouží refaktor.
Virtualizace seznamů není univerzální lék, ale vyplatí se vědět, jak skutečně funguje
Článek vysvětluje, že virtualizace není totéž co nekonečné načítání dat a ve frontendové praxi se často nadužívá. Ve skutečnosti drží v DOM jen malý počet viditelných řádků, zatímco zbytek existuje pouze v datech, přičemž dojem plného seznamu vytváří prázdný „spacer“ a posun vykresleného výřezu pomocí transformace. Klíčové je i opětovné používání stejných DOM uzlů nebo view instancí, takže se při scrollování většinou nic neničí ani znovu nevytváří. Autor zároveň upozorňuje, že pro menší a jednoduché seznamy bývá virtualizace zbytečná a lepší je nejdřív řešit trackBy, OnPush nebo obecně množství renderované logiky.
- Pro frontend je nejdůležitější rozdíl mezi načítáním dat a vykreslováním: nekonečný scroll řeší přísun dalších položek, virtualizace zase omezuje počet DOM uzlů a dává smysl hlavně u dlouhých nebo často aktualizovaných seznamů.
- V Angularu i Reactu funguje základ podobně: viewport má pevnou výšku, každá položka musí mít správně nastavenou pevnou výšku a knihovna recykluje malé množství řádků místo toho, aby udržovala tisíce prvků v DOM.
- V praxi má virtualizace i nevýhody: hůř se kombinuje s proměnlivou výškou řádků, může komplikovat životní cyklus komponent, nehodí se pro SEO, tisk ani rozhraní, kde uživatel spoléhá na vyhledávání v obsahu přes Ctrl+F.
CSS vlastnost direction mění směr textu a rozložení prvků
Vlastnost direction v CSS určuje, zda se obsah vykreslí zleva doprava, nebo zprava doleva. Typicky se používá pro jazyky jako arabština nebo hebrejština, ale ovlivnit může i pořadí některých prvků v rozhraní. Základní použití vypadá jako direction: rtl; pro směr zprava doleva. Pro běžný frontend je důležité s ní počítat hlavně při tvorbě vícejazyčných webů a lokalizaci.
- Pomáhá správně zobrazit obsah pro jazyky psané zprava doleva, takže je klíčová při podpoře mezinárodních verzí aplikací.
- Může ovlivnit nejen text, ale i tok rozložení a chování některých UI prvků, proto je dobré ji testovat v reálném rozhraní.
- V praxi se hodí při návrhu komponent, které musí fungovat stejně spolehlivě v režimu LTR i RTL.
Next.js opravuje závažné bezpečnostní chyby v App Routeru, Server Actions i cachování
Next.js vydal červencové bezpečnostní aktualizace pro verze 16.2.11 a 15.5.21, které řeší několik vysoce závažných i středně závažných zranitelností. Největší rizika se týkají útoků typu DoS, obcházení middleware, SSRF a chyb v cachování odpovědí. Zasažené jsou hlavně aplikace postavené na App Routeru, Server Actions, Turbopacku a některých přepisovacích pravidlech. Pokud Next.js používáte v produkci, aktualizace by měla mít vysokou prioritu.
- Nejkritičtější chyby mohou vyřadit aplikaci z provozu přes vysoké zatížení CPU, obejít bezpečnostní kontroly v middleware nebo zneužít server k SSRF útokům při přesměrování a rewrites.
- Ohrožené jsou zejména projekty s App Routerem a alespoň jednou Server Action, aplikace builděné Turbopackem s jedním locale a vlastní servery, které přeposílají nebo přesměrovávají požadavky.
- Opravy jsou dostupné v Next.js 16.2.11 a 15.5.21, případně i v novějších canary a preview verzích řady 16.3; pro praxi dává smysl co nejdřív aktualizovat závislosti a zkontrolovat pravidla rewrites, redirects a práci s fetch cache.
React Flight v RSC otevřel cestu k vážným útokům, opravy už jsou venku
Článek rozebírá, proč je protokol React Flight v React Server Components bezpečnostně citlivý: nepřenáší jen data, ale i reference na moduly, serverové akce a asynchronní stav. Právě to umožnilo zneužití chyby React2Shell, která vedla k vzdálenému spuštění kódu bez přihlášení jediným požadavkem. React už vydal opravy, ale autor upozorňuje, že nejde jen o jednu chybu, nýbrž o širší riziko spojené s deserializací a důvěrou ve vstupní stream. Pro týmy používající RSC z toho plyne jasný závěr: aktualizovat a zpřísnit validaci i ochranu serverových akcí.
- Nejkritičtější dopad na praxi je nutnost okamžitě zkontrolovat verze Reactu: zranitelné byly mimo jiné 19.0.0, 19.1.0–19.1.1 a 19.2.0, opravy dorazily v 19.0.1, 19.1.2 a 19.2.1, další aktualizace řeší i následné DoS chyby.
- Pro frontend a fullstack vývojáře je zásadní validovat vstupy každé Server Action hned na začátku, ideálně přes Zod nebo Valibot, nepřistupovat k vlastnostem objektů před validací a nespoléhat jen na to, že framework riziko vyřeší sám.
- Jako další obrana dává smysl oddělovat serverový kód přes
server-only, doplnit vlastní CSRF ochranu nad rámec výchozího chování Next.js a brát WAF i Taint API jen jako doplňkovou vrstvu, ne jako hlavní bezpečnostní hranici.
twd-js testuje vanilla JavaScript přímo v prohlížeči bez bundleru
Knihovna twd-js míří na jednoduché weby psané v čistém HTML a JavaScriptu, které běží bez build procesu, ale přesto potřebují spolehlivé testy. Místo simulovaného DOMu spouští testy v reálném prohlížeči a dá se načíst rovnou z CDN přes import mapu, takže není potřeba npm ani bundler. Testy používají známý styl Testing Library a mohou běžet vedle aplikace přímo při vývoji na localhostu. Nechybí ani mockování API přes service worker ze stejné domény.
- Pro frontend vývoj je hlavní výhoda v tom, že testy ověřují skutečné chování stránky v prohlížeči, takže lépe odhalí chyby, které by v jsdomu nemusely být vidět.
- Nasazení je velmi jednoduché: stačí přidat import mapu do HTML, ručně zapsat testovací soubory a podmínit spuštění jen pro localhost, aby se testovací vrstva nedostala do produkce.
- Praktický přínos do budoucna je v přenositelnosti testů — protože pracují nad vykresleným DOMem, mohou se hodit i po přechodu z vanilla JavaScriptu na React, Vue nebo Solid, kdy se mění hlavně konfigurace, ne samotné testy.
Mikrofrontendy bez zbytečné magie: skládání přes import maps a nativní ES moduly
Článek popisuje přístup k mikrofrontendům, který staví na nativních funkcích prohlížeče místo další vrstvy vlastního runtime a složité konfigurace. Základem jsou import maps a ES moduly, díky nimž lze jednotlivé části aplikace vyvíjet i nasazovat nezávisle a přitom sdílet stejné knihovny, třeba React, bez duplicit. Autor kolem toho postavil malý toolkit rmc-toolkit, který z jednoho manifestu generuje mapování modulů, pomáhá s buildem i routováním. Výsledkem je jednodušší architektura, menší bundle a méně provozní i mentální zátěže pro týmy.
- Import maps umožňují načítat moduly podle aliasů přímo v prohlížeči, takže odpadá potřeba vlastního loaderu, iframe řešení nebo těžké integrační vrstvy.
- Jeden společný manifest určuje sdílené závislosti, umístění assetů i vazbu na URL, což zjednodušuje synchronizaci mezi buildem, routováním a nasazením jednotlivých mikrofrontendů.
- Pro frontend praxi je klíčové, že sdílené knihovny se nestahují v každém samostatném bundle znovu, takže i při více nezávisle nasazovaných částech zůstává aplikace lehčí a předvídatelnější.
@starting-style nahrazuje hacky pro vstupní CSS animace bez JavaScriptu
Nové CSS pravidlo @starting-style řeší běžný problém se vstupními animacemi prvků, které se právě vloží do DOM. Místo dvojitého requestAnimationFrame, setTimeout(0) nebo vynuceného reflow lze přímo v CSS definovat počáteční stav před prvním vykreslením. Prohlížeč pak plynule přejde do běžných stylů bez nutnosti přepínat třídy nebo sahat do JavaScriptu. Funguje to i při přepínání display: none a dobře se hodí také pro a Popover API.
- Ve frontendu to zjednodušuje komponenty: vstupní animace lze deklarovat čistě v CSS a odstranit křehkou logiku navázanou na mount, časování a reflow.
- V kombinaci s
allow-discretejde nově animovat i příchod a odchod prvků sdisplay, takže drawer, modal nebo popover nepřeskočí mezi stavy bez animace. - Podpora je už široká napříč moderními prohlížeči a ve starších se pravidlo jen ignoruje, takže prvek zůstane funkční i bez animace a není potřeba polyfill.
Typově bezpečný design systém v Reactu staví na tokenech a generovaném CSS
Článek ukazuje, že škálovatelný design systém v Reactu nevzniká jen jako sada komponent, ale hlavně díky přísně definovaným design tokenům v TypeScriptu. Autor doporučuje nejdřív typovat barvy a témata, z nich generovat CSS proměnné a vynutit konzistenci už při kompilaci místo až za běhu aplikace. Tím se výrazně zjednoduší podpora dark modu, brandingu pro více tenantů i práce s přístupností. Výsledkem je kombinace striktních pravidel, pružného themingu a lepšího vývojářského zážitku.
- Komponenty mohou přijímat jen platné sémantické tokeny, takže překlepy nebo neexistující barvy odhalí TypeScript hned při psaní kódu a ne až v produkci.
- Generování CSS proměnných z centrální konfigurace umožňuje snadno přepínat světlé a tmavé téma nebo nasadit individuální branding bez úprav samotných komponent.
- V praxi dobře funguje hybridní přístup: TypeScript řídí tokeny a témata, zatímco Tailwind zůstává pro utility třídy; je ale potřeba počítat s limity opacity modifikátorů nad CSS proměnnými.
TypeScript 7 přináší až 10× vyšší výkon díky přepisu kompilátoru do Go
Microsoft vydal TypeScript 7.0, ve kterém kompletně přepsal kompilátor i jazykový server z TypeScriptu běžícího na Node.js do nativního Go. Hlavním cílem bylo odstranit limity JavaScriptového runtime, zejména jednovláknové zpracování a vysoké nároky na paměť u velkých projektů. Výsledkem je podle Microsoftu až desetinásobné zrychlení, rychlejší diagnostika v editoru a nižší spotřeba paměti. Pro většinu projektů má být přechod bezbolestný, ale některé nástroje napojené na staré compiler API si zatím vyžádají opatrnost.
- Největší přínos pro vývojáře je v každodenní práci: kontrola typů, build i restart jazykového serveru jsou výrazně rychlejší, takže editor reaguje téměř okamžitě i u rozsáhlých codebase.
- Zrychlení stojí na dvou pilířích: nativní běh bez režie V8 a paralelní zpracování přes více jader CPU, kdy se současně provádí parsování, bindování, emit i type-checking.
- Pokud používáte nástroje závislé na starém programovém compiler API, například ve stacku s Vue, Svelte nebo Astro, je zatím rozumné zůstat na TypeScriptu 6; nová nativní API má dorazit ve verzi 7.1.
Ještě nemáte odběr?
Nenechte si utéct žádnou důležitou novinku. Přidejte se k nám a získejte pravidelný informační přehled čistých faktů přímo do své schránky.