Contenuto
Dan Webb, responsabile tecnico di Twitter, team web core, ha sottolineato in un post sul blog che Twitter deve rielaborare la sua architettura sottostante per aumentare le prestazioni. Le modifiche vedranno Twitter allontanarsi dall'approccio all'architettura delle applicazioni web pesanti JavaScript della fine del 2010, con la società "che lavora per riprendere il controllo delle […] prestazioni front-end spostando il rendering sul server".
Secondo Webb, i tempi di caricamento della pagina iniziale saranno un quinto di quelli che erano in precedenza e altre modifiche dovrebbero aiutare il team di Twitter ad aggiungere più rapidamente nuove funzionalità in futuro. Una delle modifiche più ovvie per coloro che prestano attenzione agli indirizzi web sarà la rimozione dell'hashbang durante la transizione. "Quando vieni su twitter.com, vogliamo che tu veda i contenuti il prima possibile. Con gli URL hashbang, il browser deve scaricare una pagina HTML, scaricare ed eseguire un po 'di JavaScript, riconoscere il percorso hashbang (che è visibile solo al browser), quindi recupera e visualizza il contenuto per quell'URL ", ha spiegato Webb. "Eliminando la necessità di gestire il routing sul client, rimuoviamo molti di questi passaggi e riduciamo il tempo necessario per scoprire cosa sta succedendo su twitter.com".
Gli sviluppatori rispondono ai piani di Twitter
Il "Nuovo Twitter" non è mai stato molto popolare. Tim Bray si è lamentato del modo in cui gli hashbang infrangono il web e quasi esattamente un anno fa, lo stesso Webb ha dichiarato di non essere soddisfatto dell'uso dell'hashbang.
Oggi, la maggior parte degli sviluppatori è comprensibilmente soddisfatta dell'annuncio di Twitter. L'evangelista degli sviluppatori di Mozilla Christian Heilmann ha dichiarato a .net: "Adoro questo cambiamento. Gli URL hashbang sono un terribile hack e sono necessari solo per ambienti che non supportano l'API pushState della cronologia. Mi piace anche che Twitter mostri l'argomento più menzionato sulla necessità di gli hashbang in passato - le prestazioni - sono fasulli ". Ha aggiunto che gli URL dovrebbero essere "URL reali che possono essere seguiti in un ambiente senza JavaScript o un browser" e sperava che altri seguissero l'esempio di Twitter, forse tramite Twitter "fornendo numeri a sostegno della sua decisione, sfatando così i miti sull'eccellente percepito prestazioni delle app solo JavaScript. "
Lo sviluppatore Mark Damon Hughes ci ha detto che l'approccio di Twitter per il nuovo Twitter era condannato fin dall'inizio. "C'è un modo pulito e moderno per creare un sito dinamico: avere un piccolo stub di HTML, jQuery e JavaScript in un file statico. Questo richiama il server nelle query AJAX e riempie la pagina. Se lo fai bene , riduci la larghezza di banda e i tempi di caricamento. Puoi inserire la maggior parte del tuo sito su CDN vicino all'utente. "
Hughes ha spiegato che questo non è ciò che ha fatto Twitter: "Ha creato un client enorme e grasso che si caricava lentamente, caricava l'intera home page con una grande immagine di sfondo e feed, quindi lo sostituiva con quello che avevi effettivamente richiesto". Ma ha anche detto che l'architettura aggiornata di per sé non sarà una bacchetta magica per il servizio: "Twitter sta tornando a una pagina renderizzata dal server, che per una singola query come la visualizzazione di un tweet sarà più veloce per il server del servizio e il utente. Ma se poi raggiungi la pagina di un utente, o la tua, o fai qualcosa che necessita di un ricaricamento, Twitter deve inviare di nuovo l'intera pagina come se fosse ancora il 1995, o tornare al fat client e ad AJAX. Forse un giorno ridurrò quel cliente ... "
