Why use a frontend framework with a backend language?

Every product conversation eventually lands on the same question: should the interface be rendered by the backend, or built as a separate frontend application that talks to an API? I first wrote about this in 2019, when React was winning every argument by default. The answer has matured since then, and so has the tooling on both sides.

Two different jobs

A backend language such as Ruby, Python or Node is good at the things that make an application trustworthy: modelling data, enforcing business rules, talking to payment providers, sending mail, running background work and protecting everything behind authentication. Those concerns change slowly and need to be correct every time.

A frontend framework such as React, Vue or Svelte is good at the things that make an application pleasant: instant feedback, optimistic updates, drag and drop, keyboard shortcuts, offline states and complex forms that respond as you type. Those concerns change quickly and are judged by feel rather than by correctness.

Splitting the two lets each side use the tool built for its job. The API becomes a stable contract, the interface becomes a client of that contract, and neither has to know how the other is implemented.

When the pairing pays for itself

• The interface is app-like. Dashboards with live filtering, editors, planners, anything where the user stays on one screen for minutes and expects it to react instantly.
• More than one client will use the same data. A web app plus an iOS or Android app is the classic case. One JSON API serving three clients is far cheaper than three sets of server templates.
• Two teams need to move in parallel. With a documented API, a frontend developer can build against mock responses while the backend is still being written.
• You are integrating third-party UI. Rich text editors, charting libraries and design systems are overwhelmingly built for a JavaScript frontend first.

What it costs

A separate frontend is a second application. It has its own build pipeline, its own dependency updates, its own deploy, and its own ways of breaking. Authentication becomes token management instead of a session cookie. Search engines need server-side rendering or pre-rendering to index your pages. Validation rules get written twice, once for instant feedback in the browser and once for real enforcement on the server.

The question is not whether a frontend framework is good. It is whether your product has enough interaction to justify running two applications instead of one.

The middle path most products should start on

Modern Rails ships with Hotwire, which gives server-rendered HTML most of the responsiveness people associate with a single-page app. Turbo makes navigation feel instant, Turbo Frames update parts of a page, and Stimulus adds small, focused JavaScript behaviours. For a typical business product, this covers eighty to ninety percent of screens with one codebase, one deploy and one mental model.

The remaining screens, the ones that are truly interactive, can host a React or Vue component inside a Rails view. You get the rich interaction where it matters without turning the whole application into an API client. If that island grows into most of the product, you have earned a dedicated frontend, and the API you extract will be based on real usage instead of guesses.

A simple decision guide

1. Count the screens that need to update without a page load. If it is fewer than a handful, render on the server and add Hotwire.
2. Ask whether a mobile app is on the roadmap within a year. If yes, design the backend as an API from the start, even if the first web client is server-rendered.
3. Look at the team. One full-stack developer is more productive in a single Rails app. Separate frontend and backend specialists are more productive with a clear API between them.
4. Whatever you pick, keep every rule that matters in the backend. The browser can be bypassed; the server cannot.

If you are weighing this decision for a product of your own, tell me about it. I have built both kinds and am happy to give a straight answer for your situation.