3 ms·

The syntax for specifying dependencies is irrelevant -- webpack aims to support all of them, and as far as I know has experimental ES6 import/export support. I'

The syntax for specifying dependencies is irrelevant -- webpack aims to support all of them, and as far as I know has experimental ES6 import/export support. I'm definitely going to transition to ES6 modules soon. 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...

Touche 12y ago
> The infrastructure is the important piece, not the module syntax. 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.
latchkey 12y ago
I know your blog post is only part 1, but your example doesn't show hot module reloading. Adding that will complicate your build file even more.
- jlongster 12y ago
  I don't know what you are complaining about. Build systems are complex. These config files are relatively straight-forward. You tell it where to start, where to output, to use sourcemaps, and give it a few plugins. It can't get much simpler. For hot module replacement, sure, it gets a little more complex. You add another plugin and another entry point, that's all.
  - latchkey 12y ago
    You're sounding really defensive. I find it entertaining that in one sentence you say 'Build systems are complex' and in another 'It can't get much simpler.' 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.
    - TheAceOfHearts 12y ago
      I'm currently setting up something similar to this. It's an app that does server-side rendering. It has the server-side code, the shared rendering code, and the client-side code. 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.
    - jlongster 12y ago
      I don't feel defensive, honestly build systems are boring to me so I'm not that passionate about it. What I meant was that its simple relative to what it could be. 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.

Touche 12y ago

> The infrastructure is the important piece, not the module syntax. 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.

latchkey 12y ago

I know your blog post is only part 1, but your example doesn't show hot module reloading. Adding that will complicate your build file even more.

jlongster 12y ago
I don't know what you are complaining about. Build systems are complex. These config files are relatively straight-forward. You tell it where to start, where to output, to use sourcemaps, and give it a few plugins. It can't get much simpler. For hot module replacement, sure, it gets a little more complex. You add another plugin and another entry point, that's all.
- latchkey 12y ago
  You're sounding really defensive. I find it entertaining that in one sentence you say 'Build systems are complex' and in another 'It can't get much simpler.' 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.
  - TheAceOfHearts 12y ago
    I'm currently setting up something similar to this. It's an app that does server-side rendering. It has the server-side code, the shared rendering code, and the client-side code. 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.
  - jlongster 12y ago
    I don't feel defensive, honestly build systems are boring to me so I'm not that passionate about it. What I meant was that its simple relative to what it could be. 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.