6 Motive pentru care aplicațiile Web Isomorfe nu sunt glonțul de argint pe care îl căutați – blog.

în ultimii doi ani, am auzit termenul de aplicații Web izomorfe menționat într-un mod pozitiv din ce în ce mai frecvent. De asemenea, în acest timp, m-am gândit și eu la tehnică. Concluzia mea este că Isomorphic Web Apps este ceva care nu ar adăuga valoare pentru mine sau organizațiile tipice pentru care lucrez. Mai multe lucruri m-au condus la această concluzie.

dar, înainte de a enumera motivele, permiteți-mi să subliniez mai întâi că cred că bibliotecile javascript izomorfe (adică lodash.js) sunt minunate. De asemenea, cred că componentele izomorfe izolate pot fi valoroase, de exemplu un indicator al pieței bursiere actualizat în direct.

motivele pentru care nu cred că aplicațiile Web Isomorfe sunt valoroase pentru mine sau pentru organizațiile pentru care lucrez sunt:

• serverul web poate fi acum doar scris în javascript
• aplicațiile Web izomorfe nu pot fi niciodată îmbunătățite progresiv pentru aplicațiile non-banale
• blocarea vs fluxul de date care nu blochează
• timpul de interacțiune și Valea stranie
• dispozitivele Mobile îngheață în timpul parsării javascript
• cei mai buni dezvoltatori sunt acum ocupați să nu producă valoare

vreau să încep cu o definiție a aplicațiilor web izomorfe. O aplicație web izomorfă este o aplicație web în care codul aplicației nu are cunoștințe despre locul în care este rulat. În schimb, aceste cunoștințe sunt păstrate în codul infrastructurii și permit aplicației în ansamblu să ruleze atât pe partea clientului, cât și pe partea serverului.

serverul web poate fi acum scris doar în javascript

dacă codul clientului și Codul serverului sunt aceleași (iar clientul poate interpreta astăzi doar javascript), atunci suntem limitați să folosim javascript doar pe server. Îmi place node.js foarte mult, dar cred că este mai bine să fie deschis la alternative în viitor, în perspectiva mea.

aplicațiile Web izomorfe nu pot fi niciodată îmbunătățite progresiv pentru aplicațiile non-banale

javascript din partea clientului are acces la o mașină de stare în memorie care permite un nivel de interacțiune cu granulație fină, cu o latență foarte scăzută (sub-milisecunde). Același lucru nu este valabil și pentru mașina de stare HTTP, care este condusă de clicuri pe link și trimiteri de formulare.

pentru mine, îmbunătățirea progresivă este de a începe cu o linie de bază care este accesibilă pentru toate dispozitivele/browserele posibile, de la vechi la curent la viitor. În practică, aceasta înseamnă o linie de bază a randării pe partea serverului. Pasul de îmbunătățire este o decizie de afaceri cu privire la locul de îmbunătățire a site-ului/aplicației pentru a crește valoarea. Cu alte cuvinte, îmbunătățirea se face în codul aplicației (specific) și *nu* în codul infrastructurii (general), cu excepția tehnicilor de optimizare precum pjax sau turbolinks.

calea pentru aplicațiile Web izomorfe pentru a obține o îmbunătățire progresivă este să luați această mașină de stare în memorie cu granulație fină și să o „traduceți” pentru a utiliza numai linkuri și formulare. Singurele cazuri pe care le pot vedea în cazul în care acest lucru este posibil este în cazul în care nu au nevoie de redare completă client-side, în primul rând, dar în schimb ar putea să se bazeze pe tehnicile de optimizare menționate mai sus și componente client-side pentru îmbunătățirea experienței (de exemplu, o componentă calendar pentru un câmp de intrare pentru o dată).

o variantă a acestei soluții este de a nu sprijini fiecare stat client-side/tranziție în mașină de stat server-side. În acest caz, aceasta ar trebui să fie o decizie de afaceri care trebuie reflectată în codul aplicației, făcând mediul codului aplicației sensibil, ceea ce contravine ideii de aplicații Web izomorfe.

calea pentru aplicațiile Web izomorfe pentru a obține o îmbunătățire progresivă este de a lua această mașină de stare în memorie cu granulație fină și de a o „traduce” pentru a utiliza numai link-uri și formulare.

blocare vs flux de date care nu blochează

secvența de redare pentru Web-ul de pe server și Web-ul de pe client sunt diferite: Blocurile de pe server și partea de client nu se blochează.

Imaginați-vă că trebuie să facem două cereri către unele servicii pentru a face o vizualizare. Putem face aceste cereri în paralel.

pe partea de server, în cazul în care a doua cerere se întoarce în primul rând, se poate face acea parte a răspunsului, dar trebuie să blocheze trimiterea acestor octeți până când primul a randat și a returnat acea parte a răspunsului înapoi la browser.

din partea clientului, această constrângere nu există: cele două răspunsuri pot fi gestionate și redate independent.

de asemenea, cred că cele de mai sus reprezintă cele mai simple exemple. Imaginați-vă că aveți un arbore de componente, în cazul în care componenta rădăcină este inteligent (a se vedea componente de prezentare și Container pentru o explicație a componentelor inteligente/prost), urmat de câteva niveluri de componente prost, și apoi cel puțin o componentă frunze, care este inteligent.

infrastructura are nevoie apoi de o modalitate de a se asigura că contextul Smart leaf nu se pierde, astfel încât să pierdem controlul executării blocării/blocării, în funcție de modul server/client. O modalitate de a rezolva această problemă ar putea fi ca întregul program să fie executat într-o monadă gratuită, reprezentând execuția ca date care urmează să fie interpretate ulterior. O altă soluție ar putea fi utilizarea unei forme de model de vizitator și lăsați componentele să declare ce date au nevoie (similar cu tutorialul: realizarea manuală a unei aplicații izomorfe Redux (cu dragoste)). Acesta din urmă este probabil cel mai ușor. Ideea mea este că problema diferitelor moduri de blocare sunt probabil mult mai complicate pe care le imaginează inițial.

un design alternativ este de a avea o regulă care spune „numai componenta rădăcină poate fi o componentă inteligentă”, similar cu modul în care s-ar putea folosi monada IO în Haskell, păstrând frunzele pure și având doar efecte secundare la nivelul superior. Cred că acest design este bun pe partea serverului, dar nu pe partea clientului: o componentă din partea clientului ar trebui să poată încărca propriile date în cel puțin unele scenarii, de exemplu în ceea ce privește componentele legate de social media. A avea o regulă care nu permite niciodată aceste scenarii pare foarte neproductiv.

Time-to-interaction and the Uncanny Valley

cu abordarea isomorphic Web Apps, va exista o perioadă de timp în care utilizatorul vede elemente grafice pe ecran care par a fi interactive, dar nu sunt. cu alte cuvinte, timpul dintre momentul în care browserul a redat răspunsul serverului și când javascript este descărcat, analizat și executat. Aceasta se numește „Valea neobișnuită” sau „satul Potemkin”.

a se vedea acest tweet și răspunsurile pentru mai multe detalii.

dispozitive mobile congela în timpul parsarea javascript

pe un telefon mobil „tipic”, veți obține 1ms UI fir stand pe 1KB javascript, în conformitate cu acest tweet. Malte Ubl este liderul tehnic al proiectului AMP, așa că bănuiesc că știe despre ce vorbește.

cei mai buni dezvoltatori sunt acum ocupați să nu producă valoare

aplicații Web izomorfe este o abordare care necesită un nivel ridicat de abilități de dezvoltare. În multe domenii (cel puțin în lumea occidentală), este dificil să găsești și să recrutezi Dezvoltatori cu înaltă calificare. Alegerea de a dezvolta aplicații Web izomorfe alocă acelor Dezvoltatori să facă ceva ce pun la îndoială produce orice valoare de afaceri. Există modalități mai bune de a face uz de timpul lor.

rezumat

aplicațiile Web izomorfe limitează alegerea limbii/platformei serverului web să fie doar javascript. Are ambiția de a permite o îmbunătățire progresivă, dar nu poate oferi rezultate. Acesta introduce un nivel ridicat de complexitate tehnică datorită diferențelor de blocare/blocare a fluxului de date. Acesta introduce o fereastră de timp în cazul în care lucrurile par a fi interactive, dar nu sunt (Valea straniu). O cantitate mare de javascript îngheață, de asemenea, browserele mobile, cu regula generală că 1KB de javascript înseamnă 1ms de fir UI blocat. Și, deoarece necesită un design software complicat, este nevoie de timp și efort prețios de la cei mai buni dezvoltatori – există o modalitate mai bună de a-și folosi timpul.

în cele din urmă, vreau să subliniez că experiențele tale ar putea fi diferite de ale mele. Poate că există scenarii când aplicațiile Web Isomorfe sunt bune. Dar ele nu sunt un glonț de argint pentru reducerea fiecărui decalaj între beneficiile web server-side și beneficiile web client-side, în timp ce obținerea nici unul dintre dezavantajele ambelor abordări.

ce crezi? Te-ai gândit „merge izomorf”? Aveți gânduri despre provocări și Costuri? Cum te descurci cu ei?

mulțumiri

Vă mulțumim pentru Oskar Wickstr pentru discuții valoroase în jurul acestui subiect. Oskar a revizuit și acest post-mulțumesc Oskar.