I løpet Av de siste to årene har jeg hørt begrepet Isomorphic Web Apps nevnt på en positiv måte mer og oftere. Også i løpet av denne tiden, jeg har gjort noen tenker meg om teknikken. Min konklusjon er At Isomorphic Web Apps er noe som ikke ville tilføre verdi for meg eller de typiske organisasjonene jeg jobber for. Flere ting har ført meg til denne konklusjonen.
Men før jeg lister årsakene, la meg først understreke at jeg tror isomorfe javascript-biblioteker (dvs.lodash.js) er kjempebra. Også, jeg tror at isolerte isomorfe komponenter kan være verdifulle, for eksempel en live oppdatert aksjemarkedsindikator.
årsakene til At Jeg ikke tror At Isomorphic Web Apps er verdifulle for meg eller organisasjonene jeg jobber for er:
- webserveren kan nå bare skrives i javascript
- Isomorphic Web Apps kan aldri Være Progressiv Forbedring for ikke-trivielle apps
- Blokkering vs ikke-blokkerende dataflyt
- Tid-til-interaksjon Og Uncanny Valley
- Mobile enheter fryser under parsing av javascript
- dine beste utviklere er nå opptatt med å ikke produsere verdi
jeg vil starte Med En Definisjon av isomorphic web apps. En Isomorphic Web App er en web app der programkoden har ingen kunnskap om hvor det kjøres. I stedet holdes denne kunnskapen i infrastrukturkoden og lar applikasjonen som helhet kjøre på både klientsiden og serversiden.
- webserveren kan nå bare skrives i javascript
- Isomorphic Web Apps kan aldri Være Progressiv Forbedring for ikke-trivielle apps
- Blokkering vs ikke-blokkering av dataflyt
- Time-to-interaction Og Uncanny Valley
- Mobile enheter fryser under parsing av javascript
- dine beste utviklere er nå opptatt med å ikke produsere verdi
- Sammendrag
- Anerkjennelser
webserveren kan nå bare skrives i javascript
hvis klientkoden og serverkoden er den samme (og klienten kan i dag bare tolke javascript), er vi begrenset til bare å bruke javascript på serveren. Jeg liker node.js veldig mye, men jeg tror det er bedre å være åpen for alternativer i fremtiden, i mitt perspektiv.
Isomorphic Web Apps kan aldri Være Progressiv Forbedring for ikke-trivielle apps
klientsiden javascript har tilgang til en in-memory state maskin som gir mulighet for en finkornet nivå av interaksjon, med en svært lav ventetid (sub-millisekunder). Det samme gjelder ikke FOR HTTP-tilstandsmaskinen, som drives av koblingsklikk og skjemainnsendinger.
For Meg Er Progressiv Forbedring å starte med en grunnlinje som er tilgjengelig for alle mulige enheter / nettlesere, fra gammel til nåværende til fremtidig. I praksis betyr dette en grunnlinje for server – side gjengivelse. Forbedringstrinnet er en forretningsbeslutning om hvor du skal forbedre nettstedet / appen for å øke verdien. Med andre ord gjøres forbedringen i applikasjonskoden (spesifikk) og * ikke * i infrastrukturkoden (generell), bortsett fra optimaliseringsteknikker som pjax eller turbolinks.
Måten For Isomorphic Web Apps å få Progressiv Forbedring er å ta denne finkornet in-memory state machine og «oversette» den for å bare bruke bare lenker og skjemaer. De eneste tilfellene jeg kan se hvor dette er mulig, er hvor du ikke trengte full klientside gjengivelse i utgangspunktet, men i stedet kunne stole på ovennevnte optimaliseringsteknikker og klientsidekomponenter for å forbedre opplevelsen (dvs.en kalenderkomponent for et inntastingsfelt for en dato).
en variant av denne løsningen er å ikke støtte hver klient-side tilstand / overgang i server-side tilstand maskin. I dette tilfellet bør dette være en forretningsbeslutning som må gjenspeiles i søknadskoden, noe som gjør applikasjonskodemiljøet følsomt, noe som går imot ideen Om Isomorfe Webapper.
Måten For Isomorphic Web Apps å få Progressiv Forbedring er å ta denne finkornet in-memory state machine og «oversette» den for å bare bruke bare koblinger og skjemaer.
Blokkering vs ikke-blokkering av dataflyt
gjengivelsessekvensen for web på serversiden og web på klientsiden er forskjellige: serversiden blokkerer og klientsiden blokkerer ikke.
Tenk deg at vi trenger å gjøre to forespørsler til noen tjenester for å gjengi en visning. Vi kan gjøre disse forespørslene parallelt.
på serversiden, hvis den andre forespørselen returnerer først, kan den gjengi den delen av svaret, men må blokkere sending av disse bytene til den første har gjengitt og returnert den delen av svaret tilbake til nettleseren.
denne begrensningen finnes ikke på klientsiden: de to svarene kan håndteres og gjengis uavhengig.
også, jeg tror det ovenfor representerer det enkleste av eksemplene. Tenk deg at du har et tre av komponenter, hvor rotkomponenten er smart (se Presentasjons-Og Beholderkomponenter for en forklaring på smarte/dumme komponenter), etterfulgt av noen få nivåer av dumme komponenter, og deretter minst en bladkomponent som er smart.
infrastrukturen trenger da en måte å sikre at smart leafs kontekst ikke går seg vill, slik at vi mister kontrollen over blokkeringen / ikke-blokkeringen, avhengig av server / klientmodus. En måte å løse dette problemet på kan være å få hele programmet til å bli utført i en fri monad, som representerer utførelsen som data som senere skal tolkes. En annen løsning kan være å bruke noen form for besøksmønster og la komponenter erklære hvilke data de trenger (ligner På Tutorial: Handcrafting en Isomorphic Redux-Applikasjon (With Love)). Sistnevnte er trolig enklest. Mitt poeng er at problemet med forskjellige blokkeringsmoduser er sannsynligvis mye mer komplisert som man forestiller seg i utgangspunktet.
et alternativt design er å ha en regel som sier «bare rotkomponenten kan være en smart komponent», som ligner PÅ HVORDAN DU kan bruke IO Monad I Haskell, holde bladene rene og bare ha bivirkninger på toppnivå. Jeg tror dette designet er bra på serversiden, men ikke på klientsiden: en komponent på klientsiden skal kunne laste inn egne data i minst noen scenarier, for eksempel om sosiale medier relaterte komponenter. Å ha en regel som aldri tillater disse scenariene virker veldig uproduktiv.
Time-to-interaction Og Uncanny Valley
Med Isomorphic Web Apps tilnærming, vil det være en tid hvor brukeren ser grafiske elementer på skjermen som ser ut til å være interaktiv, men ikke. Med andre ord, tiden mellom når nettleseren har gjengitt serverresponsen og når javascript er lastet ned, analysert og utført. Dette kalles «Uncanny Valley» eller «Potemkin Village».
Se denne tweeten og svarene for flere detaljer.
Mobile enheter fryser under parsing av javascript
på en «typisk» mobiltelefon får du 1ms UI – trådstall per 1kb javascript, ifølge denne tweeten. Malte Ubl er teknisk leder AV AMP-prosjektet, så jeg mistenker at han vet hva han snakker om.
dine beste utviklere er nå opptatt med å ikke produsere verdi
Isomorphic Web Apps er En tilnærming som krever et høyt nivå av utviklingsferdighet. På mange områder (i det minste i den vestlige verden) er det vanskelig å finne og rekruttere dyktige utviklere. Å velge Å utvikle Isomorphic Web Apps tildeler de utviklerne til å gjøre noe som jeg spørsmålet gir noen forretningsverdi i det hele tatt. Det finnes bedre måter å bruke tiden sin på.
Sammendrag
Isomorphic Web Apps begrenser webserverens språk / plattformvalg til bare å være javascript. Det har ambisjonen om Å tillate Progressiv Forbedring, men det kan ikke levere. Det introduserer et høyt nivå av teknisk kompleksitet på grunn av forskjellene i blokkering/ikke-blokkering av dataflyt. Det introduserer et tidsvindu hvor ting ser ut til å være interaktive ,men er ikke (The Uncanny Valley). En høy mengde javascript fryser også mobile nettlesere, med tommelfingerregel at 1kb javascript betyr 1ms av stoppet UI-tråd. Og, siden det krever en komplisert programvaredesign, det tar verdifull tid og krefter fra dine beste utviklere – det er bedre måte å gjøre bruk av sin tid.
Til Slutt vil Jeg understreke at dine erfaringer kan være forskjellige fra mine. Kanskje det er scenarier når Isomorphic Web Apps er gode. Men de er ikke en sølvkule for å bygge bro over hvert gap mellom server – side web fordeler og klient – side web fordeler, mens du får ingen av ulempene med begge tilnærminger.
hva synes du? Har du vurdert å «gå isomorphic»? Har du noen tanker om utfordringer og kostnader? Hvordan håndterer du dem?
Anerkjennelser
Takk Til Oskar Wickstrrö Og Per Ö for verdifulle diskusjoner rundt dette emnet. Oskar også anmeldt dette innlegget-takk Oskar.
