The Rails View, Revisited

When Bruce Williams and I wrote The Rails View for Pragmatic in 2012, the view layer felt like a junk drawer. ERB templates, helpers stuffed into modules nobody owned, partials nesting four levels deep, an asset pipeline that promised order and mostly delivered Sass. The book tried to give that drawer some shelves: clean helpers, smart partials, presenters and decorators, careful caching, mobile considerations, and conventions teams could actually agree on.

Twelve years on, the drawer doesn’t exist anymore.

What replaced it is a real layer — closer to a frontend in its own right, but still recognizably Rails. Hotwire collapsed the SPA tax. ViewComponent and Phlex gave us actual components, with tests and previews. Importmap-rails and Propshaft retired Sprockets. Strict locals turned partials into something with a contract. Tailwind ate global stylesheets. Action Text gave us rich content without writing an editor. Solid Cache made fragment caching cheap again. The asset pipeline — the source of half of the book’s chapter on JavaScript — is functionally gone.

This isn’t a lookback. The book holds up well in places (decorators, internationalization, the discipline of small partials) and badly in others (every word about Sprockets). What’s interesting now isn’t auditing what aged; it’s that the premises under view code have shifted.

Three premises, in particular:

The view is a component, not a template. A partial used to be a chunk of markup with implicit access to whatever the controller dropped into @variables. A ViewComponent (or a Phlex class, or a Tailwind-driven helper) is a typed, testable, previewable unit. The mental model isn’t “render this file” — it’s “instantiate this thing.” That changes how we organize, name, and test view code, and pulls a lot of what used to live in helpers up into actual classes.

The page is interactive by default. Turbo Drive and Turbo Frames make every link a partial reload, every form a streamable response, every list updateable in place. We used to add JavaScript when something needed to feel alive. Now we opt out of liveness when something genuinely shouldn’t change. That’s a different default, and it changes which decisions even matter (forms, broadcasts, optimistic UI) and which ones evaporate (most jQuery-era patterns).

The asset pipeline isn’t a problem to solve. Importmap-rails is a deliberate refusal of the bundler-industrial-complex. Propshaft is a static file server that doesn’t apologize. Tailwind compiles in milliseconds. The 2012 book devoted real estate to “should we use Sprockets manifests or…” — that real estate is now free. We can spend it on questions the original book couldn’t ask: server-driven UI, streaming, accessibility, performance budgets at the component level.

So: this is the kickoff. Over the coming months I’ll walk back through the book chapter by chapter, but pointed forward — not “what we got right” but “what we should now be doing instead.” Some of it will rhyme with the original (decorators are still good; semantic HTML is still good; tests for views are still mandatory). Most of it won’t. We’ll cover ViewComponent and Phlex side by side, Hotwire as the assumed substrate, modern caching with Solid Cache, accessibility as a first-class concern, AI-assisted view authoring (which I have opinions about), and the question quietly underneath all of it: what is a Rails view, in 2026?

Bruce and I never planned a second edition. The form was wrong; books move too slowly for a layer changing this fast. Blog posts can move at the speed the layer actually moves.

Let’s see where it goes.