Interaktivita bez JavaScriptu není trik, je to důsledek streamu
Web se dělí na dvě představy. Statická stránka bez interakce, nebo JavaScript na klientovi, který DOM přepisuje. Existuje ale třetí varianta a je zajímavá tím, co odhaluje o prohlížeči, ne tím, že by se měla používat.
HTTP odpověď nemusí nikdy skončit. Když spojení necháš otevřené a dál do něj posíláš HTML a CSS, prohlížeč nečeká na konec dokumentu. Parsuje a vykresluje průběžně, protože inkrementální renderer byl vždycky, jen se na něj zapomnělo. Funguje to napříč enginy a jede to na tom, že stream je legitimní stav dokumentu.
Stav zůstane na serveru, prohlížeč dostane snímky
V tomhle uspořádání se nesynchronizuje stav. Server drží celý model aplikace a klientovi posílá průběžně nové kusy značek, které přepisují pozice a vzhled. Demo s Flappy Birdem tímhle způsobem drží 60 FPS: server prostě streamuje CSS aktualizace pozic.
Vstup od uživatele se řeší starým mechanismem. Formulář se dá zacílit na skrytý iframe, takže se po odeslání překreslí iframe a ne hlavní stránka. Klik se tím stane requestem, který serveru řekne, co se stalo, a hlavní stream odpovídá novým snímkem.
Zajímavé je, že celá konstrukce nepotřebuje žádné nové API. Skládá se z chování, které prohlížeče měly dávno předtím, než se rozšířil jednostránkový model.
Cena se nezmizí, jen se přesune do latence
Náklady sedí jinde, než by čekal odhad. Na serveru je to překvapivě levné: přes 500 souběžných her na jedno jádro na starším stroji, což je řádově lepší než srovnatelná aplikace na Rails. Přenos vyjde na zhruba 20 KiB/s na hru, takže 49 sekund hraní stojí tolik dat jako jedno stažení megabajtového JS bundlu.
Zaplatí se to latencí a ta je nesmlouvavá. Každá interakce jde přes okružní cestu k serveru. V Atlantické Kanadě, kde server stál, se hrálo výborně. Se vzdáleností to plynule degraduje a na opačné straně planety je to nehratelné. Vzdálenost k serveru se stala součástí herní smyčky, protože v aplikaci není nic, co by ji zamaskovalo.
Druhá cena je provozní. Nikdy nekončící odpověď je pro okolní software neobvyklý tvar. Generátor náhledů odkazů v Pleromě se na takovém spojení zasekl natolik, že se z toho stalo odepření služby a server bylo nutné restartovat.
Co si z toho odnést
Tenhle experiment se nehodí nasadit, ale hodí se ho mít v hlavě jako krajní bod osy. Na jednom konci drží veškerý stav klient a server je jen zdroj dat. Na druhém drží veškerý stav server a klient je obrazovka. Všechno, co reálně stavíš, leží někde mezi a volíš jen to, kolik stavu překročí hranici.
Z toho plyne užitečná otázka k vlastní architektuře. Když přesuneš rozhodování na server, ušetříš synchronizaci, konflikty a velikost bundlu. Zaplatíš tím, že každá interakce dostane cenu jednoho okružního času, a ta cena se dá skrýt jen optimistickým vykreslením na klientovi. Streamované HTML z toho dělá čistý experiment právě proto, že žádné takové maskování nemá.
A ještě jedna věc: prvky, které dnes považuješ za zastaralé, často zakódovaly předpoklady, které pořád platí. Inkrementální parsování dokumentu je jedním z nich a stojí na něm i streaming server rendering v moderních frameworcích. Rozdíl je v tom, že tam se stream zavře a předá klientovi, zatímco tady se nezavře nikdy.