JS Module Loaders
The Lineup
- RequireJS
- BrowserifyJS
-
WebPackJS(too late, it's old now) - SystemJS
The Problem
- Complex dependencies are difficult to maintain
- Browser code does not inherently mix with Node
- Some times, having lots of script tags is a problem
Require JS
= AMD
(Asynchronous Module Definition)
Require JS
This is what AMD looks like.
Require JS
The Good
- Lazy Loading allows for optimization
- 1 script tag
The Bad
- Many separate requests
- Lazy Loading may cause slow loading
- Must maintain config
- Enormous, unreadable syntax in every file
- Prefers AMD modules
Require JS
Browserify JS
= CommonJS
Browserify JS
This is what Common JS looks like.
Browserify JS
With Browserify, there's an extra step:
That will build the bundle that we reference in our html.
Browserify JS
A structure for Angular with Browserify
Browserify JS
This is how you configure your libs in package.json
The Good
- Bundling is good for performance
- 1 script tag
- Syntax is consistent with Node (CommonJS)
- Works with any type of module
The Bad
- Must maintain config but only for 3rd party libs
- Despite source maps, can introduce debug troubles
Browserify JS
System JS
System JS +
= ES6 Modules
System JS
In order to run this in the browser we need to include an ES6 runtime (Traceur or Babel) and the ES6 module loader shim.
System JS
Demo Time
ES6 Module import/export
System JS
Default
Named Exports
Or
Then
The Good
- Separate scripts for dev is good for debugging
- Bundling for production is good for performance
- Syntax is consistent with ES6
- Works with any type of module
The Bad
- Script tags have to be different for production and dev which complicates builds a bit
System JS
In case you're interested...
You can use Steal JS to help you create multiple bundles to get the benefits of both bundling AND lazy loading.