Isomorfní webové aplikace jsou takové, které sdílejí kód mezi serverovou a klientskou stranou. Jinými slovy, jsou obě strany psané v JavaScriptu. I když tak to vůbec nemuselo být, historie je zajímavější.
Úplně poprvé jsem se s touto koncepcí setkal před (fíha, to je neuvěřitelné) takřka 20 lety. Vlastně JavaScript přímo vznikl jako client-side i server-side jazyk, serverové prostředí se jmenovalo Netscape LiveWire a kód vypadal nějak takto. Šlo tedy o mix HTML a JavaScriptu, jen s tím rozdílem, že skript se vykonával na serveru. JavaScript byl zamýšlený jako jazyk pro amatérské programátory, jako konkurent tehdejšího PHP a Microsoftího ASP, zatímco pro profesionály tu byla client-side a server-side Java.
Nic nedopadlo podle očekávání. Kvůli soudním sporům Java z prohlížečů zmizela, ke konci se držela už jen v porno chatech a bankovnictví, a dnes je z ní jeden velký bezpečnostní kráter distribuovaný jako adware, který je nutno v prohlížečích vypínat. Neuspěl ani JavaScript na serveru, protože byl příliš nezralý a nevhodný na takové nasazení a serverové řešení upadajícího Netscape nezískalo popularitu.
Vývoj webů na mnoho let zbrzdilo šílenství okolo specifikací začínajících na X a monopol Internet Exploreru, ale pak došlo k jejich svržení a máme tu hromadu nových technologií. A s tím se pochopitelně vrací i otázka jednoho jazyka na obou stranách. Odstartoval to zejména výkonnostně nadupaný interpret JavaScriptu z Google Chrome a platforma Node.js.
Situace je dosti jiná, než před 20 lety:
- server-side technologie ušly obrovský kus cesty a vyzrály
- client-side prožívá pubertu
- v průniku jazyků je pouze JavaScript
Tvorba webů pomocí serverových frameworků se stává komoditou, na řadu složitých otázek odpovídají zažité návrhové vzory. Na straně klienta to naopak bují, dnešní novinky nejspíš brzy nahradí novinky jiné, a to se ještě několikrát zopakuje. Tenhle stav je fajn, dohání se dlouhé zpoždění a máte šanci se zapojit a odvětvím pohnout.
Dohání také JavaScript, leč jeho skutečnou pozici nejlépe charakterizuje potřeba a popularita nejrůznějších nadstaveb, ať už jde o CoffeeScript, Google Closure Compiler nebo TypeScript. Pomocí nich už dnes lze z JavaScriptu udělat něco celkem robustního, což ale ve skutečnosti stále není. Přičemž jazyky s ambicí jej nahradit existují.
Osobně mi cesta k izomorfním aplikacím připadá přirozená a správná. U klientského skriptování jsem začínal a stále hledal různé spojnice, například Nette má dosud poměrně ojedinělou vlastnost, že pravidla pro validaci formulářů zapsaná na straně serveru vám automaticky překlopí na stranu prohlížeče. Isomorfní validace formulářů od roku 2008.
Ale v žádném případě bych si isomorfně nenechal naprogramovat třeba e-shop. Zatím.
Příliš mladé prostředí znamená absenci zažitých návrhových vzorů a různá rizika. Když si Dan Steigerwald, který pro mě částečně pochopitelně odmítá jakékoliv problémy této technologie připouštět, si tuhle posteskl, že čeští vývojáři jsou pozadu za frikulíny ze San Francisca a stále se drží serverových technologií, rozjela se diskuse o výhodách a nevýhodách jednotlivých přístupů a Dan jako odpověď na jednu námitku poslal příklad webu (tuším jeho kolegů) iodine.com psaný v React.js. Čímž poskytl pěkný příklad neduhů SPA/isomorfních aplikací:
- na webu nefunguje správně tlačítko zpět
- na mnoha různých URL se nachází identický obsah
- jeho výroba byla násobně dražší
Zdůrazňuji, že z jeho stany nešlo o ukázkový příklad, nicméně tím lépe demonstruje hlavní problém SPA/isomorfních aplikací: udělat je dobře je stále velmi těžké a potažmo drahé. Přičemž tentýž web za použití server-side frameworku, jako je například Nette, zvládne napsat i průměrný a levný programátor. A podobných hrubek se přitom nedopustí.
Izomorfním aplikacím se nevyhýbejte, zkoušejte si novinky, zavčasu odhalujte slepé cesty, rozšiřujte si obzory. Ale s ostrým nasazením se držte jen u typů aplikací, kde je to skutečně nutné a výhodné. Není jich zase tolik.
Navíc nemáte v žádné žhavé technologii jistotu. Tvrdit opak, třeba proto, že za nějakou z nich stojí obří firma, znamená být slepý k historii posledních 20 let.
Komentáře
Tomáš K. #1
Nepovažuji se za odborníka na toto téma, ale jednou z možných cest by mohl být Google Dart (https://dart.dev/). S výhledem na Web komponenty / Polymer se zdá být Dart na budoucnost rekativně dobře připraven.
Radek #2
Psát vše v JS je, myslím, zatím příliš velký skok do neznáma, kde neuřídím ani kvalitu ani náklady. Zatím by mi bohatě v nette stačilo, kdyby klientský javascript věděl něco málo o komponentách, jak jsou obsahově provázány, kdyby nebylo potřeba invalidovat každou komponentu zvláštním ajaxem (více signálů v ajaxu) a ulehčila se úprava DOM.
Tobiáš Potoček #3
Mně přijde zajímavé, že samotné Nette nemá od isomorfních aplikací zase tak daleko. Co jsem vyrozuměl, tak mezi klíčové vlastnosti isomorfních vlastností mimo jiné patří:
No a když zapnu v Nette nette.ajax a nette.ajax.history, tak výsledek splňuje automaticky druhé dva body, jen s tím rozdílem, že se mezi serverem a klientem přenáší data + šablona, zatímco v JavaScriptových isomorfních aplikacích se šablony přenesou na začátku a dále se přenáší jen data. A ohledně prvního bodu, tak u jednodušších webových stránek to platí také jednoduše proto, že není potřeba psát vůbec žádný klientský kód :D ony dva pluginy + zmíněné automatické generování validačních formulářových pravidel pro klienta řeší vše za mě.
Martin L. #4
Dobře se osvědčuje taktika spočívající ve sledování toho, jak věci dělá Daniel Steigerwald a nedělat je tak. Doporučuji.
Daniel Steigerwald #5
Web Iodine má zajímavou historii. V podstatě měli dva web designery, kteří uměli trochu jQuery a ještě méně JavaScript. Ten web vznikl tak, že si na statické HTML stránce hráli s https://d3js.org/, aby mohli zobrazovat grafy. Data o deseti vybraných drogách byla uložena v JSON, a to proto, že struktura se stále měnila, a bylo potřeba, aby kdokoliv z firmy, třeba farmaceutická specialistka, kdykoliv do JSON mohla šáhnout a něco upravit. No a kluci web developeři ta data chtěli nějak zobrazit. Celé to byl frontend first prototyp na rychlé hraní si s návrhem appky.
Byla potřeba umožnit rychle nějak tvořit webové komponenty, klikací formuláře, boxy pro jednotlivé drogy atd. Učit se celý Angular (naštěstí) nebyl čas. Vybral jsem React.js, protože ten dělal přesně co bylo potřeba, nic víc.
No a v jednu chvíli přišel požadavek na to, že by bylo dobře, kdyby Google mohl tahle data nějak indexovat. Měl jsem dvě možnosti. Buď překopat celý stack, nebo zkusit izomorfní přístup. A pozor, bez Este.js! Aby firma měla minimální závislost na mém kódu, až zase zmizím v Evropě.
Uprava pro serverové renderování mi zabrala jeden den. Nic víc po mne nechtěli, a nic víc jsem nesměl ani přidat. Firma byla zrovna v druhé fázi startupu.
Nebylo mi dovoleno zabývat se ničím jiným. Prostě maximálně agilní přístup, dělej jen to, co teď potřebujeme. Takže rozhodně nelze mluvit o nějaké ideální isomorfní appce. To by nemělo zapadnout 🙂
Stack, který jsem pro ně vytvořil jim maximálně vyhovoval. React.js umožní i podprůměrnému programátorovi vytvořit šablony/komponenty, a ty se vesele renderují na serveru i clientu. Nebylo třeba se učit celý Angular binding, scopes, atd., nic.
Co se týká isomorfních appek, shodneme se. Někdo musí nejprve prošlapat cestu (já), ale pak to bude naprostá bomba. Jak z hlediska efektivity vývoje, tak architektury a UX celé aplikace.
Vojta #6
#5 Danieli Steigerwalde, No a ta ideální isomorfní apka?
Daniel Steigerwald #7
Mimochodem, ani SPA nejsou tak vyřešené, jak by se mohlo zdát. Rozdíl mezi klasickým serverovým „naparsuj url, načti z db, mixni se šablonou, vrať HTML“ a aplikací, která drží stav a reaguje na asynchronní proud událostí, je nebetyčný.
I já se při školení vývoje webových aplikací ve firmách často ptám, potřebujete opravdu SPA? Proč? Pravdou ovšem je, že asi všechny moderní úspěšné aplikace jsou SPA. Jestli je to nutné nebo ne, to je na jinou diskuzi.
Většina programátorů se učí zaběhu, a při psaní SPA si dost natlučou prošlapováním slepých cest. Ne, s jQuery si opravdu nevystačíte, a například jQuery promises jsou prostě špatně naimplementované. Naštěstí z Facebooku poslední dobou padají skvělé knihovny a patterny. React.js, Flux, immutable-js. Všichni se máme ještě hodně co učit. A to se mi líbí 🙂
Daniel Steigerwald #8
#6 Vojto, Na jedné teď pracuju, a brzo ji zveřejním. Budu ji používat pro ilustraci nejen izomorfního přístupu, ale mnoha dalších patternů.
Opravdu mne nebaví jen o něčem mluvit, a nemít možnost ukázat kód. No a na vlastní pet projekt nebyl poslední rok čas, strávil jsem 6 měsíců v USA.
Daniel Steigerwald #9
#6 Vojto, Pokud jste myslel nějaké reálné, tak například https://www.airbnb.com/ nebo https://medium.com/ jsou isomorfní.
Jan Liška #10
Těším se na ideální isomorfní aplikaci. Posledních několik let se zabývám vývojem SPA, backend je ale vždy v jiném jazyce.
Na AirBnB se bez javascriptu nenačtou konkrétní nabídky na titulní stránce. Na detailu ubytování se viditelný obsah s vypnutým javascriptem načítá znatelně rychleji, než se zapnutým javascriptem. Proč to? Neměl by u isomorfní aplikace být obsah stránky shodný (s výjimkou různých social pluginů) a nemělo by se html načíst ze serveru a javascriptem zůstat pro první zobrazení neovlivněno?
Daniel Steigerwald #11
#10 Jane Liško, Ta aplikace na které dělám, a kterou budu používat k ilustraci principů a patternů, je zde: https://github.com/steida/songary.
Daniel Steigerwald #12
Btw, Iodine dnes spustil novej web, komplet založenej na React.js.
https://s3.amazonaws.com/…m/index.html
Je to docela zajímavej koncept Davide. Není to SPA, je to MPA. Ale přesto je to isomorfní appka. Každá URL se zpracovává zvlášť, vrátí se HTML, ale client navěsí tu samou React komponentu, a stránka se stane interaktivní.
Tenhle stack si ještě vybudovali s mojí pomocí, ale novej web už sami.
Robert #13
Smalltalk je též jazyk, ve kterém lze psát isomorfní aplikace. Čistě objektový jazyk, komponentová tvorba aplikace – React.js se tomu z JS světa trochu blíží.
Server-side: https://www.seaside.st/
Client-side: https://amber-lang.net/
Dosažení isomorfismu: https://github.com/…amework/tide
Osobně mám velmi dobrou zkušenost se Seaside, Amber je vcelku early stage, Tide je asi spíš experimentální, chce to vyzkoušet. Komunita je relativně malá, ale velmi aktivní.
Tento článek byl uzavřen. Už není možné k němu přidávat komentáře.