The infrastructure is the important piece, not the module syntax. Webpack provides this infrastructure, and it's easy to provide it for ES6 modules as well.
For example: how do I hot reload modules? How do I eval code inside a module? Webpack allows you to do all of this, and is more advanced than anything out there. SystemJS and jspm are nice but I still find webpack to support way more features.
What do you mean "hacked together"? Look at how small my config is! Do you know how much you get from that small config? The only thing hacky is the `node_modules` hack, and as far as I know, you'd have to do something similar with anything else (I don't see anyone using SystemJS/jspm on the backend).
Also, re-transpiling files that change? Just fire up the watcher (`webpack --watch`) and webpack automatically does this...
That's what makes SystemJS appealing; the infrastructure is the ES6 (now WhatWG) Loader Specification; a spec that browsers will be implementing. So you don't have to worry about learning yet-another-module-loader like you do when jumping from requirejs -> browserify -> webpack -> whatever's next trends.
For hot module replacement, sure, it gets a little more complex. You add another plugin and another entry point, that's all.
I disagree that build systems need to be complex. They get complex because people try to invent too many different ways of doing things instead of working towards standards. webpack is a prime example of that.
I'd love to see a full demo seed example of your ideal build system. Something that includes hot code swapping and even more importantly, unit testing.
Yes, build systems are complex, because people need features, even if you personally don't need them. Webpack doesn't offer many ways to do the same thing; it just simply has a lot of features. Whenever we get enough tooling around ES6 modules to match it (or come close), I'll gladly switch.
You'll see a fuller example later. I'd love to see a matching set up using systemjs/jspm. You could convince me to switch.
Webpack solves a LOT of problems with application development. Handling assets properly is very difficult, and webpack makes it straightforward.
Build systems are complicated, I'd love to see something that handles the same problems as webpack but somehow manages to avoid the required configuration.
Wouldn't using something like Babel remove that issue?
The problem is supporting dependencies. You need something that can load everything, which is the functionality that SystemJS provides.
posted March 16, 2015.
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