Rails 7: The End of Webpacker?

Rails 7: The End of Webpacker?

DHH recently announced that Rails 7 will not use Webpacker by default. This is a big departure that every Rails developer should have on their radar.

The main takeaways from this video (and the corresponding blog post) are:

  • ES6 can be used natively now–no more transpiling!
  • HTTP2 removes the penalties for serving lots of small asset files instead of individual (large) concatenated and minified asset files
  • Import maps are supported by a few browsers and can be added to the rest with a small shim
  • These three technologies can be combined to obviate the JavaScript tool chain

The introduction of Webpacker in Rails 5 always bugged me. All the dependencies–Webpack, Yarn, Node–just to get your JavaScript files compiled and minified seemed like overkill and still does, not to mention the confusion of having two JS directories, app/assets/javascripts and app/javascript.

It didn’t feel very Rails-y, either. Rails is notorious for having opinions and enforcing them. The Webpacker approach to JavaScript felt opinion-less and bolted-on to help keep Rails relevant by making it easier to use popular JS frameworks like React. It lost the feeling of “convention over configuration” by providing multiple conventions and a fair bit of configuration.

The proposed tool chain-less approach to JS that DHH debuted in the video above feels just the opposite. It provides one path instead of many, removes a bunch of dependencies, and simplifies the process of adding JavaScript to your app. That feels much more Rails-y.

The big caveat, though, is that existing projects that are already mired in the current way of doing things will have a hard time converting to the new hotness and may have to stick with Webpacker. I’ll be interested to see if the Rails team develops some sort of migration path to help old apps leave Webpacker behind. For new projects or existing apps that are light on JS, though, using this ES6/HTTP2/import maps method should be pretty straight-forward.

I am very excited about this, and I wholeheartedly agree with DHH that “we’re way overdue [for] a correction back to simplicity for the frontend.”

Loved the article? Hated it? Didn’t even read it?

We’d love to hear from you.

Reach Out

Comments (2)

  1. I think the new direction is a much better default for Rails, especially the fact that you can skip the node dependency if you want to.

    For Rails apps that have a non-trivial amount of JS, it’s still a good idea to use a bundler, and if you are going to have a node dependency, you might as well get a good development experience out of it.

    Vite Rails should provide a nice migration path for apps are too complex to rely on import-maps. It’s also a good option for developers that want a better DX that doesn’t involve manually reloading the page on each change.

Leave a comment

Leave a Reply

Your email address will not be published. Required fields are marked *

More Insights

View All