viimeisen kahden vuoden aikana olen kuullut, että termi Isomorfiset verkkosovellukset mainitaan myönteiseen sävyyn yhä useammin. Myös tänä aikana, olen tehnyt joitakin ajatellut itse tekniikkaa. Johtopäätökseni on, että Isomorfiset verkkosovellukset eivät tuo lisäarvoa minulle tai tyypillisille organisaatioille, joille työskentelen. Monet asiat ovat johtaneet minut tähän johtopäätökseen.
mutta ennen kuin luettelen syitä, haluan korostaa ensin, että ajattelen isomorfisia javascript-kirjastoja (eli lodashia.js) ovat mahtavia. Mielestäni myös yksittäiset isomorfiset komponentit voivat olla arvokkaita, esimerkiksi elävä päivitetty osakemarkkinoiden indikaattori.
syyt siihen, miksi en usko isomorfisten verkkosovellusten olevan arvokkaita minulle tai organisaatioille, joille työskentelen, ovat:
- WWW-palvelin voidaan nyt kirjoittaa vain JavaScriptillä
- Isomorfiset verkkosovellukset eivät voi koskaan olla progressiivisia ei-triviaaleille sovelluksille
- esto vs ei-estävä datavirta
- aika vuorovaikutukseen ja Uncanny Valley
- Mobiililaitteet jäätyvät JavaScriptin jäsennyksen aikana
- parhaat kehittäjäsi ovat nyt kiireisiä eivätkä tuota arvoa
haluan aloittaa määrittelemällä isomorfiset verkkosovellukset. Isomorfinen verkkosovellus on verkkosovellus, jossa sovelluskoodilla ei ole tietoa siitä, missä sitä ajetaan. Sen sijaan tämä tieto säilytetään infrastruktuurikoodissa, ja sen avulla koko sovellus voi toimia sekä asiakas-että palvelinpuolella.
- WWW-palvelin voidaan nyt kirjoittaa vain JavaScriptillä
- Isomorfiset verkkosovellukset eivät voi koskaan olla progressiivisia lisälaitteita ei-triviaaleille sovelluksille
- esto vs ei-estävä datavirta
- Time-to-interaction and the Uncanny Valley
- Mobiililaitteet jäätyvät jäsennettäessä JavaScriptiä
- parhaat kehittäjäsi ovat nyt kiireisiä eivätkä tuota arvoa
- Summary
- kiitokset
WWW-palvelin voidaan nyt kirjoittaa vain JavaScriptillä
jos asiakaskoodi ja palvelinkoodi on sama (ja asiakas voi nykyään tulkita vain JavaScriptiä), silloin rajoitutaan käyttämään vain JavaScriptiä palvelimella. Pidän node.js hyvin paljon, mutta mielestäni on parempi olla avoin vaihtoehdoille tulevaisuudessa, minun näkökulmastani.
Isomorfiset verkkosovellukset eivät voi koskaan olla progressiivisia lisälaitteita ei-triviaaleille sovelluksille
asiakaspuolen JavaScriptillä on pääsy muistitilakoneeseen, joka mahdollistaa hienorakeisen vuorovaikutuksen tason hyvin pienellä latenssilla (alimillisekunnit). Sama ei pidä paikkaansa HTTP – valtiokoneessa, jota ohjaavat linkin klikkaukset ja lomakkeet.
minulle progressiivinen parannus on aloittaa perustasosta, joka on kaikkien mahdollisten laitteiden/selainten käytettävissä, vanhoista nykyisistä tulevaisuuteen. Käytännössä tämä tarkoittaa palvelinpuoleisen renderöinnin perustasoa. Tehostamisvaihe on liiketoimintapäätös siitä, missä sivustoa/sovellusta parannetaan arvon lisäämiseksi. Toisin sanoen parannukset tehdään sovelluskoodissa (erityinen) ja *ei* infrastruktuurikoodissa (yleinen), lukuun ottamatta optimointitekniikoita, kuten pjax tai turbolinks.
tapa, jolla Isomorfiset verkkosovellukset saavat progressiivisen parannuksen, on ottaa tämä hienorakeinen muistitilakoneisto ja ”kääntää” se käyttämään vain linkkejä ja lomakkeita. Ainoat tapaukset, joissa tämä on mahdollista, ovat tapaukset, joissa et tarvinnut koko asiakaspuolen renderöintiä, vaan voit luottaa edellä mainittuihin optimointitekniikoihin ja asiakaspuolen komponentteihin kokemuksen parantamiseksi (eli kalenterikomponentti päivämäärän syöttökentälle).
tämän ratkaisun muunnelma ei tue jokaista asiakaspuolen tilaa / siirtymää palvelinpuolen tilakoneessa. Tällöin kyseessä pitäisi olla liiketoimintapäätös, jonka pitää näkyä sovelluskoodissa, jolloin sovelluskoodiympäristöstä tulee herkkä, mikä on vastoin Isomorfisten verkkosovellusten ideaa.
tapa, jolla Isomorfiset verkkosovellukset saavat progressiivisen parannuksen, on ottaa tämä hienorakeinen muistitilakoneisto ja ”kääntää” se käyttämään vain linkkejä ja lomakkeita.
esto vs ei-estävä datavirta
palvelinpuolen Webin ja asiakaspuolen Webin renderöintisarja on erilainen: palvelinpuolen blokit ja asiakaspuolen eivät blokaa.
Kuvittele, että meidän täytyy tehdä kaksi pyyntöä joihinkin Palveluihin saadaksemme näkymän. Voimme tehdä nämä pyynnöt rinnakkain.
palvelinpuolella, jos toinen pyyntö palaa ensin, se voi renderoida kyseisen osan vastauksesta, mutta sen on estettävä näiden tavujen lähettäminen, kunnes ensimmäinen on renderöinyt ja palauttanut kyseisen osan vastauksesta takaisin selaimeen.
asiakaspuolella tätä rajoitetta ei ole: nämä kaksi vastausta voidaan käsitellä ja suorittaa itsenäisesti.
myös edellä mainitut edustavat mielestäni yksinkertaisimpia esimerkkejä. Kuvittele, että sinulla on komponenttien puu, jossa juurikomponentti on älykäs (katso esitelmä-ja Säiliökomponentit älykkäiden/tyhmien komponenttien selitystä varten), jota seuraa muutama taso tyhmiä komponentteja ja sitten ainakin yksi lehtikomponentti, joka on älykäs.
infrastruktuuri tarvitsee sitten tavan varmistaa, että smart Leafin konteksti ei eksy, jolloin menetämme esto/estottoman suorituksen hallinnan palvelimesta/asiakastilasta riippuen. Yksi tapa ratkaista tämä ongelma voisi olla tehdä koko ohjelma suoritettavaksi vapaalla monadilla, joka esittää suorituksen datana myöhemmin tulkittavaksi. Toinen ratkaisu voisi olla käyttää jonkinlaista kävijämallia ja antaa komponenttien ilmoittaa, mitä tietoja he tarvitsevat (kuten opetusohjelma: käsityönä isomorfinen Redux-sovellus (rakkaudella)). Jälkimmäinen lienee helpoin vaihtoehto. Minun pointtini on, että ongelma eri esto tilat ovat luultavasti paljon monimutkaisempi, että yksi kuvittelee aluksi.
vaihtoehtona on sääntö, jonka mukaan ”vain juurikomponentti voi olla älykäs komponentti”, samaan tapaan kuin Haskellin IO Monad-laitetta voi käyttää, jolloin lehdet pysyvät puhtaina ja niillä on vain sivuvaikutuksia ylätasolla. Mielestäni tämä rakenne on hyvä palvelinpuolella, mutta ei asiakaspuolella: asiakkaan puolella olevan komponentin pitäisi pystyä lataamaan omia tietojaan ainakin joissakin skenaarioissa, esimerkiksi sosiaaliseen mediaan liittyvien komponenttien osalta. Sääntö, joka ei koskaan salli näitä skenaarioita, tuntuu hyvin tuottamattomalta.
Time-to-interaction and the Uncanny Valley
Isomorfisen Web Apps-lähestymistavan avulla käyttäjä näkee ruudulla graafisia elementtejä, jotka vaikuttavat interaktiivisilta, mutta eivät ole. toisin sanoen aika, joka kuluu siitä, kun selain on renderoinut palvelimen vastauksen Ja kun javascript Ladataan, jäsennetään ja suoritetaan. Tätä kutsutaan nimellä” Uncanny Valley ”tai”Potemkinin kylä”.
Katso tästä twiitistä ja vastauksista lisätietoja.
Mobiililaitteet jäätyvät jäsennettäessä JavaScriptiä
”tyypillisessä” matkapuhelimessa, saat 1MS UI-säiettä stall per 1KB javascript, tämän twiitin mukaan. Malte Ubl on AMP-projektin tekninen johtaja, joten epäilen, että hän tietää, mistä puhuu.
parhaat kehittäjäsi ovat nyt kiireisiä eivätkä tuota arvoa
isomorfiset verkkosovellukset on lähestymistapa, joka vaatii korkeaa kehitystaitoa. Monilla aloilla (ainakin länsimaissa) on vaikea löytää ja rekrytoida korkeasti koulutettuja kehittäjiä. Valitsemalla kehittää Isomorphic Web Apps allocates nämä kehittäjät tehdä jotain, että kyseenalaistan tuottaa mitään liiketoiminnan arvoa ollenkaan. On parempiakin tapoja käyttää aikaansa.
Summary
Isomorfiset verkkosovellukset rajoittavat www-palvelinkielen/Alustan valinnan vain JavaScriptiksi. Sillä on kunnianhimoinen tavoite mahdollistaa asteittainen parantaminen, mutta se ei voi saavuttaa tuloksia. Se tuo korkean tason teknistä monimutkaisuutta johtuen eroista esto / ei-esto tiedonkulun. Se esittelee aikaikkunan, jossa asiat näyttävät olevan interaktiivisia, mutta eivät ole (the Uncanny Valley). Suuri määrä JavaScriptiä jäädyttää myös mobiiliselaimet, sillä peukalosäännöllä, että 1KB JavaScriptiä tarkoittaa 1ms stalled UI-säiettä. Ja koska se vaatii monimutkaista ohjelmistosuunnittelua, se vie arvokasta aikaa ja vaivaa parhailta kehittäjiltäsi-on olemassa parempi tapa käyttää aikaansa.
lopuksi haluan korostaa, että sinun kokemuksesi saattavat olla erilaisia kuin minun. Ehkä on skenaarioita, joissa Isomorfiset verkkosovellukset ovat hyviä. Mutta ne eivät ole Hopealuoti, joka yhdistää jokaisen aukon palvelinpuolen web-etujen ja asiakaspuolen web-etujen välillä, samalla kun ne eivät saa mitään molempien lähestymistapojen haitoista.
mitä mieltä olet? Oletko harkinnut ”menemistä isomorfiseksi”? Onko sinulla ajatuksia haasteista ja kustannuksista? Miten hoidat heidät?
kiitokset
Kiitos Oskar Wickströmille ja Per Ökvistille arvokkaista keskusteluista aiheen ympärillä. Oskar arvosteli myös tämän postauksen-kiitos Oskar.
