It's a bit late to figure out, but I see caveats with dynamic imports in es-module-shims but not SystemJS.
The one thing that I really miss is that most (all?) JS module implementations really seem to be focused on static compile workflows. Sure, for deployments you want that, for development JS as a very dynamic language would offer much better support for live programming systems if the module systems would play along nicely. One reason why I personally was excited to see that the loader proposal initially considered custom locate/fetch/define behavior added via hooks but more recent discussions about bringing it forward seem to dismiss that. I think for great tooling a module system that supports both deployment as well as development needs is necessary and would really add to the JS ecosystem.
[1] https://github.com/systemjs/systemjs [2] https://github.com/whatwg/loader
Back when webpack first came out, I struggled a little bit with figuring out what it actually did. While I understand now, I am not why I would want to (or you) switch from JSPM to webpack. I don't see any features that webpack has that JSPM doesn't (and JSPM offered ES6 support well before of course, with babel on by default).
I like to use JSPM because of how relatively easy everything fits together -- and how straightforward it is to use and configure.
For those not familiar, JSPM is a package manager, module bundler, and module loader all in one for javascript applications.
This means you can:
jspm install
jspm bundle-sfx js/main dist/build.js
// set our baseURL reference path
System.config({
baseURL: '/app'
});
// loads /app/main.js
System.import('main.js');
As you may have guessed, JSPM relies on SystemJS (https://github.com/systemjs/systemjs) internally for some of the features above.
This video really opened my eyes to what it could do: https://www.youtube.com/watch?v=iukBMY4apvI
SystemJS is a polyfill (and extender post-polyfill) that is great with support for plugins, transpiling ES6, and format detection for CommonJS, AMD, and even "Global" modules: https://github.com/systemjs/systemjs
Also recommended, is JSPM (http://jspm.io) which is a package manager that utilizes the features of SystemJS and configures SystemJS to load NPM packages (akin to Browserify/Webpack) and Github repositories (somewhat similar to Bower).
It handles all the transpilation work for you (at runtime for development, or during a manual build/bundling for production) using either Babel, Traceur or Typescript, and allows you to seamlessly use ES6 everywhere in your code and even load third party code on Github and NPM as ES6 modules.
https://github.com/jspm/jspm-cli
https://github.com/systemjs/systemjs
EDIT: Some more info copied from another post:
SystemJS (jspm's module loader) has the following main advantages compared to competing module loaders:
- Able to load any type of module as any other type of module (global, CommonJS, AMD, ES6)
- Can handle transpilation and module loading at runtime without requiring a manual build step
However, jspm itself is primarily a package manager. Its main advantages over existing package management solutions include:
- Tight integration with the SystemJS module loader for ES6 usage
- Maintains a flat dependency hierarchy with deduplication
- Ability to override package.json configuration for any dependency
- Allows loading of packages from just about any source (local git repos, Github, NPM) as any module format
In 2015, we have ES6 modules now. Instead of define/require, we have import/export and it is standards based now, which is nice.
For systems that do not support ES6 syntax directly, this is provided today with tools like SystemJS [1] and jspm [2]. SystemJS is great because it supports all of the module formats for backwards compatibility. jspm is great because it doesn't matter where you grab your dependencies from (npm/github/bower/etc).
I agree with the authors comment about gulpfiles being hacky and not very DRY (don't repeat yourself). That said, his examples felt very hacked together as well, there is too much programming in there. Do I copy that build file across every new project I create?
gulpfiles are great because they provide extra functionality that is missing, like only re-transpiling files that change. For large projects this can really be a time saver. webpack has that by running a separate server process, complicated! Projects like gulp-helpers [3] try to bring a tiny bit of sanity and re-usability to gulpfiles by making things a bit more DRY and configuration based. It is just an example of one way to do things, but hopefully you see my point.
[1] https://github.com/systemjs/systemjs [2] http://jspm.io/ [3] https://github.com/lookfirst/gulp-helpers