# The joy of Inertia Rails: painting your own with 50 happy little lines > Inertia is Turbolinks with one twist: render JSON instead of HTML on the second visit. We rebuild the whole protocol on a real Rails app with a 50-line client and a 16-line server, then audit what the real gem adds on top. - Date: 2026-07-14T00:00:00.000Z - Authors: Svyatoslav Kryukov, Travis Turner - Categories: Rails, Open Source - URL: https://evilmartians.com/chronicles/the-joy-of-inertia-rails-painting-your-own-with-50-happy-little-lines --- Hi there, welcome back, so glad you could join us again. You know, we've painted with Inertia.js on this blog many times, but today is gonna be a little different: today we make the brush ourselves. Then, we'll end up with a 50-line React client, a 16-line Rails renderer, wet-on-wet, running on a real Rails app. There won't be any mistakes here (only happy little headers) so just relax, and we'll let this post unfold. This one's for anyone deciding whether to bet on Inertia for frontend (that includes the _future you_ who'll have to defend that bet). People will say a frontend needs a big bunch of things: a client-side router, a state library, an API layer, a year of your life. We don't need that here. All we need is one little header, one nice little page object, and about fifty lines. And you can do it too. [Inertia's own docs](https://inertiajs.com/docs/v3/getting-started) insist it isn't a framework, and by the end of this post you'll see why: the whole thing fits on one small canvas. Don't evaluate Inertia by its feature list. Evaluate this claim instead: its wire format is small enough to read in one sitting, and every feature is just that same format, applied again. *Read also Evil Martians' article*: https://evilmartians.com/chronicles/inertiajs-in-rails-a-new-era-of-effortless-integration Everything below runs, and nothing is pseudocode. The demo app is a real Rails app with one Git commit per feature: [skryukov/the-joy-of-inertia-rails](https://github.com/skryukov/the-joy-of-inertia-rails). --- *Playbook, Stackblitz, Fountain, Monograph–we joined the best-in-class Rails startups to speed up, scale up and win! Curious? Let's talk!* [Contact Evil Martians](https://evilmartians.com/contact-us) --- ## Wet-on-wet: Turbolinks, 2012 Everything on this blog happens wet-on-wet. We don't wait for a layer to dry; we paint the next stroke right into the last one, and the painting stays alive the whole time. The web learned its own version of that trick in 2012. The Rails answer to "_why does every click re-download the whole world?_" was [Turbolinks](https://github.com/turbolinks/turbolinks), and its mechanics fit in one sentence: intercept the click, fetch the next page's HTML over XHR (an in-page request; today you'd use `fetch`), swap the ``, keep the current JavaScript runtime alive, and update the URL with `pushState`. The browser never does a full navigation—the canvas never dries—so the app feels like an SPA. But the server keeps doing what servers do best: routing, authentication, rendering, redirects. This comes with no API layer, client-side router, or state synchronization problems. The idea lives on today as [Turbo Drive](https://turbo.hotwired.dev/handbook/drive), the heart of Hotwire. That technique carries a little but radical premise: **the server owns the page.** ## "Beat the devil out of it": the mutation Now, suppose your views aren't ERB templates. Your team builds views in React, or Vue, or Svelte—because you want their component model, their ecosystem, their typed props. Turbolinks has nothing to swap: there's no server-rendered `` to fetch, because the "view" is a component living in the browser. This is the fork in the road where most teams throw out their technique with the paint. They build a JSON API, adopt a client-side router, add a data-fetching library, and sign up to keep two applications in agreement about what a user is. [We've written before](/blog/simplicity-vanished-solving-the-mystery-with-inertia-js-and-rails) about what that costs. *Read also Evil Martians' article*: https://evilmartians.com/chronicles/simplicity-vanished-solving-the-mystery-with-inertia-js-and-rails [Jonathan Reinink](https://reinink.ca/articles/server-side-apps-with-client-side-rendering) asked the better question: _what's the smallest change to the Turbolinks idea that survives component views?_ And a component is just a function of two things—a name and its props. **So: on the first visit, render HTML, same as always. Then, on every visit after that, render JSON that describes the component to draw.** From there, everything else falls out of two questions. **What goes in the JSON?** The component's name, and its props, the URL, (so the address bar can tell the truth), and an asset version, so the server can notice your tab is running last week's JavaScript. This ends up as four fields: ```json { "component": "pages/about", "props": { "year": 2026 }, "url": "/about", "version": "1" } ``` **How does the server know which kind of visit this is?** One request header: `X-Inertia: true`. Present, you get the JSON. Absent, you get a full HTML page with that same JSON embedded in a `