Actually Webpack and Rollup go hand-in-hand. Rollup just compiles JavaScript ES6 modules into a single file, dealing with only `import` and `export` statements and some tree-shaking. Webpack handles everything else, like ES6-to-ES5 conversion, bundling dependencies, styles and everything else you need to get your code shippable to browsers and node.

>Actually Webpack and Rollup go hand-in-hand. Rollup just compiles JavaScript ES6 modules into a single file

Isn't that webpacks gig. Or what that gulp? Or was that browserify? Or was that Jello? Or was that...

Doesn't seem so terrible to me for people to have a choice in what tool they use.

You seem to be complaining that innovation is happening.

If you don't want to deal with the inevitable 'options' that are going to be offered up by a community as large as the JS community, you could 1. pick a smaller community, 2. stick to old tech (e.g. at our company we still have an app running on RequireJS that runs just fine -- RequireJS is over 6 years old). 3. calmly re-assess tech choices every year or so.

>You seem to be complaining that innovation is happening.

Not at all. I'm complaining that all of these seemingly similar tools keep superseding each other and solve...what exactly.

Why do you think competitiveness of tooling is a bad thing? I understand why it could feel overwhelming, but you really can just pick one (assuming it appears to do what you want) and if it does, stick with it.

The only benefit Rollup brings over Webpack is tree-shaking, which will be in Webpack 2.0.

That's not true. Even without tree-shaking, Rollup produces bundles that are smaller and faster to execute than the equivalent Webpack bundle, because Webpack needs to inline a module loader whereas Rollup moves all the code into the same scope. They're fundamentally different designs.

I don't know about that. Searching around for conversations surrounding `gulp vs webpack`, people seem generally unconvinced that they can replace gulp with just webpack.

You can run arbitrary tasks in Gulp. The most common task is build. But that build task is chained together via scripting and plugins.

Webpack only deals with the build. But instead of script, it aims for a more declarative API with config files.

So Webpack only covers the build part of Gulp. Which leaves all of the other scripting capabilities of Gulp. However, a major opinion now is to just write vanilla JS scripts and call them via npm commands and hooks. Gulp has strange api, is callback heavy, and everything needs a Gulp plugin to work. Plain javascript scripts can be closer to normal javascript, and npm can use the tool's CLI directly.