I'm creating my first Angular application and I would figure out what is the role of the module loaders.
Why we need them?
I tried to search and search on Google and I can't understand why we need to install one of them to run our application?
Couldn't it be enough to just use import to load stuff from node modules?
I have followed this tutorial (that uses SystemJS) and it makes me to use systemjs.config.js file:
/**
* System configuration for Angular samples
* Adjust as necessary for your application needs.
*/
(function(global) {
// map tells the System loader where to look for things
var map = {
'app': 'transpiled', // 'dist',
'@angular': 'node_modules/@angular',
'angular2-in-memory-web-api': 'node_modules/angular2-in-memory-web-api',
'rxjs': 'node_modules/rxjs'
};
// packages tells the System loader how to load when no filename and/or no extension
var packages = {
'app': { main: 'main.js', defaultExtension: 'js' },
'rxjs': { defaultExtension: 'js' },
'angular2-in-memory-web-api': { main: 'index.js', defaultExtension: 'js' },
};
var ngPackageNames = [
'common',
'compiler',
'core',
'forms',
'http',
'platform-browser',
'platform-browser-dynamic',
'router',
'router-deprecated',
'upgrade',
];
// Individual files (~300 requests):
function packIndex(pkgName) {
packages['@angular/'+pkgName] = { main: 'index.js', defaultExtension: 'js' };
}
// Bundled (~40 requests):
function packUmd(pkgName) {
packages['@angular/'+pkgName] = { main: '/bundles/' + pkgName + '.umd.js', defaultExtension: 'js' };
}
// Most environments should use UMD; some (Karma) need the individual index files
var setPackageConfig = System.packageWithIndex ? packIndex : packUmd;
// Add package entries for angular packages
ngPackageNames.forEach(setPackageConfig);
var config = {
map: map,
packages: packages
};
System.config(config);
})(this);
Why we need this configuration file?
Why we need SystemJS (or WebPack or others)?
Finally, in your opinion what is the better?
If you go to the SystemJS Github page, you will see the description of the tool:
Universal dynamic module loader - loads ES6 modules, AMD, CommonJS and global scripts in the browser and NodeJS.
Because you use modules in TypeScript or ES6, you need a module loader. In the case of SystemJS, the systemjs.config.js allows us to configure the way in which module names are matched with their corresponding files.
This configuration file (and SystemJS) is necessary if you explicitly use it to import the main module of your application:
<script>
System.import('app').catch(function(err){ console.error(err); });
</script>
When using TypeScript, and configuring the compiler to the commonjs module, the compiler creates code that is no longer based on SystemJS. In this example, the typescript compiler config file would appear like this:
{
"compilerOptions": {
"target": "es5",
"module": "commonjs", // <------
"moduleResolution": "node",
"sourceMap": true,
"emitDecoratorMetadata": true,
"experimentalDecorators": true,
"removeComments": false,
"noImplicitAny": false
}
}
Webpack is a flexible module bundler. This means that it goes further and doesn't only handle modules but also provides a way to package your application (concat files, uglify files, ...). It also provides a dev server with load reload for development
SystemJS and Webpack are different but with SystemJS, you still have work to do (with Gulp or SystemJS builder for example) to package your Angular2 application for production.
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.
SystemJS code:
// 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()
});
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.
Webpack, when configured, correctly does this for you (and bundles the output together). If you want to do something similar with SystemJS you would typically use a JavaScript task runner. The most popular task runner is another npm module called gulp.
So, for example, SystemJS might lazy load a minified JavaScript file that has been minified by gulp. Gulp, when setup correctly, can minify files on the fly and live reload. Live reloading is the automatic detection of a code change and an automatic browser refresh to update. Great during development. With CSS, live streaming is possible (i.e. you see the page update the new styles without the page even reloading).
There are many other tasks which Webpack and gulp can perform which would be too numerous to cover here. I've provided an example :)
So far I was using systemjs. It was loading files one by one and first load was taking 3-4 seconds without minified files. After switching to webpack I got a great performance improvement. Now it takes only to load one bundle file (also polyfills and and vendor libs which almost never changed and almost always cached) and that's it. Now it takes just a second to load the client side app. No additional client side logic. As less the number of individual files loaded as higher the performance. When using systemjs you should think about importing modules dynamically to save in performance. With webpack you focus mainly on your logic because performance will be still be good once the bundle is minified and cached in you browser.
