Quali sono i pro e i contro di Asset-Pipeline/Turbolinks di Rails 4 per una grande applicazione?

Question

Stiamo lavorando a un'applicazione piuttosto ampia e ampia. Il sito Web avrà molte sezioni diverse con alcuni requisiti e comportamenti dell'interfaccia utente molto diversi.

Guardando al futuro, Rails 4 ha separato la pipeline degli asset in una gemma separata in modo che possiamo scegliere di includerla o meno. La stessa cosa potrebbe accadere con i turbolinks.

La domanda che continuo a chiedermi in questi giorni e non riesco a trovare una risposta è: dovrei usare queste biblioteche nel nostro progetto o no?

I problemi principali nella mia riflessione è il fatto che la strategia di file all-in-one probabilmente non funzionerà e dovremo utilizzare i bundle di file nelle diverse parti dell'applicazione. Come reagirà con i turbolinks, perché deve presupporre che tutti i js/css siano già stati caricati? I vantaggi di tale configurazione superano la complessità del codice implicita sia dalla pipeline che dai turbolinks?

Non mi aspetto una risposta Sì/No, solo alcune opinioni sull'argomento.

Answer 1

Entrambi sono strumenti validi che non necessariamente si annullano a vicenda.

Turbolinks: consente di caricare solo il corpo di una pagina, facendolo funzionare come una richiesta AJAX (un esempio di un simile comportamento sarebbe quello di Facebook).

Vantaggi:

• salta il compito del browser di rendere pienamente una nuova pagina, eliminando così il tempo di "pagina bianca" in cui il browser non risponde.
• Correlato con il precedente: Nel caso in cui si stia riscontrando un comportamento che potrebbe essere influenzato dal caricamento di una nuova pagina, come si supponga, riproducendo un brano, i turbolink non lo influenzeranno (vedere la prossima soundcloud).
• Non ricarica la testina del documento, quindi non carica gli stessi tag/contenuto due volte (se è lo stesso).
• Consente di memorizzare nella cache il contenuto della visualizzazione sul lato server.

Svantaggi:

• A trascinare se tag di intestazione davvero bisogno di essere aggiornato (nuovi file js, css nuovi file, aggiornamento metatag ...)
• Se si desidera utilizzare sul lato client visualizzare il rendering, non è solo lo strumento per questo.
• Il comportamento predefinito per disabilitare il comportamento è solo doloroso (utilizzando le classi CSS per disabilitare i tag di ancoraggio all'interno di una sezione? Che fa schifo).

In realtà è una questione di cosa sia l'architettura della tua app, che cosa ha come target.

A proposito di pipeline di asset, ho avuto risultati contrastanti, anche se direi che ha più vantaggi che svantaggi. Nel complesso, gli strumenti di pre-elaborazione migliorano la produttività dello sviluppo di più browser, ma non si basano su di esso nella produzione. Ma nel caso del pipelining delle risorse, deve fare altrettanto bene con ciò che si desidera. Puoi pre-elaborare SASS, Coffeescript, hai librerie grandiose come bussola o bourbon, ma questo può anche aumentare le tue prestazioni generali. Quindi, confrontalo e vedi se questi dovrebbero essere strumenti per te.

Answer 2

Cominciamo con un post sugli svantaggi: http://eviltrout.com/2013/01/06/turbolinks-and-the-prague-effect.html

Se questo non è un problema per voi: http://geekmonkey.org/2012/09/introducing-turbolinks-for-rails-4-0/

Per avvolgere le cose: Turbolinks migliorerà la vostra pagina di carico in modo significativo se il vostro le pagine condividono lo stile di JavaScript e CSS. PJAX è utile quando le prestazioni lato server sono un problema.

• Spero che questo aiuti :)