Here's a little message board.
Type something in the box at the bottom of the page. Don't post it. Just type.
Then click About in the black bar at the top.
Keep an eye on the strip of four little counters above the page while you do it.
Your draft is gone.
So is the uptime counter. So is the scroll position. So is anything else the page was holding in memory.
The HTML the server sends has two halves: a <head> (title, stylesheet and script links) and a <body> (everything you can see). The browser turns that text into a tree of live objects, the DOM, and runs your JavaScript against it. That tree, plus the JavaScript's memory, is the page process.
That's what a page load is. The browser throws away the whole process and builds a new one from the HTML the server sent. Look at the server's response on the right: all of it got used, top to bottom.
This is how the web worked for twenty years, and it's how a plain Rails app works today. Every click: everything, again.
Try it once more if you like. Click Messages to come back, type, click About. It never gets kinder.
How small can the blast radius get?
Single-page apps fixed the draft problem by never loading a page again. They keep one process alive and paint HTML themselves from JSON. That works. It's also a whole second application to write, and your Rails views stop being the truth.
Hotwire's bet is different: keep the server writing HTML, and shrink how much of the page you throw away.
Every piece of Hotwire is an answer to the same question. When something changes, how much of the page do you replace, and who decides? This is the ladder we're going to climb, one rung at a time:
- r₀page loadeverything
- r₁Turbo Drivethe <body>
- r₂morphingonly what changed
- r₃Turbo Framesone box
- r₄Turbo Streamsnamed elements
- r₅Stimulusnothing · add behaviour