This isn’t a vote for it necessarily but as far as I know it’s main selling point was having a substantially smaller learning curve. I have no idea if that’s true however.
My personal experience with Rollup is that that is only true in very specific circumstances, mostly around node rather than web JS packaging, but I’m open to others’ mileages varying.
1 Like
| Feature | webpack/webpack | node-browserify | rollup/rollup |
|---|---|---|---|
| Additional chunks are loaded on demand | yes | no | no |
AMD define |
yes | deamdify | rollup-plugin-amd |
AMD require |
yes | no | no |
AMD require loads on demand |
yes | no | no |
CommonJS exports |
yes | yes | commonjs-plugin |
CommonJS require |
yes | yes | commonjs-plugin |
CommonJS require.resolve |
yes | no | no |
Concat in require require("./fi" + "le") |
yes | no | no |
| Debugging support | SourceUrl, SourceMaps | SourceMaps | SourceUrl, SourceMaps |
| Dependencies | 19MB / 127 packages | 1.2MB / 1 package | ?MB / 3 packages |
ES2015 import/export |
yes (webpack 2) | no | yes |
Expressions in require (guided) require("./templates/" + template) |
yes (all files matching included) | no | no |
Expressions in require (free) require(moduleName) |
with manual configuration | no | no |
| Generate a single bundle | yes | yes | yes |
Indirect require var r = require; r("./file") |
yes | no | no |
| Load each file separate | no | no | no |
| Mangle path names | yes | partial | not required (path names are not included in the bundle) |
| Minimizing | Terser | uglifyify | uglify-plugin |
| Multi pages build with common bundle | with manual configuration | with manual configuration | no |
| Multiple bundles | yes | with manual configuration | no |
Node.js built-in libs require("path") |
yes | yes | node-resolve-plugin |
| Other Node.js stuff | process, __dir/filename, global | process, __dir/filename, global | global (commonjs-plugin) |
| Plugins | yes | yes | yes |
| Preprocessing | loaders, transforms | transforms | plugin transforms |
| Replacement for browser | web_modules, .web.js, package.json field, alias configuration option |
package.json field, alias option | no |
| Requirable files | file system | file system | file system or through plugins |
| Runtime overhead | 243B + 20B per module + 4B per dependency | 415B + 25B per module + (6B + 2X) per dependency | none for ES2015 modules (other formats may have) |
| Watch mode | yes | watchify | rollup-watch |
in production mode (opposite in development mode)
X is the length of the path string
Bundlephobia is nice for comparing packages.
1 Like
Let me be clearer: I don’t really care about a detailed comparison of tech specs when I examine the question of “why Rollup?” – I care about how will this affect the Rails developer experience. I haven’t seen any arguments to that effect, only lists of tech specs that are decontextualized from the user goal we’re theoretically trying to solve here. Remember that OP’s desire was to not care about JavaScript – copypastaing a bunch of someone else’s arguments from documentation does not appear to serve that goal to me.
2 Likes
No argument from me, this is directly from the Webpack site:
'Twas not you to whom I was replying. Webpack, browserify and rollup are all being compared in this thread.
The context was quoted in my post, here it is again:
You nailed it here where you point out that rollup is used more for node.js than the web. The point of that table was to illustrate that rollup is a “batteries not included” tool. I worry that moving to a node.js centric tool would only exacerbate the node.js ecosystem pain-points around webpacker. Is anyone currently working on a webpacker guide for https://guides.rubyonrails.org/? I feel that clarifying conventions would go a long way to fix some of the concerns in this thread.
That is true, but the vast majority of dependencies you linked are true devDependencies; only a handful of them are bundled with the source code.
Nonetheless, some people have shared the concern that webpack installs tons of node modules. Whether you share that concern or not, it’s clear that with rollup, even if some dependencies are bundled, it takes less much time and space to install your node_modules.
To be clear, I wasn’t and am still not suggesting rails should use rollup instead of webpack for its first-class integration. I think building webpacker made sense: webpack is the most popular tool, and it’s broader in scope than rollup. But I disagree with the comments about rollup being “batteries not included”. If you want to do all of the things webpack can do (like dealing with other assets), then sure, that’s not “included”, but that’s also kind of the point: Rollup is just focused on bundling javascript (specifically ES or commonjs modules) and it’s great at that. That’s why I brought it up in this thread. I also don’t agree with the idea that it’s mainly geared toward node; I use it exclusively to bundle code for the web.
1 Like
I touched on this in my first message, but in my experience, rollup can deduplicate code and eliminate unused code better than webpack, which results in smaller javascript bundles to ship to the end user.
webpack’s module loading code is more generic because webpack has such a broad scope, but unfortunately that means it can get in the way of fully optimized bundles. It’s possible that webpack may eventually not have to sacrifice optimization to support its features (so it could get “the best of both worlds”), but when it came down to shipping an optimized (mobile-centric) application, we had to go with the best option available to us, which was rollup. Also I can’t say I’m overly optimistic that webpack will get there very soon, based on the response I’ve seen to this issue:
In the end, like most choices in software, it’s all tradeoffs and every team will have different criteria specific to their application. But to give some numbers from one of our largest bundles, an uncompressed 199KB bundle from webpack was reduced to 164KB just by switching to rollup. I don’t have the gzipped numbers offhand; I know they were less given that gzip compresses away duplicated code, but the uncompressed file size still matters because that’s what the browser has to parse before it can begin executing.
Anyway, like I said in my last reply, I still think it makes the most sense for rails to build its first-class integration around webpack, but since you asked, I had to reply 
1 Like
While bootstrap isn’t vanilla it’s widely used and rather a pain to get working. It took me just about 3 hours to get it somewhat working (it’s still not working correctly) and frankly I’m just about to quit my short webpacker exploration due to that experience.
And I haven’t even tried to use the CSS side of things in webpacker, currently importing (via sprockets) in the likes of "…/…/…/node_modules/…/…/something.css`. Is that the way it’s intended to be used? CSS is in sprockets by default after all.
Maybe it’s bootstrap (or the use of it) but I guess we can agree that “prototyping with Rails and Bootstrap” is a common use case and it’s incredibly frustrating to get going and while I’m not that up2date on everything I’m doing this for over 15 years so I’m not even a “newbie”, can’t imagine how frustrating it must be for one.
2 Likes
I import my CSS like this in a file called application.scss.
@import "~toastr";
@import "~sweetalert2/src/sweetalert2.scss";
Then I import that into webpack with import "../stylesheets/application"
Some packages work by just importing the package name like toastr, others don’t like sweet alert 2, but still a whole lot better than the mess of …/'s
1 Like
@Fjan If you like Sprockets you might want to give condenser and condenser-rails a go. I think you’ll like it for what you are looking for.
I’ve been working on it over the years, it tries do use the same conventions you’re used to with Sprockets (not sprockets 4 though, I didn’t like the direction it was going), but gets rid of the directives since they are no longer needed.
To bundle the JavaScript Condenser uses rollup, so if you like rollup (@vascoosx @Thibaut_Barrere @jakeNiemiec @rmacklin) you might to try it as well.
@DHH if you open to proposals for future Sprockets would love some eyes on Condenser. It supports modules and npm modules too.
1 Like
This thread helped inform the work I’ve been doing on creating an in-browser ES6/ESM future for Rails with Hotwire. I agree that Webpack is a necessary evil for certain types of development (Vue, React, etc), but I also agree that apps that don’t want or need that shouldn’t have to wrestle with something this complex. The progress that’s happened in browser support for ES6/ESM over the last several years is finally giving us a new path. Will continue to explore what that means for Rails 7+.
12 Likes
I’d say we need a future without nodejs as a dependency for our rails apps.
The asset pipeline offers an integrated way of adding js dependencies from within gems.
So many things are nobrainers when one skips webpack. I like that the rails app for hotwire is shown with —skip-javascript as parameter 
1 Like
Like Bijan said, I also wish nodejs/webpack and yarn are no longer dependencies on Rails. I loved Rails without it for many years and I was happy to ignore that ecosystem entirely. I was both shocked and sad that Rails 6.0 made me go through those hoops.
2 Likes
I’m very late to this - but I have to disagree about ‘just works’ I spent many hours trying to add jQuery and Bootstrap to a rails project
there are a bunch of tutorials - many of which give a half-working experience.
(in my case, stuff worked in ujs and console, but not my included js. I didn’t even realise it was half broken until several days into using it)
I don’t know if it is plausible - but for me, what I would like to see would be a js equivalent of bundler
#yarnbundefile.rb
yarnbundle 'jquery' [optionally some version info]
yarnbundle 'bootstrap'
yarnbundle install … and magically it all works
at the moment, I think the process is
- yarn install
- google how to include in environment.js (it seems to be different for each library)
- require (or import?) in application.js
- (sometimes) require (or import?) in application.js
thanks
1 Like