The History of the Asset Pipeline

Over the years, Rails has been changing the default way to handle assets while also adding different alternative options at the same time.

At first there were static files, then Sprockets appeared, then we had a choice between Webpacker and Sprockets for a few years, now Webpacker is gone and importmaps are the default. But jsbundling-rails and cssbundling-rails are also official options.

Sound confusing? In this article we’ll try to explain the history of all these changes.

I would like to clarify that this is a compilation of my understanding on this topic as an engineer. I am not connected with Rails’ core team. Some things might not be 100% accurate since I wasn’t present for the discussions leading to each decision over the years.

Static Files

Before Rails 3.1, Rails did not provide any kind of assets management. JavaScript, CSS, image files and others were placed in the public folder and served directly from there. You can see an example of this in a brand new Rails 3.0 app opens a new window .

Sprockets

In 2011, Rails 3.1 was released introducing a new feature called the Asset Pipeline opens a new window using the Sprockets gem opens a new window (an asset management solution to allow asset preprocessing and compilation).

This solved a big problem: frontend code on applications was getting more and more complex, new tools appeared, and the need to generate assets affected all web frameworks. This also made it easier to include assets from Rails Engines in applications and allowed Rails to use the CoffeeScript language internally.

Webpacker

In parallel, other solutions for the same problem started appearing in other languages and communities. One of them was Webpack opens a new window , released a few years later in 2014.

The different solutions for compiling and bundling assets evolved, and it was clear that Webpack was the most popular and complete one, largely because of the adoption by the JavaScript community.

Sprockets was lagging behind in terms of features and, support for the new ECMAScript standards. Eventually, Sprockets was updated to support using assets from the node_modules folder and some ES6 features, and Node was added as a dependency to the projects. Even after that, it still lacked support for many modern features and JavaScript libraries.

At some point it became clear that Sprockets was not going to match Webpack opens a new window when working with JavaScript files. In 2017, Rails 5.1 was released with optional Webpack support opens a new window using the Webpacker gem opens a new window , and Rails 6.0 made it the default for JavaScript assets opens a new window .

It’s important to note that, even though Rails 6.0 set Webpacker as the default for JavaScript assets, the application still used Sprockets to manage all the other asset types, and it’s still a valid option to manage the JavaScript assets if needed.

The use of Webpacker was not that well received, Webpack was more complicated to set up compared to Sprockets and it fundamentally changed how JavaScript files are connected with each other and how bundles are generated.

Adding to that, it uses an app/javascript folder outside of the app/assets folder. This was so Sprockets and Webpacker files wouldn’t get mixed up, but it was a move out of the previous conventions.

The migration opens a new window required many specific changes and patterns the community was not used to doing.

importamps, jsbundling-rails, cssbundling-rails

In 2021, the new 7.0 major version of Rails was released. It included many changes related to assets management: importmaps is the new default opens a new window method of handling JS assets, Webpacker is not the default anymore and was retired opens a new window , and new rails new options and rake tasks were added to support more tools to cover other needs:

• It allows you to use Webpack, esbuild, or rollup.js through the jsbundling-rails gem opens a new window .
• It allows you to use PostCSS, Dard-Sass, Tailwind, and more through the cssbundling-rails gem opens a new window .

Shakapacker

The retirement of the Webpacker gem also created a problem for applications using it: they’ll have to migrate to a maintained tool to not run into technical debt in the future. A fork of Webpacker called Shakapacker opens a new window was created and it’s currently under active development.

All of these options also state that they support Rails 6, not just Rails 7.

Summarizing

If you are in Rails 6 or 7, you currently have a lot of options to handle the assets; you can even combine them. This can be confusing for new developers learning the framework or for experienced ones doing upgrades.

These are the options:

• Sprockets still works on Rails 7 (it’s not a Rails dependency anymore but it’s included in the Gemfile for new apps)
• Webpacker, while retired, still works on Rails 7
• Shakapacker, replacement of Webpacker ensures future compatibility
• importamps-rails, default in Rails 7 if no --javascript option is used
• jsbundling-rails, when using the --javascript flag in Rails 7
• cssbundling-rails, when using the --css flag in Rails 7

Conclusion

The Asset Pipeline changed a lot over the years by necessity, for Rails to be able to support all the modern web needs. It’s also important to understand that even the oldest methods of handling assets (like plain static assets in /public, or good-old Sprockets) are still valid in Rails 7 if those are enough for your needs.

Moving to whatever is the new default in a new Rails application is not mandatory. You can skip the complexity of migrating if it won’t add any value to your app or you don’t want/need the new features.

However, each option has its pros and cons, so it’s useful to know what’s available and what the differences are to make an informed decision.

If you are having trouble upgrading Rails or your asset manager and need help please feel free to contact our team of experts opens a new window .

We have a new service! The Ruby on Rails Security Audit opens a new window ; let us help you fortify your Rails application with a comprehensive security audit.