At FastRuby.io, we spend a lot of time upgrading Ruby and Rails applications. However, we do more than just that, we also pay attention to other areas of the application that can be improved. For example, we recently migrated a customer’s application from Sprockets to JS bundling with esbuild opens a new window .

In this article, I share my experience migrating from Sprockets opens a new window to JS Bundling opens a new window (JavaScript Bundling for Rails).

This is not a step-by-step guide, as each application has its own unique needs. Instead, I discuss the problems I encountered and the approach I took during the migration to JavaScript bundling.

A few months ago, we were working on a Rails 7 app using Webpack 5. One of the main problems we had was that making a small change in the Javascript took around 39 seconds to recompile. You can imagine how much productivity we lost just waiting, and honestly, I personally remember getting really distracted during that dead time, just sitting there.

At that point, Webpacker had been retired opens a new window , so we checked the official migration guide opens a new window and found several options: the first was jsbundling-rails opens a new window , the second was Shakapacker opens a new window , another was Importmaps opens a new window , and finally, we knew we had the option to try Vite opens a new window .

We finally went with Vite, which (as noted on GitHub) is named after the French word for “quick” (pronounced /vit/, like “veet”). Our reload time improved a lot, it dropped to just one second, which felt like magic. In this post, I’ll explain why we chose it, and also why we got such a huge speed improvement.

There have been a lot of changes over the years in asset management for Ruby on Rails applications. The main question, after all the madness, is… “What should I do if I need to upgrade my Rails application?”

In this article we will talk about the options we have for each version jump.

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.

We’ve come a long way as full-stack Rails engineers. We began with everything neatly bundled in one framework, handling both backend and frontend together. The asset pipeline, with Sprockets opens a new window , kept this ecosystem running smoothly for us. Then, as front-end complexity grew, we turned to Webpacker opens a new window to pick up where Sprockets left off.

Now, it’s time for the next step in our journey: moving from Webpacker to esbuild. In this post, we’ll explore how to make that transition and why it’s worth considering.

When we run tests, we don’t want to hit external services in most cases, so our tests don’t depend on external services and are more stable. We can use gems like VCR opens a new window or WebMock opens a new window to stub the requests that are done by the Rails application, but when the request is initiated by the JavaScript code… that’s a different story.

In modern apps, it’s common to enhance the user experience with JavaScript. Whether it’s just some JavaScript sprinkles here and there or a full JS-based frontend, this is as important as your Ruby code when it comes to the app’s correct functionality. In this article we’ll show how to measure the test code coverage for the JavaScript code when running system/integration tests along with the Ruby code coverage.

Back in 2011, Rails 3.1 introduced The Assets Pipeline opens a new window feature using the Sprockets gem opens a new window . This made it really easy to handle assets (images, fonts, JavaScript, CSS and more), solving many of the issues that developers had to face everyday.

In 2012, Webpack opens a new window was released solving the same issues in a different way and in time became the most used solution to handle assets. And since Rails 6, Webpack became the default solution to handle JavaScript assets using the Webpacker gem opens a new window on new Rails applications.

In this article I’ll explain the steps we took to migrate to Webpack to handle our JavaScript assets, and how we added support as a node module in our styleguide opens a new window .