¿Cuáles son las diferencias entre SystemJS y Webpack?

SystemJS funciona en el lado del cliente. Carga módulos (archivos) dinámicamente bajo demanda cuando se necesitan. No tienes que cargar toda la aplicación por adelantado. Puede cargar un archivo, por ejemplo, dentro de un controlador de clic de botón.

Código SystemJS:

// example import at top of file
import myModule from 'my-module'
myModule.doSomething()

// example dynamic import (could be placed anywhere in your code)
// module not loaded until code is hit
System.import('my-module').then((myModule) {
  // myModule is available here
  myModule.doSomething()
});

Aparte de configurarlo para que funcione, ¡eso es todo lo que hay en SystemJS! Ahora eres un SystemJS pro!

Webpack es completamente diferente y lleva una eternidad dominarlo. No hace lo mismo que SystemJS pero, cuando usando Webpack, SystemJS se vuelve redundante.

Webpack prepara un único archivo llamado bundle.js-Este archivo contiene todo HTML, CSS, JS, etc. Debido a que todos los archivos se agrupan en un solo archivo, ahora no hay necesidad de un cargador perezoso como SystemJS (donde los archivos individuales se cargan según sea necesario).

La ventaja de SystemJS es esta carga lenta. La aplicación debe cargar más rápido porque no está cargando todo en un solo golpe.

La ventaja de Webpack es que, aunque la aplicación puede tome unos segundos para cargar inicialmente, una vez cargado y almacenado en caché es muy rápido.

Prefiero SystemJS pero Webpack parece ser más de moda.

Angular2 quickstart utiliza SystemJS.

Angular CLI utiliza Webpack.

Webpack 2 (que ofrecerá tree shaking) está en beta, por lo que tal vez sea un mal momento para pasar a Webpack.

Nota SystemJS está implementando el estándar de carga de módulos ES6. Webpack es solo otro módulo npm.

Corredores de tareas (opcional lectura para aquellos que quieren entender el ecosistema en el que SystemJS podría existir)

Con SystemJS su única responsabilidad es la carga lenta de archivos, por lo que todavía se necesita algo para reducir esos archivos, transpilar esos archivos (por ejemplo, de SASS a CSS), etc. Estos trabajos que deben realizarse se conocen como tareas.

Webpack, cuando está configurado, hace esto correctamente por usted (y agrupa la salida). Si quieres hacer algo similar con SystemJS normalmente utilice un ejecutor de tareas JavaScript. El ejecutor de tareas más popular es otro módulo npm llamado gulp.

Así que, por ejemplo, SystemJS podría cargar perezosamente un archivo JavaScript minificado que ha sido minificado por gulp. Gulp, cuando se configura correctamente, puede minificar archivos sobre la marcha y recargar en vivo. La recarga en vivo es la detección automática de un cambio de código y una actualización automática del navegador para actualizar. Excelente durante el desarrollo. Con CSS, la transmisión en vivo es posible (es decir, verá la página actualizar el nuevo estilos sin que la página se vuelva a cargar).

Hay muchas otras tareas que Webpack y gulp pueden realizar que serían demasiado numerosas para cubrir aquí. He proporcionado un ejemplo:)

Hasta ahora estaba usando systemjs. Estaba cargando archivos uno por uno y la primera carga estaba tomando 3-4 segundos sin archivos minificados. Después de cambiar a webpack obtuve una gran mejora en el rendimiento. Ahora solo se necesita cargar un archivo de paquete (también polyfills y libs de proveedores que casi nunca cambian y casi siempre se almacenan en caché) y eso es todo. Ahora solo toma un segundo cargar la aplicación del lado del cliente. No hay lógica adicional del lado del cliente. Como menor el número de archivos individuales cargados como mayor el rendimiento. Al usar systemjs, debe pensar en importar módulos dinámicamente para guardar el rendimiento. Con webpack te centras principalmente en tu lógica porque el rendimiento seguirá siendo bueno una vez que el paquete se minimice y se almacene en caché en tu navegador.