For getting Bootstrap to work with Rails 8, you need to choose between Propshaft, JSBundling/CSSBundling, Shakapacker, or Vite Rails as your asset pipeline or JavaScript paradigm. (Note: Propshaft is the new default asset pipeline, not a “packager.” The other three options are packagers that handle bundling and transpiling.)
One sentence for anyone upgrading: Sprockets is gone as the Rails 8 default and Propshaft replaces it, while importmap-rails still ships but no longer leads this guide.
Propshaft
PROS: • The default asset pipeline in Rails 8. • Simple, minimal, and fast. It digests and serves browser-ready assets. • Works out of the box with importmap-rails, so you can add importable JS with no build step. • Strong with HTTP/2, since splitting files can beat bundling them.
CONS: • Does not bundle, transpile, or minify. • No TypeScript or JSX compilation. You need a bundler or Vite for that. • Only serves JS that is already browser-ready (ES Modules).
JSBundling
PROS: • Can use ESBuild, Webpack, or Rollup as the compiler. • Can use ESBuild, a faster alternative to Webpack. • A good, quick way to use node packages via npm or Yarn. • A good, quick way to get TypeScript or JSX compiling with Babel. • Drops compiled output into app/assets/builds, where Propshaft picks it up.
CONS: • Does not offer a complete solution for building assets inside React or React-on-Rails apps. • Too many node dependencies can make your app unwieldy.
Shakapacker
PROS: • Offers a complete deployment and development pipeline for TypeScript and React (including JSX). • Comes ready for server-side rendering with the react_on_rails gem.
CONS: • Uses Webpack, which can be slow to compile with many npm dependencies. • Too many node dependencies can make your app unwieldy.
Vite Rails
PROS: • An excellent development and deployment environment for modern JS: React, Vue, Solid JS, and more. • Fast dev server with hot module replacement. • Great for Rails-API apps. • Strong for a blended Rails-React app that keeps some Turbo and Stimulus alongside React components.
CONS: • Too many node dependencies can make your app unwieldy.
Once you decide, the fastest way to get started with a new Rails 8 app is to use my Rails Quick Scripts. They are easy to use and get you up and running right away, leaving you with excellent sane defaults and instantaneous basic configuration.
MY PICK: VITE RAILS OVER SHAKAPACKER
These days I prefer Vite Rails over Shakapacker for new work. Here is the difference.
Shakapacker is the maintained fork of Webpacker. It is Webpack under the hood. That means heavier config, slower builds as your dependency tree grows, and a tight integration path with react_on_rails for SSR. It is still a solid choice if you are committed to that stack.
Vite Rails uses Vite. Vite runs on ESBuild for development and Rollup for production builds. The dev server is fast, hot module replacement is instant, and the config stays small. For React, Vue, or Solid on top of Rails, Vite Rails is what I reach for first.
If you already have a Webpack and react_on_rails setup that works, Shakapacker is fine. For greenfield front-end work, I go with Vite Rails.
INTERTIA
Where does Inertia fit? Inertia is not a fifth choice here, because it is not a packager. It is an architecture that runs on top of a bundler, almost always Vite. You still pick one of the options above to compile your assets, then Inertia hands React, Vue, or Svelte components their props straight from your Rails controllers with no API layer.
RAILS VS REACT VS OTHER PARADIGMS IN 2026
The default has shifted. For most of the last decade the standard stack was a backend API plus a React SPA. That was the architecture bootcamps taught and recruiters asked for. In 2026 it is no longer the obvious choice for every app.
Rails 8 pushed hard in the other direction. Hotwire (Turbo and Stimulus) ships by default. Turbo Drive intercepts links and form submissions and swaps the body without a full reload, so a plain server-rendered Rails app feels fast. Solid Queue, Solid Cache, and Solid Cable removed external service dependencies. Propshaft and importmap-rails let you run with no build step at all. The whole release is a bet that you can build a modern app without a separate frontend.
The case for Rails and Hotwire
- You write one app in one language. No second codebase, no JWT handling, no CORS, no API versioning, no client-side router, no global state library.
- You ship far less JavaScript. A CRUD app in Hotwire sends a fraction of what an equivalent Next.js app sends, even with React Server Components trimming the client bundle.
- It is faster to build and cheaper to maintain for a solo dev or small team. This is the “one-person framework” pitch, and it holds up for CRUD-heavy products.
- Turbo Frames and Turbo Streams cover the dynamic parts of most apps.
The case for React or a full SPA
- Some apps need real client-side richness. You will not build Figma or Miro with Hotwire alone. Canvas-heavy, drag-heavy, offline-capable, or deeply stateful UIs still want React or something like it.
- The ecosystem is large and mature: TanStack Query, shadcn/ui, Framer Motion, and a deep hiring pool.
- React code can carry over to React Native for mobile, which lowers cost if you need a native app too.
- If your team is already strong in React and thin on Rails and Hotwire, that talent reality matters more than any benchmark.
The middle ground got better
The interesting movement in 2026 is not at the poles. It is in between.
- Islands architecture is now common. Use Hotwire for most pages and mount React only on the specific components that need it. Turbo Mount and similar tools make this clean.
- Inertia Rails matured a lot. It gives you React, Vue, or Svelte components with props passed straight from your Rails controllers. There is no API layer and no client-side fetching. It uses Rails sessions, so your existing auth works unchanged, and ERB pages can coexist while you convert one page at a time. It now has feature parity with the Laravel adapter, including Inertia 2.0 features. If you want real components without building and maintaining a separate API, this is the option to look at first.
- Inertia pairs naturally with Vite Rails, which is one more reason I reach for Vite on new front-end work.
How the build question maps to all this
There are really two axes, and it helps to separate them.
- Build or no build. Importmap and Propshaft give you a no-build path. Vite, JSBundling, and Shakapacker give you a build step with transpiling and bundling.
- Server HTML or client components. Hotwire is server-rendered HTML. React, Vue, and Solid are client components. Inertia sits in the middle by letting Rails drive client components without an API.
Pick your point on both axes based on the app, not the trend.
My read for 2026
- New CRUD app, small team: Rails 8 with Hotwire, Propshaft, and importmap. No build step. Ship it. (Check out my gem Hot Glue for building lightening fast CRUD pages with Turbo— it’s like Rails scaffolding on steroids).
- Mostly server-rendered with a few rich spots: Hotwire plus React islands through Turbo Mount or Inertia, built with Vite Rails.
- Component-heavy product where you still want Rails to own routing and data: Inertia Rails with React or Svelte on Vite. Skip the separate API.
- Genuinely SPA-class interactivity or a shared React Native codebase: a full React frontend on Vite Rails, or a separate frontend talking to a Rails API.
“Modern” no longer means “SPA.” In 2026 you have a real spectrum, and Rails 8 makes the simple end of it more viable than it has been in years.
COMMON QUESTIONS
Can I use Bootstrap or Tailwind with any paradigm?
Yes. Bootstrap or Tailwind will work with Propshaft, JSBundling, Shakapacker, or Vite Rails.
Can I use Turbo with any paradigm?
Yes. Turbo will work with Propshaft, JSBundling, Shakapacker, or Vite Rails.
Can I use Stimulus with any paradigm?
Yes. Stimulus will work with Propshaft, JSBundling, Shakapacker, or Vite Rails.
How much should I use the asset pipeline?
In Rails 8, Propshaft is the default asset pipeline. It replaces Sprockets. Propshaft loads your assets, stamps them with a digest for far-future caching, and serves them. It does not transpile or bundle, so anything that needs compiling goes through jsbundling-rails, cssbundling-rails, or Vite, which drop their output into a load path that Propshaft then digests and serves.
You still load CSS through the stylesheet_link_tag helper in your layout file. If you have a more React-style application tree with styles defined inline or in your JS code, you can use that paradigm instead when you are on Shakapacker or Vite Rails.
If you are upgrading an older app, see the Propshaft upgrade guide for moving off Sprockets.
Can I use React and TypeScript with any paradigm?
No. React and TypeScript will not work with importmap-rails or plain Propshaft, since neither transpiles. TypeScript can be added to a JSBundling app once you add the TypeScript watcher and reconfigure your Yarn script.
You can use React with JSBundling, but it requires some modification to support features like server-side rendering. For more about JSBundling and React, see this post.
To support SSR, Shakapacker comes ready to go, works in tandem with the react_on_rails gem, and is an ideal React and TypeScript environment on top of Ruby on Rails. Vite Rails is my preferred choice for React, Vue, Solid JS, or any Rails-API app where you want a JS paradigm to control the front end.
What if I have an API-only Rails app?
If you have an API-only Rails app, you have to decide whether to deploy React (or your other frontend framework) on top of Rails or separately from it. “On top of” means your React code lives inside your Rails app folder (in app/javascript/) and deploys along with your Rails app. This is generally the best strategy for React-Rails apps.
Alternatively, you can deploy your React app completely separately from your Rails app. That setup brings headaches around (1) timed deployments, (2) a lack of end-to-end testing options, and (3) getting the CORS settings right across two domains (the Rails domain and the React domain). Generally, a single Rails app with the JS frontend bundled within it is the best strategy.Share