SystemJS (angular2.0): caricamento di file separati o riduzione di un grande JS?

Question

Sono un po 'confuso riguardo a SystemJS, sembra che carichi automaticamente i file separatamente e non li compili e li minimizzi in un unico file js.

Ho pensato che l'idea originale stava facendo richieste per file diversi anche se minori sono le cattive pratiche? E un file js grande preferito (minimizzato) e prodotto invece.

Ecco come ho SystemJS installato in questo momento di caricare file separati (vedi sotto), è questo ora il modo consigliato di fare questo?

System.config({ 
      packages: { 
       app: { 
        format: 'register', 
        defaultExtension: 'js' 
       } 
      } 
     }); 
     System.import('app/main') 
       .then(null, console.error.bind(console)); 

Answer 1

System.js (cioè il modulo standard ES6) cambia il flusso di lavoro di sviluppo

In Sviluppo

file separati + vengono utilizzati on-the-fly transpilation fare il test, il ricaricamento e/o il caricamento a caldo dei singoli file funzionano senza dover transpulare/creare l'intero pacchetto di applicazioni dopo ogni modifica.

In Produzione

I singoli file sono transpiled e combinati in un unico-o-più bundle utilizzando utilizzando strumenti come Webpack e JSPM.

Sia JSPM che Webpack (ad esempio dalla versione 2) supportano i moduli ES6 per impostazione predefinita e possono sfruttare il tremolio dell'albero (ad es. Tramite rollup.js) per eliminare il codice non utilizzato nell'output del bundle.

A parte: Eventualmente, quando HTTP2 è supportato dalla maggior parte/tutti i server e lo standard del modulo ES6 è supportato nativamente da tutti i browser, il raggruppamento diventerà un anti-pattern. Il vantaggio del bundling (ovvero la riduzione delle richieste HTTP) non sarà più rilevante, e gli svantaggi (cioè le carenti caratteristiche del caching, l'aumento della complessità di sviluppo) saranno una ragione sufficiente per non usarlo.

Albero Agitazione

Invece di ottimizzare fasci riducendo le importazioni di file, albero scuotendo tracce tutti i percorsi di importazione della applicazione per determinare quale codice sarà incluso nell'output.

Ad esempio, se l'applicazione utilizza gli osservabili di Rxjs per recuperare in modo asincrono i dati, è possibile importare l'intero pacchetto.

import 'rxjs'; 

Questo funziona bene per iniziare ma non è efficiente. La fase di scuotimento dell'albero del processo di raggruppamento non ha un modo per determinare quale codice non viene utilizzato, quindi l'intero pacchetto Rxjs sarà incluso nell'output.

Per ottimizzare le dimensioni del bundle di output, sarebbe preferibile importare solo le funzionalità di Rxjs utilizzate nel codice dell'applicazione.

import { Observable } from 'rxjs/Observable'; 
import { map } from 'rxjs/operators/map'; 
import { startWith } from 'rxjs/operators/startWith'; 

Quando la fase di agitazione albero viene eseguito, sarà comprendono solo il codice dal pacchetto Rxjs necessario creare un Observable e utilizzare gli operatori map e startWith.

Transpilation

Oltre a albero di agitazione e bundling, avrete anche bisogno di una strategia per la transpile/fonte tipografico ES6 ad ES5. Tradizionalmente, gli strumenti di automazione come Grunt o Gulp venivano utilizzati manualmente specificando i passaggi necessari per trasporre, concatenare, minimizzare/rendere più agevole il codice sia per lo sviluppo che per la produzione.

JSPM può gestire tutto questo creando un self-executing fascio

jspm bundle-sfx app/main dist/main --uglify 

Webpack può ottenere lo stesso

webpack -p app/main.js dist/main.js 

Oltre a ES6/transpilation tipografico, entrambi gli strumenti possono anche pale leva/plugin per supportare altri tipi di file come css e scss.