The Front-end is Omakase
Cameron Dutro • Philadelphia, PA • Talk

Date: July 10, 2025
Published: not published
Announced: unknown

"Rails is omakase." DHH's classic 2012 blog post is still great reading in 2025. Here's a quote from the article that sums up his main point:

"A team of chefs picked out the ingredients, designed the APIs, and arranged the order of consumption on your behalf according to their idea of what would make for a tasty full-stack framework."

Right! And we have all benefitted enormously from the Rails core team sharing those tastes with the rest of us. The ingredients and API design decisions he's referring to fit the shape of a great deal of the web applications we might want to build. Just as we trust the omakase chef to serve a great unagi and sake pairing, we lean on the years of industry experience baked into Rails to build web applications with fewer resources.

If Rails and the Rails philosophy are omakase, the front-end world is the opposite: "okonomi," meaning "choosing what to order." Rather than picking a set of technologies, smart defaults, and conventions on your behalf, most front-end frameworks and tools expect the developer to cobble together a bunch of tools that were not necessarily designed to work with one another. The decision points are endless: Typescript or Javascript? Vite, webpack, or importmaps? SASS or Less? PostCSS or dart-sass? Tailwind, Bootstrap, or Bulma? BEM, SMACSS, OOCSS, CUBE, or HECS? Maybe CSS modules? And what about React, Vue, Angular, Svelte, or HTMX? The list goes on and on.

For understandable reasons, Rails has gradually retracted its opinions around front-end development over the last 10 years. In practice this has meant the Rails front-end is much less omakase and much more okonomi than the rest of the framework. Need a Javascript bundler? Bring your own. Want to use Typescript? Configure it yourself. While at first glance the high degree of flexibility might seem freeing, it's quite contrary to how Rails was originally designed. As Leonardo Da Vinci said, "Art lives from constraints and dies from freedom." The constraints Rails places on its developers are, somewhat counterintuitively, the same things that make it such a productive framework.

In my opinion, Rails needs an omakase front-end. We need a set of strong front-end opinions like we have on the back-end.

During my talk, I'd like to share my opinions for configuring the front-end of a Rails application, and provide a look at the libraries, configurations, and tools I've found to be the most productive. The talk will include a brief history of front-end tooling in Rails, what we've learned along the way, and what a more opinionated future could look like. I'll introduce a Rails generator I'm working on that configures a fully-baked and opinionated front-end setup - like Jumpstart or Bullet Train, but specifically for the front-end. I'd like to finish up by touching on future innovations like rendering ViewComponents in the browser.

So, why am I qualified to give this talk? I work on an open-source design system for a large company that runs a number of complex Rails apps. I've been around for most of the big front-end shifts in Rails, including the introduction of the asset pipeline, CoffeeScript, webpacker, and now js/cssbundling, importmaps, and ViewComponent. I've written code using all of these tools, and now my design systems work is giving me an even broader look at the front-end ecosystem. I recently re-wrote the documentation for getting started with our gems and Javascript packages, including a guide for adding it to a Rails app. I wanted to be thorough, so I covered configuring every tool supported by cssbundling-rails and jsbundling-rails, as well as Sprockets, vite, and importmaps. It was... a lot. Imagine how overwhelming all these choices must be for a beginner coming to Rails for the first time. Hell, I barely have a handle them, and I've been in the industry for 15 years.

RailsConf 2025