Arresto del Javascript sul lato client da trasformare in un monolite

Il moderno approccio JS è:

• Conserva molti file sorgente separati * .js, più o meno come facciamo nei linguaggi OO
• Utilizza una pipeline di build JavaScript come gulp o grunt per concatenare e ridimensionare i file * .js in una singola risorsa prima della spedizione

Questo ti permette di:

• Evita file enormi e mantieni la leggibilità del codice
• Consegna tutti i file al browser in una singola richiesta miniata

Per applicazioni molto grandi, anche il singolo asset minificato potrebbe diventare troppo grande. È qui che arrivano caricatori di moduli come requirejs - che ti consentono di caricare solo ciò di cui hai bisogno.

Per evitare un file monolite contenente tutto il codice della tua applicazione, puoi utilizzare due tecniche:

• quadri. Esistono numerosi framework JavaScript che ti consentono di dichiarare dipendenze tra i file e caricare tali file su richiesta. Un framework popolare è RequireJS .

  Questo ti dà un approccio diretto dove tutto il lavoro di dipendenza è fatto per te, e puoi concentrarti sulla codifica, come fai nella maggior parte dei linguaggi mainstream come Python, Java o C #. Nota che Node.js segue un approccio simile.

• Modello di modulo . Qui, non stai facendo affidamento su una libreria di terze parti per le dipendenze, ma semplicemente dividi il tuo codice in parti che sono molto isolate l'una dall'altra. Dato che hai familiarità con OOP, il modulo sarebbe vicino allo stesso tempo a un oggetto e uno spazio dei nomi: troverai modi per dichiarare chiaramente quali funzioni possono essere chiamate dal mondo esterno e mantenere private le altre funzioni.

  Una volta che hai i tuoi moduli separati, puoi dividere il tuo file monolite in file più piccoli, di solito un file per modulo. Da lì, hai una scelta: o semplicemente carichi tutti i file uno alla volta dal browser ogni volta (che non è uguale a "ogni richiesta": se hai configurato correttamente la memorizzazione nella cache sul lato client, i file verranno memorizzati nella cache per molto tempo). Oppure raggruppa tutti i tuoi file in uno (o diversi, nel caso in cui abbia senso) per ridurre il numero di richieste.

  Se vuoi raggruppare questi file, ci sono un sacco di librerie sul lato server che lo fanno. A seconda del tuo ambiente, puoi cercarne uno o scriverne uno da solo.

  La minificazione potrebbe anche essere una buona idea e Google Closure Compiler è una delle tue opzioni. Tieni presente che il compilatore di Google Closure presenta livelli diversi da un semplice "omaggi dello spazio bianco" a una trasformazione molto efficace e molto aggressiva del tuo codice. Se provi a usare quello aggressivo sul codice esistente, è probabile che non sarai affatto soddisfatto dei risultati. Ci vuole tempo per abituarsi a come Google Closure Compiler, a questo livello, vuole che tu scriva il tuo codice.

Si noti che il raggruppamento del codice JavaScript non porta necessariamente a prestazioni migliori. Se, ad esempio, il tuo sito web ha molte pagine e ogni pagina usa un codice comune, l'approccio RequireJS significherebbe due cose:

• Un utente che arriva su questa pagina scaricherà solo un piccolo frammento di tutto il codice JavaScript, cioè ciò che è necessario per questa pagina. Spingere un enorme pacchetto composto da dozzine di file per il tuo utente che ne ha solo bisogno due o tre non è la cosa più bella che puoi fare.

• Se modifichi frequentemente uno dei file, RequireJS scaricherà semplicemente la nuova versione di questo file per gli utenti che hanno già visitato il tuo sito in precedenza. Se si tratta di un pacchetto, una piccola modifica invalida l'intero pacchetto.

Si noti che il raggruppamento e la minimizzazione sono due cose diverse. Puoi fare l'uno senza l'altro.

Infine, ricorda che ci sono alcuni aspetti molto importanti che dovrebbero essere la tua preoccupazione principale:

• Memorizzazione nella cache sul lato client. I file JavaScript possono e spesso devono essere memorizzati nella cache per un tempo molto lungo, senza che il browser debba nemmeno eseguire il controllo e ricevere HTTP 304 non modificato in risposta. Ciò significa anche che ogni volta che si modifica un file JavaScript, tutti i collegamenti ad esso devono essere modificati, ovvero http://cdn.example.com/js/hello.js diventerà http://cdn.example.com/js/hello.js?r=1 , quindi http://cdn.example.com/js/hello.js?r=2 , ecc.

• CDN. Se stai servendo utenti cinesi dall'Europa, o utenti indiani dagli Stati Uniti, stai sbagliando. Ancora più importante, se stai servendo contenuti statici dal tuo server che è già responsabile di contenuti dinamici, potresti non solo degradare le prestazioni, ma anche pagare semplicemente troppo per la larghezza di banda. Servizi come Amazon CloudFront assicurano prestazioni di consegna eccellenti per il tuo contenuto statico.