6 Redenen isomorfe Web Apps is niet de Zilveren kogel die u zoekt-blog.

gedurende de laatste twee jaar, heb ik de term isomorfe Web Apps steeds vaker op een positieve manier genoemd. Ook gedurende deze tijd, heb ik wat nagedacht over de techniek. Mijn conclusie is dat isomorfe Web Apps iets is dat geen waarde zou toevoegen voor mij of de typische organisaties waar ik voor werk. Verschillende dingen hebben mij tot deze conclusie gebracht.

maar voordat ik de redenen opsommel, wil ik eerst benadrukken dat ik denk dat isomorfe javascript bibliotheken (dwz lodash.js) zijn geweldig. Ook denk ik dat geïsoleerde isomorfe componenten waardevol kunnen zijn, bijvoorbeeld een live bijgewerkte aandelenmarktindicator.

de redenen waarom ik niet geloof dat isomorfe webapps waardevol zijn voor mij of de organisaties waarvoor ik werk, zijn:

• De web server kan nu alleen worden geschreven in javascript
• Isomorf Web Apps kan nooit worden Progressive Enhancement voor niet-triviale apps
• Blokkeren vs niet-blokkerende data flow
• Time-to-interactie en de Geheimzinnige Vallei
• Mobiele apparaten bevriezen tijdens het parseren van javascript
• Uw beste ontwikkelaars zijn druk niet op het produceren van waarde

ik wil beginnen met een definitie van Isomorf Web Apps. Een isomorfe Web App is een web app waar de applicatie code heeft geen kennis van waar het wordt uitgevoerd. In plaats daarvan wordt deze kennis bewaard in de infrastructuurcode en kan de applicatie als geheel draaien op zowel client-side als server-side.

de webserver kan nu alleen geschreven worden in javascript

als de client code en de server code hetzelfde zijn( en de client kan vandaag alleen javascript interpreteren), dan zijn we beperkt tot javascript alleen op de server te gebruiken. Ik hou van node.js heel erg, maar ik denk dat het beter is om open te staan voor alternatieven in de toekomst, in mijn perspectief.

isomorfe webapps kunnen nooit progressieve verbetering zijn voor niet-triviale apps

Client-side javascript heeft toegang tot een in-memory state machine die een fijnkorrelig niveau van interactie mogelijk maakt, met een zeer lage latentie (sub-milliseconden). Hetzelfde geldt niet voor de HTTP state machine, die wordt aangedreven door link klikken en formulier inzendingen.

voor mij is progressieve verbetering te beginnen met een baseline die toegankelijk is voor alle mogelijke apparaten/browsers, van oud naar huidig naar toekomst. In de praktijk betekent dit een basislijn van server-side rendering. De verbetering stap is een zakelijke beslissing over waar de site/app te verbeteren om de waarde te verhogen. Met andere woorden, de verbetering wordt gedaan in de applicatie code (specifiek) en *niet* in de infrastructuur code (algemeen), met uitzondering van optimalisatie technieken zoals pjax of turbolinks.

de manier waarop isomorfe webapps progressieve verbetering kunnen krijgen, is door deze fijnkorrelige in-memory state machine te “vertalen” om alleen links en formulieren te gebruiken. De enige gevallen die ik kan zien waar dit mogelijk is is waar je niet nodig volledige client-side rendering in de eerste plaats, maar kon vertrouwen op bovengenoemde optimalisatie technieken en client-side componenten voor het verbeteren van de ervaring (dat wil zeggen een kalender component voor een invoerveld voor een datum).

een variant van deze oplossing is het niet ondersteunen van elke client-side status/overgang in de server-side status machine. In dit geval, dit moet een zakelijke beslissing die moet worden weerspiegeld in de applicatie code, het maken van de applicatie code omgeving gevoelig, die gaat tegen het idee van isomorfe Web Apps.

de manier waarop isomorfe webapps progressieve verbetering kunnen krijgen, is door deze fijnkorrelige in-memory state machine te “vertalen” om alleen links en formulieren te gebruiken.

Blocking versus niet-blocking data flow

de rendervolgorde voor het web aan de serverzijde en het web aan de client zijn verschillend: de blokken aan de serverzijde en de clientzijde blokkeren niet.

stel je voor dat we twee verzoeken aan sommige services moeten doen om een weergave te maken. We kunnen deze verzoeken parallel doen.

aan de serverzijde, als het tweede verzoek als eerste terugkeert, kan het dat deel van het antwoord weergeven, maar moet het verzenden van die bytes blokkeren totdat het eerste dat deel van het antwoord heeft gerenderd en teruggestuurd naar de browser.

aan de kant van de client bestaat deze beperking niet: de twee antwoorden kunnen onafhankelijk worden behandeld en weergegeven.

ook denk ik dat het bovenstaande de eenvoudigste voorbeelden zijn. Stel je voor dat je een boom van componenten hebt, waar de root component slim is (zie Presentationele en Container componenten voor een uitleg van smart/dumb componenten), gevolgd door een paar niveaus van dumb componenten, en dan ten minste één blad component dat slim is.

de infrastructuur heeft dan een manier nodig om ervoor te zorgen dat de context van smart leaf niet verloren gaat, zodat we de controle over de blokkerende/niet-blokkerende uitvoering verliezen, afhankelijk van de server/client-modus. Een manier om dit probleem op te lossen zou kunnen zijn om het hele programma worden uitgevoerd in een vrije monad, die de uitvoering als gegevens die later worden geïnterpreteerd. Een andere oplossing zou kunnen zijn om een of andere vorm van bezoeker patroon te gebruiken en laat componenten verklaren welke gegevens ze nodig hebben (vergelijkbaar met Tutorial: Handcrafting een isomorfe Redux applicatie (met liefde)). Dat laatste is waarschijnlijk het makkelijkst. Mijn punt is dat het probleem van de verschillende blokkeermodi waarschijnlijk veel ingewikkelder zijn dan men zich aanvankelijk voorstelt.

een alternatief ontwerp is om een regel te hebben die zegt “alleen de root component kan een slimme component zijn”, vergelijkbaar met hoe je de Io Monad in Haskell zou kunnen gebruiken, waardoor de bladeren zuiver blijven en alleen bijwerkingen op het hoogste niveau hebben. Ik denk dat dit ontwerp goed is aan de server kant, maar niet aan de client kant: een component aan de client kant moet in staat zijn om zijn eigen gegevens te laden in ten minste een aantal scenario ‘ s, bijvoorbeeld met betrekking tot social media gerelateerde componenten. Een regel hebben die deze scenario ‘ s nooit toelaat, lijkt erg onproductief.

Time-to-interaction en The Uncanny Valley

met de isomorfe Web Apps-benadering zal er een tijd zijn waarin de gebruiker grafische elementen op het scherm ziet die interactief lijken, maar dat niet zijn. met andere woorden, de tijd tussen het moment waarop de browser het antwoord van de server heeft weergegeven en het moment waarop het javascript wordt gedownload, ontleed en uitgevoerd. Dit wordt de “Uncanny Valley” of “Potemkin Village”genoemd.

zie deze tweet en de reacties voor meer details.

mobiele apparaten bevriezen tijdens het ontleden van javascript

op een “typische” mobiele telefoon, krijg je 1ms UI thread stall per 1KB javascript, volgens deze tweet. Malte Ubl is de tech lead van het AMP project, dus ik vermoed dat hij weet waar hij het over heeft.

uw beste ontwikkelaars zijn nu bezig met het niet produceren van waarde

isomorfe webapps is een aanpak die een hoog niveau van ontwikkelingsvaardigheden vereist. In veel gebieden (tenminste in de westerse wereld) is het moeilijk om hoogopgeleide ontwikkelaars te vinden en te rekruteren. Kiezen voor het ontwikkelen van isomorfe Web Apps toewijst die ontwikkelaars om iets te doen dat ik vraag produceert elke zakelijke waarde op alle. Er zijn betere manieren om gebruik te maken van hun tijd.

samenvatting

isomorfe webapps beperkt uw webservertaal/platformkeuze tot alleen javascript. Het heeft de ambitie om een geleidelijke verbetering mogelijk te maken, maar het kan niet waarmaken. Het introduceert een hoge mate van technische complexiteit als gevolg van de verschillen in het blokkeren/niet-blokkeren van gegevensstroom. Het introduceert een tijdvenster waar dingen interactief lijken te zijn, maar dat niet zijn (The Uncanny Valley). Een hoge hoeveelheid javascript bevriest ook mobiele browsers, met de regel-in-duim dat 1KB van javascript betekent 1ms van vastgelopen UI thread. En, aangezien het een ingewikkeld softwareontwerp vereist, kost het kostbare tijd en moeite van uw beste ontwikkelaars – er zijn betere manier om gebruik te maken van hun tijd.

tot slot wil ik benadrukken dat uw ervaringen anders kunnen zijn dan de mijne. Misschien zijn er scenario ‘ s wanneer isomorfe Web Apps zijn goed. Maar ze zijn niet een zilveren kogel voor het overbruggen van elke kloof tussen server-side web voordelen en client-side web voordelen, terwijl het krijgen van geen van de nadelen van beide benaderingen.

wat denkt u? Heb je overwogen om isomorf te worden? Heeft u ideeën over de uitdagingen en kosten? Hoe ga je met ze om?

Dankbetuigingen

dank aan Oskar Wickström en Per Ökvist voor de waardevolle discussies over dit onderwerp. Oskar ook beoordeeld dit bericht-dank u Oskar.