Vue 3.6 entered release-candidate stage in July, and with it Vapor Mode is finally feature-complete: single-file components that compile straight to direct DOM operations, skipping the virtual DOM entirely. I have a strange reason to care about this — I've been doing Vapor's job by hand.
I use Vue daily in client work, so I care about 3.6 for the usual reasons: smaller bundles, faster updates. But for a while now I've also been hand-writing logic games for this site — a nonogram, a minesweeper variant, numberlink, mastermind, a 3D Rubik's cube with built-in solvers, a speedcubing timer. Each game is one page, no framework, no heavy libraries. Just state and direct DOM manipulation. That experience is basically a preview of what Vapor Mode does — except I've been the compiler.
What you learn when there's no virtual DOM to hide behind
Take the nonogram. The board is a grid of cells; a click toggles one cell and possibly updates a couple of row and column clue indicators. In the naive framework mental model, the view is a function of the whole board state, and something diffs its way to the minimal change. Writing it by hand, you can't afford that mental model. You think in deltas: this click changes this cell's class and these two clue elements, nothing else. You write exactly those three DOM operations and you're done.
The minesweeper was the same lesson at higher stakes. Mine is a no-guess variant — every generated grid is verified by a solver so you're never forced into a 50/50. When a flood-fill reveals dozens of cells at once, you feel every unnecessary DOM touch. So you batch: compute the full set of cells to reveal in pure JS, then apply the class changes in one pass. State first, DOM second, and only the DOM that actually changed.
The 3D Rubik's cube pushed this furthest. Animating layer turns and running solvers (layer-by-layer, CFOP, optimal) means the interesting work lives entirely in the state model — the render layer is a thin projection of it. Once you structure things that way, "rendering" stops being the hard part of the app.
What this says about Vapor Mode
Three takeaways from doing manually what Vapor now does at compile time.
First, the virtual DOM was never primarily a performance feature. It's a developer experience feature: it lets you write view = f(state) and not think about deltas. The diffing is the price you pay for that mental model, not a speed trick. Vapor's bet is that a compiler can keep the declarative authoring model and emit the delta-based code I was writing by hand — the best of both.
Second, the discipline that no-framework code forces on you — keep state pure, treat the DOM as a projection — is exactly the discipline that makes components fast in any framework. If your component's state is tangled with its DOM, no rendering strategy saves you.
Third, there's a real ceiling on how much this matters. My games are the favorable case for direct DOM updates: high-frequency, localized mutations on large grids. A typical CRUD form re-renders so rarely that VDOM overhead is noise. If your Vue app is mostly forms and tables, Vapor will shrink your bundle more than it speeds up your interactions — still worth it, but know which benefit you're buying.
Would I still hand-write the games after Vapor lands?
Yes — but for a different reason than performance. Keeping each game dependency-free means these pages will still work untouched in ten years, and writing the update logic myself is half the fun. For product work, though, Vapor is the right direction: it takes the rendering strategy that low-level code teaches you and makes it the default output of the declarative code you'd write anyway.
One caveat: 3.6 is still a release candidate as I write this. Feature-complete is not stable — I'm not shipping it to client projects until the stable release, expected this autumn.
The games are all playable in the games section if you want to see the hand-rolled version of "vapor mode" in action.