Handling front-end assets in Ruby on Rails has historically been pretty complicated and overwhelming over the years. Today, I want to show you my current Asset Pipeline, why I chose to manage my front-end dependencies this way and how you can benefit from leveraging these tools.

My Asset Pipeline stack is the following: Bun, Propshaft, cssbundling-rails, and jsbundling-rails.

Why not importmaps?

You'll notice importmaps absent from this list, despite being a new default in Rails 7, and a significant simplification of the front-end bundling experience. Well, it turned out to be too limited. In my case, I had 2 issues: it wasn't immediately clear to me how to pin versions of libraries, and I couldn't use TailwindCSS plugins. The latter was, unfortunately a deal-breaker.

Call it instinct, but that was the sign of additional future headaches and I didn't look further into importmaps.

Bun

​Bun is pretty revolutionary. It's a complete independent Javascript runtime, as in it can replace a Node server, a JS test runner, but the interesting part for us is that it can also replace your previous JS package bundler of choice (npm, yarn, pnpm).

It's faster than either, and by far the best part about Bun is that, since it's its own runtime, it does not require having NodeJS installed. Not on your dev machine, not on your Docker images, not on your CI, nowhere.

Bun also runs the watch/recompile processes for CSS & JS assets, as we'll see below.

cssbundling-rails & jsbundling-rails

Both cssbundling-rails and jsbundling-rails are thin adapters between your front-end bundlers (in my case, postcss for css and Bun for js) and the Rails asset pipeline. Both gems do support multiple bundlers. In my case, Bun also replaces yarn as script runner for JS.

It should be noted that these "middle-of-the-road" solutions will work admirably for an application using the modern Hotwire approach, but may be limited for existing heavy Javascript frontends like React SPAs.

Propshaft

​Propshaft is the re-imagined, lighter and cleaner version of Sprockets, the heart of the Rails asset pipeline, that will become default in Rails 8. Explicitly letting modern bundlers (again, bun, seriously!) handle the complex transpiling stuff they were designed to do allows this new iteration to shed a bunch of complex code, and run faster.

Why does it work for me?

This stack sits right in the middle of the zero-runtime, zero config option, importmaps, and the webpacker behemoth. I know I will reach the limits of the former quickly, but I also know I will get lost in the configuration and optimization rabbit hole of the latter.

It also still requires very little setup, and does not interfere with the code in a way others do (i.e. replacing javascript_include_tag by something else), and is the closest to the "original" asset pipeline vision of the early 2010 (drop your asset it, we'll figure it out), with all the amenities of the last ~15 years of progress on the front-end side, but none of the bloat.

Just as Hotwire provides a limited number of sharp tools, so does the pipeline it runs with. I like that.

Interested?

If you want to give these options a try, start from the css/js-bundling repos. The documentation is very comprehensive, includes install generators for all major bundlers & migration steps from webpacker.

After working on projects where assets take 30 whole seconds to compile, with processes that balloon to multiple gigs of RAM. I cannot express enough how much of a pleasure this simple setup has made my front-end development experience.

And again: no NodeJS dependency. Huge.

Build well, build smart, but spend more time playing.

— Kevin