New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Yet another module bundler #219

Closed
Sinewyk opened this Issue Oct 24, 2015 · 9 comments

Comments

Projects
None yet
6 participants
@Sinewyk

Sinewyk commented Oct 24, 2015

Any reason why the concept (not importing everything from es6 modules) could not be done as a browserify transform/webpack loader ?

@Victorystick

This comment has been minimized.

Member

Victorystick commented Oct 24, 2015

Importing ES6 code can indeed be done using a browserify transform or a webpack loader; such tools already exist. However, the result will not be as efficient as the Rollup equivalent due to how those tools bundle the modules.

@Sinewyk

This comment has been minimized.

Sinewyk commented Oct 24, 2015

That's my point. Wouldn't it have been more efficient to dig in those codebases to implement the roll up concept code rather than trying to re-do already everything else that has already been done ?

Did you approach the browserify/webpack people to try to implement it ?

@Rich-Harris

This comment has been minimized.

Contributor

Rich-Harris commented Oct 24, 2015

@Sinewyk it's a fair question, and one that we've been asked a few times, so I'll try and answer as thoroughly as possible so that this can serve as a reference.

Forget about the tree-shaking for a moment. Webpack and Browserify have their differences, but fundamentally they work off the same basic concept: wrap each module in a function, then wrap all those functions in a bundle that includes a module loader (Browserify's prelude.js or Webpack's __webpack_require__).

Rollup, by contrast, works similarly to es6-module-transpiler and Esperanto (both now deprecated in favour of Rollup). Rather than wrapping each module in its own function, all modules share a single scope. That makes ES6 module features like bindings and cycles trivial to implement; it also means that you're not paying the per-module cost of wrapping and continually re-declaring imports. The end result is far more compact, even in situations where tree-shaking wouldn't help because all the code is being used. (Here is Redux built with Webpack, here it is built with Rollup – minified and gzipped, the Rollup version is 14.5% smaller.)

Could you do that in Browserify and Webpack? I don't know, but my hunch is that it would be rather difficult – you're basically talking about a fundamental rethink of how they work. When I started writing Rollup, it was an experiment that I wasn't certain would succeed. It would have been rather bold of us to approach the maintainers of those tools to ask whether they'd consider tearing up their designs based on a hunch, so we chose instead to build a new, simple tool, focused on ES6 modules from the ground up (rather than being CommonJS-centric and supporting ES6 modules via transforms).

Webpack 2 will support tree-shaking

See here for the details. This is really fantastic news – Webpack has a large user base, and those users now have a powerful incentive to start using ES6 modules. Developments like this are significant in terms of moving the JS community away from legacy module formats, and I'm thrilled about it.

But the idea is still basically the same – wrap modules, supply a module loader. Compare this example of Webpack 2 with the equivalent Rollup example.

When should you use Webpack?

Webpack really shines if you're developing a complex application. I don't personally use it, because I'm not particularly keen on the way it encourages Webpack-specific idioms (such as overloading require() to sometimes mean 'load this module', sometimes mean 'have these side-effects', and sometimes mean 'generate this URL'), but that's just me – a huge number of developers are in love with it, and we've seen some incredibly cool stuff (such as hot module replacement) come from the Webpack camp. I'm glad that it exists.

It makes less sense if you're developing a library. The idea that a library should include a module loader (i.e. __webpack_require__) just so it can load its own modules is, if you think about it, rather bizarre. But that's not Webpack's fault – developers flocked to it in the absence of an alternative. Rollup aims to be one such alternative. (I say 'one such' and not 'the' because the great thing about standards is that annoying details such as which module bundler you use fade into the background – we can stop writing Browserify code and Webpack code and RequireJS code, and just write JavaScript.)


I hope this goes some way towards explaining why this exists as a separate project. It doesn't exist as a criticism of Browserify (which I still use, occasionally) or Webpack, it exists because ES6 modules encourage a completely different approach to module bundling.

I'll close this issue, but happy to continue the discussion if necessary.

@Sinewyk

This comment has been minimized.

Sinewyk commented Oct 24, 2015

Thanks for detailed explanations. I only hope in the future we can merge some of these tools to avoid fragmenting even more the community.

I'll continue using webpack for applications (dev-server, code splitting), but I'll probably keep rollup in mind for libraries or simple applications where I don't need code splitting and can make due livereload stuff in another way.

nb: I'm only sligthly aware of webpack behavior for module bundling, I'm not proficient in saying how difficult it would be to merge both systems. Sorry if I was a condescending.

@Rich-Harris

This comment has been minimized.

Contributor

Rich-Harris commented Oct 24, 2015

nb: I'm only sligthly aware of webpack behavior for module bundling, I'm not proficient in saying how difficult it would be to merge both systems. Sorry if I was a condescending.

Not at all! It's a totally legitimate question that lots of people have asked 🍻

@sokra

This comment has been minimized.

sokra commented Oct 25, 2015

it exists because ES6 modules encourage a completely different approach to module bundling.

It's a pretty valid reason. A static module syntax (ES6) allows a wide range to advanced optimizations (see rollup), which would be difficult to integrate in a module bundler which allows mixing of ES6, CommonJS and AMD.

@Rich-Harris

This comment has been minimized.

Contributor

Rich-Harris commented Oct 26, 2015

Thanks @sokra – awesome to see you here. (And thanks for source-map-visualization, I use it a lot, and the other day I suddenly realised 'hey, this was made by the Webpack guy!')

@FezVrasta

This comment has been minimized.

FezVrasta commented Aug 20, 2016

@Rich-Harris thanks for the awesome post, would you care to elaborate this sentence?

it encourages Webpack-specific idioms (such as overloading require() to sometimes mean 'load this module', sometimes mean 'have these side-effects', and sometimes mean 'generate this URL')

I'm studying the downsides of import vs require in WebPack and yours seem like good points.

@Shyam-Chen

This comment has been minimized.

Shyam-Chen commented Nov 2, 2016

Rollup writes less code than Webpack 2. (Easy to configure)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment