az elmúlt két évben egyre gyakrabban hallottam az izomorf webalkalmazások kifejezést pozitív módon. Ezen idő alatt is sokat gondolkodtam a technikán. Következtetésem az, hogy az izomorf webalkalmazások olyan dolgok, amelyek nem adnak hozzáadott értéket nekem vagy a tipikus szervezeteknek, amelyeknél dolgozom. Számos dolog vezetett erre a következtetésre.
de mielőtt felsorolnám az okokat, először hadd hangsúlyozzam, hogy szerintem izomorf javascript könyvtárak (azaz lodash.js) fantasztikusak. Azt is gondolom, hogy az izolált izomorf komponensek értékesek lehetnek, például egy élő frissített tőzsdei mutató.
az okok, amelyek miatt nem hiszem, hogy az izomorf webalkalmazások értékesek nekem vagy azoknak a szervezeteknek, amelyeknek dolgozom, a következők:
- a webszerver most már csak javascript-ben írható
- az izomorf webalkalmazások soha nem lehetnek progresszív fejlesztések a nem triviális alkalmazások számára
- blokkolás vs nem blokkoló adatáramlás
- idő-interakció és az Uncanny Valley
- a mobil eszközök lefagynak a javascript elemzése során
- a legjobb fejlesztők most azzal vannak elfoglalva, hogy nem termelnek értéket
az izomorf webes alkalmazások definíciójával szeretném kezdeni. Az izomorf webalkalmazás olyan webalkalmazás, ahol az alkalmazás kódjának nincs ismerete arról, hogy hol fut. Ehelyett ez a tudás az infrastruktúra kódjában marad, és lehetővé teszi az alkalmazás egészének futtatását mind kliens, mind szerver oldalon.
- a webkiszolgáló most már csak JavaScriptben írható
- az izomorf webalkalmazások soha nem lehetnek progresszív fejlesztések a nem triviális alkalmazások számára
- blokkoló és nem blokkoló adatáramlás
- Time-to-interaction and the Uncanny Valley
- a mobil eszközök lefagynak a javascript elemzése során
- a legjobb fejlesztők most elfoglalt nem termelő érték
- Összegzés
- Köszönetnyilvánítás
a webkiszolgáló most már csak JavaScriptben írható
ha a kliens kódja és a szerver kódja megegyezik (és a kliens ma már csak a JavaScriptet tudja értelmezni), akkor csak JavaScriptet használhatunk a szerveren. Szeretem a csomópontot.js nagyon, de azt hiszem, jobb, ha nyitott alternatívák a jövőben, az én szemszögemből.
az izomorf webalkalmazások soha nem lehetnek progresszív fejlesztések a nem triviális alkalmazások számára
az ügyféloldali javascript hozzáférést biztosít a memóriában lévő állapotgéphez, amely lehetővé teszi az interakció finomszemcsés szintjét, nagyon alacsony késleltetéssel (ezredmásodperc alatt). Ugyanez nem igaz a HTTP állapotgépre, amelyet linkkattintások és űrlapküldések vezérelnek.
számomra a progresszív fejlesztés egy olyan alapvonallal kezdődik, amely minden lehetséges eszköz/böngésző számára elérhető, a régitől a jelenlegiig a jövőig. A gyakorlatban ez a szerveroldali renderelés alapvonalát jelenti. A bővítési lépés egy üzleti döntés arról, hogy hol lehet javítani a webhelyet/alkalmazást az érték növelése érdekében. Más szavakkal, a fejlesztés az alkalmazáskódban (specifikus) és *nem* az infrastruktúra kódban (általános) történik, kivéve az olyan optimalizálási technikákat, mint a pjax vagy a turbolinks.
az izomorf webalkalmazások progresszív továbbfejlesztésének módja az, hogy ezt a finom szemcsés memóriaállapotú gépet “lefordítják”, hogy csak linkeket és űrlapokat használjanak. Az egyetlen eset, amit látok, ahol ez lehetséges, az az, ahol nem volt szükség teljes ügyféloldali megjelenítésre, hanem a fent említett optimalizálási technikákra és ügyféloldali komponensekre támaszkodhatott az élmény fokozása érdekében (azaz egy dátum beviteli mezőjének naptári összetevője).
ennek a megoldásnak egy változata az, hogy nem támogat minden ügyféloldali állapotot/átmenetet a szerveroldali állapotgépben. Ebben az esetben ennek üzleti döntésnek kell lennie, amelyet tükrözni kell az alkalmazáskódban, érzékenyvé téve az alkalmazáskód környezetét, ami ellentétes az izomorf webalkalmazások gondolatával.
az izomorf webalkalmazások progresszív továbbfejlesztésének módja az, hogy ezt a finom szemcsés memóriaállapotú gépet “lefordítják”, hogy csak hivatkozásokat és űrlapokat használjanak.
blokkoló és nem blokkoló adatáramlás
a kiszolgálóoldali web és a kliens oldali web renderelési sorrendje eltérő: a szerveroldali blokkok és a kliens oldali nem blokkolnak.
képzeljük el, hogy Néhány szolgáltatáshoz két kérést kell tennünk a nézet megjelenítéséhez. Ezeket a kéréseket párhuzamosan is megtehetjük.
szerver oldalon, ha a második kérés tér vissza először, akkor a válasznak ezt a részét vissza tudja adni, de blokkolnia kell a bájtok küldését, amíg az első nem rendereli és vissza nem adja a válasznak ezt a részét a böngészőnek.
a kliens oldalon ez a korlátozás nem létezik: a két válasz egymástól függetlenül kezelhető és renderelhető.
is, azt hiszem, a fenti képviseli a legegyszerűbb példa. Képzeljük el, hogy van egy összetevőkből álló fa, ahol a gyökérkomponens smart (lásd a prezentációs és Konténerkomponenseket a smart/dumb komponensek magyarázatához), majd néhány szintű dumb komponens, majd legalább egy levélkomponens, amely smart.
az infrastruktúrának ezután módot kell találnia arra, hogy a smart leaf környezete ne vesszen el, így elveszítjük az irányítást a blokkoló/nem blokkoló végrehajtás felett, a szerver/kliens módtól függően. A probléma megoldásának egyik módja az lehet, ha az egész programot egy szabad monádban hajtják végre, amely a végrehajtást később értelmezhető adatként képviseli. Egy másik megoldás lehet a látogatói minta valamilyen formájának használata, és hagyja, hogy az összetevők kijelentsék, milyen adatokra van szükségük (hasonló a bemutatóhoz: izomorf Redux alkalmazás kézműves készítése (szeretettel)). Ez utóbbi valószínűleg a legegyszerűbb. Az a véleményem, hogy a különböző blokkolási módok problémája valószínűleg sokkal bonyolultabb, mint az eredetileg elképzelt.
alternatív kialakítás az, hogy van egy szabály, amely azt mondja: “csak a gyökérkomponens lehet intelligens komponens”, hasonlóan ahhoz, ahogyan az Io Monádot használhatja Haskellben, tisztán tartva a leveleket, és csak a felső szinten vannak mellékhatásai. Úgy gondolom, hogy ez a kialakítás jó a szerver oldalon, de nem a kliens oldalon: az ügyféloldali komponensnek képesnek kell lennie arra, hogy legalább néhány forgatókönyvben betöltse saját adatait, például a közösségi médiával kapcsolatos összetevőkkel kapcsolatban. Nagyon produktívnak tűnik egy olyan szabály, amely soha nem teszi lehetővé ezeket a forgatókönyveket.
Time-to-interaction and the Uncanny Valley
az izomorf webalkalmazások megközelítésével a Felhasználó olyan grafikus elemeket lát a képernyőn, amelyek interaktívnak tűnnek, de nem azok. más szóval, az idő, amikor a böngésző megadta a szerver válaszát, és amikor a javascript letöltésre, elemzésre és végrehajtásra kerül. Ezt “Uncanny Valley” – nek vagy “Potemkin Village” – nek hívják.
lásd ezt a tweetet és a válaszokat további részletekért.
a mobil eszközök lefagynak a javascript elemzése során
egy “tipikus” mobiltelefonon 1 ms UI szálat kapsz 1KB javascript-enként, e tweet szerint. Malte Ubl az AMP projekt technológiai vezetője, ezért gyanítom, hogy tudja, miről beszél.
a legjobb fejlesztők most elfoglalt nem termelő érték
izomorf Web Apps egy olyan megközelítés, amely megköveteli a magas szintű fejlesztési készség. Sok területen (legalábbis a nyugati világban) nehéz magasan képzett fejlesztőket találni és toborozni. Az izomorf webes alkalmazások fejlesztésének kiválasztása arra készteti ezeket a fejlesztőket, hogy tegyenek valamit, amit megkérdőjelezek, bármilyen üzleti értéket teremtenek. Vannak jobb módszerek arra, hogy kihasználják az idejüket.
Összegzés
az izomorf webalkalmazások korlátozzák a webszerver nyelvét/platformját, hogy csak javascript legyen. Arra törekszik, hogy lehetővé tegye a fokozatos fejlesztést, de nem képes teljesíteni. Magas szintű technikai bonyolultságot vezet be a blokkoló/nem blokkoló adatáramlás különbségei miatt. Bevezet egy időablakot, ahol a dolgok interaktívnak tűnnek, de nem azok (az Uncanny Valley). A nagy mennyiségű javascript a mobil böngészőket is lefagyasztja, a hüvelykujjszabály szerint az 1KB javascript 1 ms elakadt felhasználói felület szálat jelent. És mivel bonyolult szoftvertervezést igényel, értékes időt és erőfeszítést igényel a legjobb fejlesztőktől – van jobb módja annak, hogy kihasználják az idejüket.
végül szeretném hangsúlyozni, hogy a tapasztalatok eltérhetnek az enyémtől. Talán vannak olyan forgatókönyvek, amikor az izomorf webes alkalmazások jók. De ezek nem egy ezüst golyó a szerveroldali webes előnyök és az ügyféloldali webes előnyök közötti szakadék áthidalására, miközben mindkét megközelítés egyik hátrányát sem kapja meg.
mit gondolsz? Gondolt már arra, hogy”izomorf lesz”? Gondoltál már a kihívásokra és a költségekre? Hogyan kezeled őket?
Köszönetnyilvánítás
Köszönjük Oskar Wickstrnek és a per Xhamsterkvist-nak a témával kapcsolatos értékes vitákat. Oskar is áttekintette ezt a bejegyzést-köszönöm Oskar.
