Migrating from Rails 6 to 8: How esbuild Helped Us Fix the JavaScript Bottleneck Rails Upgrade That Sparked a Bigger Change

When we started migrating our monolith from Rails 6 to Rails 8, we expected the usual suspects:

• Deprecations
• Gem updates
• Syntax tweaks
• Config changes

But what we didn’t expect was that the biggest win would come from rethinking how we build JavaScript.

What began as a routine framework upgrade turned into an opportunity to fix our sluggish JS pipeline — and esbuild turned out to be the hero.

The Bottleneck: JavaScript Slowing Everything Down

By the time we were on Rails 6, our JavaScript build system was showing its age:

• 🔥 Hot reloads weren’t hot anymore
• ⏳ Local changes took forever to reflect
• 🏗️ CI/CD pipelines crawled under bloated build scripts

We were still tied to the legacy asset pipeline and Webpacker. Even with tweaks and caching, builds were taking minutes instead of seconds.

During the Rails 8 upgrade, we had a choice: 👉 Keep patching Webpacker, or 👉 Rethink our pipeline entirely.

We chose the second option.

The Breakthrough: Discovering esbuild

Rails 8 introduced jsbundling-rails, with esbuild as the preferred bundler.

At first, we tried it just to evaluate performance. But once we saw the results, there was no turning back.

The Migration: From Webpacker to esbuild

Here’s how we transitioned:

bundle remove webpacker
bundle add jsbundling-rails
rails javascript:install:esbuild

We restructured our asset pipeline, rewired build scripts, and ditched legacy Webpack configs for a clean, blazing-fast setup.

Why esbuild?

Without esbuild, we were running into several issues:

• ⏳ Slow builds — Webpacker and the legacy pipeline were taking 2–3 minutes for small changes, killing developer momentum.
• 🔄 Hot reload delays — Instant feedback during development was almost impossible.
• ⚠️ Complex configs — Webpack required multiple loaders, custom rules, and environment-specific tweaks.
• 🏗️ Bloated CI/CD — CI/CD pipelines had to wait long minutes to build JS, delaying deployments.

esbuild solved these problems by:

• ⚡ Extremely fast builds even on large JS codebases.
• 🔁 Truly instant hot reloads.
• 🛠 Minimal configuration — no need for dozens of Webpack loaders or custom scripts.
• 🌐 Native ESM support, making modern JavaScript simpler to integrate.
• 📦 Lightweight — fewer dependencies, less maintenance overhead.

Our Detailed Minimal esbuild Setup

We kept things lean with a simple package.json configuration:

{
  "scripts": {
    "build": "esbuild app/javascript/application.js --bundle --sourcemap --format=esm --outdir=app/assets/builds",
    "watch": "esbuild app/javascript/application.js --bundle --sourcemap --format=esm --outdir=app/assets/builds --watch",
    "copy:assets": "cp -r app/assets/images/* public/images/"
  }
}

Notes and tips:

• --bundle combines all JS files into a single output, avoiding multiple requests.
• --sourcemap Keeps debugging easy in browsers.
• --format=esm allows modern ES modules, making code cleaner.
• --watch enables automatic rebuilds when files change.
• copy:assets ensures images and static files are available without a complex loader.

Steps We Took to Smooth the Transition

1. Remove legacy Webpacker — eliminated outdated Webpack configs.
2. Install jsbundling-rails — Rails 8 integrates esbuild natively.
3. Restructure JS folders — moved JS entry points to app/javascript/.
4. Refactor imports — switched from Webpacker helpers to direct JS imports.
5. Add watch scripts for development — hot reloads became truly instant.
6. Test thoroughly — ensured all JS functionality, including third-party libraries, worked seamlessly.

Result: Developers gained speed, simplicity, and joy, while builds became predictable, fast, and maintainable.

The Results: Speed, Simplicity, and Developer Joy

After switching, the improvements were immediate:

• ⚡ Build times dropped from 2–3 minutes ➝ under 5 seconds
• 🔄 Hot reloads became truly instant
• 🚀 CI/CD pipelines sped up, saving 10–15 minutes per deploy
• ❤️ Developers loved the reduced config and dependencies

Key takeaway: Performance is developer experience. By fixing the bottleneck, we gave joy and velocity back to our team.

Thinking of Upgrading? Here’s Our Advice

If you’re planning a Rails 8 upgrade, here’s what we learned:

• 🔧 Use it as a chance to rethink frontend tooling
• 🗑️ Say goodbye to Webpacker — it’s time
• ⚡ Don’t fear esbuild: it’s fast, lightweight, and Rails-ready
• 👯 Pair up during tricky parts — migration goes smoother together

Summary

What started as a routine Rails 6 → Rails 8 upgrade quickly turned into a full-blown performance overhaul. The biggest win wasn’t just deprecations or gem updates — it was fixing our sluggish JavaScript pipeline.

By ditching Webpacker and embracing esbuild through jsbundling-rails, we cut build times from minutes to seconds, made hot reloads instantaneous, and simplified our asset pipeline. The enhanced JS bundling setup, with watch scripts, ESM support, and minimal configuration, proved that small, smart changes can make a huge impact on developer productivity.

Conclusion: A Little Cleanup Goes a Long Way

Upgrading Rails isn’t just about keeping up with the framework — it’s about taking a hard look at the friction slowing your team down. Sometimes the bottlenecks aren’t in Ruby at all, but in your JavaScript build.

By rethinking the frontend pipeline, adding watch scripts, and embracing esbuild, we didn’t just speed up builds — we boosted developer joy, reduced stress, and gave our CI/CD pipelines a caffeine shot.

So, if you’re staring down a Rails upgrade and dreading the mess: embrace the chaos, rethink the obvious, and don’t be afraid to Marie Kondo your assets. Because sometimes, tidying up your JavaScript is exactly what your team needs to spark the bigger change.

LinkedIn — https://www.linkedin.com/in/dharmik-salakiya-771854159?