Očekávám, že tímto příspěvkem všechny naštvu:křižáci proti JavaScriptu, právem zděšení z toho, kolik věcí nacpeme na moderní webové stránky; lidé tvrdí, že web je nefunkční platforma pro interaktivní aplikace stejně a měli bychom začít znovu; Reagovat uživatelé; stará garda s jejich řemeslným JS a ručně vytvořeným HTML; a Tom MacWright, někdo, koho jsem z dálky obdivoval od chvíle, kdy jsem se před mnoha lety poprvé dozvěděl o jeho práci na Mapboxu. Ale myslím, že to je cena za názory.
Tom nedávno zveřejnil Second-Hádání moderního webu a to vzalo přední svět útokem. Měli byste si to přečíst, nebo alespoň CliffsNotes. Je tu spousta věcí, se kterými v různé míře souhlasím:
Je absolutně pravda, že spouštění Reactu v klientovi pro převážně statický web je přehnané. Je také pravda, že se musíte vyhnout Reactu, pokud je vaše aplikace velmi interaktivní – je všeobecně známo, že pokud chcete 60fps animaci, budete pravděpodobně muset obejít aktualizační cyklus React a dělat věci imperativnějším způsobem (ve skutečnosti to je co dělají knihovny jako response-spring). Ale zatímco toto všechno platí pro React, mnohem méně to platí o komponentových rámcích obecně .
Je to skvělý bod, který se ve skutečnosti neřeší, i když (jak uznává Tom) ve skutečnosti jen zhoršuje problém, který tu vždy byl. Myslím, že existují jeho řešení – můžeme opakovat přístup „index bundle“, mohli bychom zahrnout verzi webu do souboru cookie a použít to k zobrazení zpětné vazby, kterou lze uplatnit, pokud dojde k nesouladu – ale musíme tomu věnovat čas.
To je skutečně velmi nepříjemné, i když je to dost snadné udělat takové věci – jen se musíme dostatečně starat:
<button class="sign-up" disabled={!is_browser}>
{is_browser ? 'Sign up' : 'Loading'}
</button>
Nejsem si ale jistý, co to má společného s frameworky ve stylu React – tento problém existuje ať už tvoří váš frontend, pokud to neuděláte bez JS (což byste měli!).
Opět je to pravda, ale více specifická pro React než cokoli jiného. Přístup Reactu k vykreslování na straně serveru – vytvoření stromu komponent a jeho serializace – zahrnuje režii, kterou nesdílejí rámce, které například kompilují vaše komponenty (ahoj!) do funkcí, které pouze zřetězují řetězce pro SSR, což je rychlejší. o dramatickou částku. A tyto požadavky na rozhraní API bylo třeba provést tak jako tak, takže má smysl je provádět co nejdříve, zvláště pokud jsou váš aplikační server a server API blízko sebe (nebo dokonce totéž).
Amen. Stačí jít a několikrát si přečíst celou sekci 'API'.
Drobné dohady stranou, Tom identifikuje některé skutečné problémy se současným stavem vývoje webu. Ale myslím, že článek dospívá k nebezpečnému závěru.
Začněme rozebráním tohoto tvrzení:
Při vší úctě k zúčastněným si nemyslím, že Gatsby je nějak zvlášť relevantní měřítko. gatsby new my-site startovací aplikace spustí 266 kB minifikovaného JavaScriptu pro zcela statickou stránku v produkčním režimu; pro gatsbyjs.org je to 808 kB. Upřímně řečeno, toto nejsou působivá čísla.
Když to ponechám stranou, nesouhlasím s premisou. Když klepnu na odkaz na Tomově webu bez JS, prohlížeč nejprve počká na potvrzení, že šlo o klepnutí a ne o štětec/přejetí, poté provede požadavek a pak musíme čekat na odpověď. S webem vytvořeným pomocí frameworku se směrováním na straně klienta můžeme začít dělat zajímavější věci. Můžeme provádět informované odhady na základě analýzy o tom, s jakými věcmi bude uživatel pravděpodobně interagovat, a předem načíst logiku a data pro ně. Požadavky můžeme zahájit, jakmile se uživatel poprvé dotkne (nebo umístí kurzor myši) na odkaz místo čekání na potvrzení klepnutí – nejhorší scénář, nahráli jsme nějaké věci, které se budou hodit později, pokud udělají klepněte na něj. Můžeme poskytnout lepší vizuální zpětnou vazbu, že probíhá načítání a že se chystá přechod. A nemusíme načítat celý obsah stránky – často si vystačíme s malým kouskem JSON, protože pro stránku již máme JavaScript. Ručně se tohle dělá ďábelsky obtížně.
Kromě toho nejsou vanilkové statické stránky dostatečně ambiciózním cílem. Vezměte si například přechody. Weboví vývojáři jsou v současné době uvězněni v myšlení diskrétních stránek s otřesnými přechody – klikněte na odkaz a uvidíte, jak bude celá stránka nahrazena přesměrováním na straně klienta nebo opětovným načtením stránky – zatímco vývojáři nativních aplikací uvažují na jiné úrovni:
Dostat web tam bude vyžadovat více než jen technologický pokrok; bude to vyžadovat i kulturní posun. Ale rozhodně se tam nemůžeme dostat, pokud opustíme naši současnou trajektorii. Což je přesně to, co Tom vypadá navrhovat.
Nevím o žádné jiné platformě, kde se od vás očekává, že budete psát logiku pro vaše počáteční vykreslení pomocí jiné sady technologií, než je logika pro následné interakce. Samotná myšlenka zní blbě. Ale na webu s jeho jedinečnou historií to bylo po mnoho let normou – vygenerovali jsme nějaké HTML pomocí PHP nebo Rails nebo cokoli jiného, a pak na to „nasypali jQuery“.
S příchodem Node se to změnilo. Skutečnost, že můžeme provádět vykreslování na straně serveru a komunikovat s databázemi a co-máš pomocí jazyka nativního pro web je úžasný vývoj.
S tímto modelem jsou problémy. Tom některé z nich identifikuje. Dalším hlavním problémem, o kterém nediskutuje, je to, že serverem vykreslený model SPA obvykle „hydratuje“ celou úvodní stránku způsobem, který vyžaduje, abyste duplikovali tuny dat – jednou v HTML, jednou v blobu JSON, který je předán klientská verze aplikace produkuje přesně stejný výsledek – a může blokovat hlavní vlákno během doby, kdy uživatel začíná s aplikací interagovat.
Ale můžeme tyto problémy vyřešit. Next dělá úžasnou inovaci kolem (například) míchání statických a dynamických stránek v rámci jedné aplikace, takže získáte výhody čistě statického modelu, aniž byste se tím museli omezovat. Marko dělá inteligentní hydrataci na úrovni komponent, něco, co očekávám od jiných frameworků. Sapper, doprovodný rámec Svelte, má stanovený cíl neposílat žádný jiný JS než samotný (malý) router pro stránky, které to nevyžadují.
Budoucnost, kterou chci – budoucnost, kterou vidím — je nástrojem, který je přístupný největšímu počtu lidí (včetně návrhářů), který dokáže inteligentně přesouvat práci mezi serverem a klientem podle potřeby, což nám umožňuje vytvářet prostředí, která konkuruje nativnímu uživatelskému rozhraní (ano, dokonce i pro blogy!), a kde upgrade části webu na „interaktivní“ nebo ze „statické“ na „dynamickou“ nezahrnuje komunikaci napříč různorodými týmy využívajícími různé technologie. Můžeme se tam dostat pouze tím, že se zavážeme k paradigmatu Tom critiques — JavaScript-ish komponentní framework vykreslovaný serverem SPA. (Lepší jména vítána.)
Moderní web má nedostatky a měli bychom o nich mluvit. Ale nevzdávejme to.