Negli ultimi due anni, ho sentito il termine Applicazioni Web isomorfe menzionato in modo positivo sempre più frequentemente. Anche durante questo periodo, ho fatto un po ‘ di pensare me stesso sulla tecnica. La mia conclusione è che le app Web isomorfe sono qualcosa che non aggiungerebbe valore per me o per le tipiche organizzazioni per cui lavoro. Diverse cose mi hanno portato a questa conclusione.
Ma, prima di elencare le ragioni, vorrei prima sottolineare che penso librerie javascript isomorfe(cioè lodash.js) sono fantastici. Inoltre, penso che i componenti isomorfi isolati possano essere preziosi, ad esempio un indicatore del mercato azionario aggiornato in tempo reale.
I motivi per cui non credo che le app Web isomorfe siano preziose per me o per le organizzazioni per cui lavoro sono:
- Il web server può solo essere scritto in javascript
- Isomorfi Web Apps non può mai essere graduale per non banale apps
- Blocco vs non-blocco del flusso di dati
- Ora-a-interazione e l’Uncanny Valley
- dispositivi Mobili freeze durante l’analisi di javascript
- i Tuoi migliori sviluppatori sono ora impegnati non produce valore
voglio iniziare con una definizione di Isomorfi Web Apps. Un’app Web isomorfa è un’app Web in cui il codice dell’applicazione non è a conoscenza di dove viene eseguito. Invece, questa conoscenza viene mantenuta nel codice dell’infrastruttura e consente all’applicazione nel suo complesso di funzionare sia sul lato client che sul lato server.
- Il server web può ora essere scritto solo in javascript
- Le app Web isomorfe non possono mai essere un miglioramento progressivo per app non banali
- Blocco vs flusso di dati non bloccante
- Ora-a-interazione e l’Uncanny Valley
- I dispositivi mobili si bloccano durante l’analisi di javascript
- I tuoi migliori sviluppatori sono ora impegnati a non produrre valore
- Sommario
- Ringraziamenti
Il server web può ora essere scritto solo in javascript
Se il codice client e il codice server sono gli stessi (e il client può oggi solo interpretare javascript), quindi siamo limitati a utilizzare solo javascript sul server. Mi piace il nodo.js molto, ma penso che sia meglio essere aperti alle alternative in futuro, nella mia prospettiva.
Le app Web isomorfe non possono mai essere un miglioramento progressivo per app non banali
Lato client javascript ha accesso a una macchina a stati in memoria che consente un livello di interazione a grana fine, con una latenza molto bassa (sub-millisecondi). Lo stesso non è vero per la macchina a stati HTTP, che è guidata da clic di collegamento e invio di moduli.
Per me, il miglioramento progressivo è iniziare con una linea di base accessibile a tutti i possibili dispositivi/browser, dal vecchio all’attuale al futuro. In pratica, ciò significa una linea di base del rendering lato server. La fase di miglioramento è una decisione aziendale su dove migliorare il sito / app per aumentare il valore. In altre parole, il miglioramento avviene nel codice dell’applicazione (specifico) e *non* nel codice dell’infrastruttura (generale), ad eccezione delle tecniche di ottimizzazione come pjax o turbolinks.
Il modo per le app Web isomorfe per ottenere un miglioramento progressivo è prendere questa macchina a stati in memoria a grana fine e “tradurla” per utilizzare solo collegamenti e moduli. Gli unici casi in cui posso vedere dove ciò è possibile sono in cui non è necessario il rendering completo lato client, ma è possibile fare affidamento sulle tecniche di ottimizzazione sopra menzionate e sui componenti lato client per migliorare l’esperienza (ad esempio un componente del calendario per un campo di input per una data).
Una variante di questa soluzione consiste nel non supportare ogni stato/transizione lato client nella macchina a stati lato server. In questo caso, questa dovrebbe essere una decisione aziendale che deve essere riflessa nel codice dell’applicazione, rendendo l’ambiente del codice dell’applicazione sensibile, il che va contro l’idea di applicazioni Web isomorfe.
Il modo per le app Web isomorfe per ottenere un miglioramento progressivo è prendere questa macchina a stati in memoria a grana fine e “tradurla” per utilizzare solo collegamenti e moduli.
Blocco vs flusso di dati non bloccante
La sequenza di rendering per il Web lato server e il Web lato client sono diversi: i blocchi lato server e il lato client non bloccano.
Immagina di dover fare due richieste ad alcuni servizi per rendere una vista. Possiamo fare queste richieste in parallelo.
Sul lato server, se la seconda richiesta ritorna per prima, può rendere quella parte della risposta ma deve bloccare l’invio di quei byte fino a quando il primo non ha reso e restituito quella parte della risposta al browser.
Sul lato client, questo vincolo non esiste: le due risposte possono essere gestite e renderizzate in modo indipendente.
Inoltre, penso che quanto sopra rappresenti il più semplice degli esempi. Immagina di avere un albero di componenti, in cui il componente radice è intelligente (vedi Componenti di presentazione e contenitore per una spiegazione dei componenti intelligenti/stupidi), seguito da alcuni livelli di componenti stupidi e quindi almeno un componente foglia che è intelligente.
L’infrastruttura ha quindi bisogno di un modo per assicurarsi che il contesto di smart leaf non si perda, in modo da perdere il controllo dell’esecuzione di blocco/non blocco, a seconda della modalità server/client. Un modo per risolvere questo problema potrebbe essere quello di eseguire l’intero programma in una monade libera, rappresentando l’esecuzione come dati da interpretare in seguito. Un’altra soluzione potrebbe essere quella di utilizzare qualche forma di modello di visitatore e lasciare che i componenti dichiarino quali dati hanno bisogno (simile a Tutorial: Handcrafting an Isomorphic Redux Application (With Love)). Quest’ultimo è probabilmente più facile. Il mio punto è che il problema delle diverse modalità di blocco è probabilmente molto più complicato che si immagina inizialmente.
Un progetto alternativo è quello di avere una regola che dice “solo il componente radice può essere un componente intelligente”, simile a come si potrebbe usare la Monade IO in Haskell, mantenendo le foglie pure e avendo solo effetti collaterali al livello superiore. Penso che questo design sia buono sul lato server ma non sul lato client: un componente sul lato client dovrebbe essere in grado di caricare i propri dati in almeno alcuni scenari, ad esempio per quanto riguarda i componenti relativi ai social media. Avere una regola che non consente mai questi scenari sembra molto improduttivo.
Ora-a-interazione e l’Uncanny Valley
Con il Isomorfi Web Apps approccio, ci sarà un tempo in cui l’utente vede elementi grafici sullo schermo che sembra essere interattivo, ma non lo sono. In altre parole, il tempo tra quando il browser ha reso la risposta del server e quando javascript è scaricato, analizzati e giustiziato. Questa è chiamata “Valle misteriosa”o” Villaggio di Potemkin”.
Vedi questo tweet e le risposte per maggiori dettagli.
I dispositivi mobili si bloccano durante l’analisi di javascript
Su un telefono cellulare “tipico”, si ottiene uno stallo del thread dell’interfaccia utente di 1 ms per javascript da 1 KB, secondo questo tweet. Malte Ubl è il capo tecnico del progetto AMP, quindi sospetto che sappia di cosa sta parlando.
I tuoi migliori sviluppatori sono ora impegnati a non produrre valore
Isomorphic Web Apps è un approccio che richiede un alto livello di abilità di sviluppo. In molte aree (nel mondo occidentale, almeno), è difficile trovare e reclutare sviluppatori altamente qualificati. La scelta di sviluppare app Web isomorfe alloca quegli sviluppatori a fare qualcosa che metto in discussione produce alcun valore aziendale. Ci sono modi migliori per fare uso del loro tempo.
Sommario
Le applicazioni Web isomorfiche limitano la scelta della lingua/piattaforma del server Web per essere solo javascript. Ha l’ambizione di consentire un miglioramento progressivo, ma non può fornire risultati. Introduce un alto livello di complessità tecnica a causa delle differenze nel flusso di dati di blocco/non blocco. Introduce una finestra temporale in cui le cose sembrano essere interattive, ma non lo sono (the Uncanny Valley). Un’elevata quantità di javascript blocca anche i browser mobili, con la regola empirica che 1KB di javascript significa 1ms di thread UI in stallo. E, dal momento che richiede una progettazione software complicato, ci vuole tempo prezioso e fatica dai vostri migliori sviluppatori-ci sono modo migliore per fare uso del loro tempo.
Infine, voglio sottolineare che le tue esperienze potrebbero essere diverse dalle mie. Forse ci sono scenari in cui le app Web isomorfe sono buone. Ma non sono un proiettile d’argento per colmare ogni divario tra i vantaggi Web lato server e i vantaggi Web lato client, pur non ottenendo nessuno degli svantaggi di entrambi gli approcci.
Cosa ne pensi? Hai considerato “going isomorphic”? Hai qualche idea sulle sfide e sui costi? Come si fa a trattare con loro?
Ringraziamenti
Grazie a Oskar Wickström e Per Ökvist per le preziose discussioni su questo argomento. Oskar anche recensito questo post – grazie Oskar.
