SystemJS works client side. It loads modules (files) dynamically on demand when they are needed. You don’t have to load the entire app up front. You could load a file, for example, inside a button click handler.
// example import at top of file
import myModule from 'my-module'
// example dynamic import (could be placed anywhere in your code)
// module not loaded until code is hit
// myModule is available here
Other than configuring it to work, that’s all there is to SystemJS! You are now a SystemJS pro!
Webpack is entirely different and takes forever to master. It does not do the same thing as SystemJS but, when using Webpack, SystemJS becomes redundant.
Webpack prepares a single file called bundle.js – This file contains all HTML, CSS, JS, etc. Because all files are bundled in a single file, there is now no need for a lazy loader like SystemJS (where individual files
are loaded as needed).
The upside of SystemJS is this lazy loading. The app should load faster because you are not loading everything in one hit.
The upside of Webpack is that, although the app may take a few seconds to load initially, once loaded and cached it is lightning fast.
I prefer SystemJS but Webpack seems to be trendier.
Angular2 quickstart uses SystemJS.
Angular CLI uses Webpack.
Webpack 2 (which will offer tree shaking) is in beta so maybe it’s a bad time to move to Webpack.
Note SystemJS is implementing the ES6 module loading standard. Webpack is just another npm module.
Task runners (optional reading for those who want to understand the ecosystem in which SystemJS might exist)
With SystemJS its sole responsibility is the lazy loading of files so something is still needed to minify those files, transpile those files (e.g. from SASS to CSS), etc. These jobs that must be done are known as tasks.
There are many other tasks which Webpack and gulp can perform which would be too numerous to cover here. I’ve provided an example 🙂