Vue 3.6 release candidate delivers feature-complete Vapor Mode without the virtual DOM

Vue 3.6 has entered its release-candidate phase, and Vapor Mode — the rendering strategy that compiles components to direct DOM operations instead of routing updates through a virtual DOM — is now feature-complete, according to a post on dev.to. The release candidate arrived in July, and a stable release is expected in the autumn.

What Vapor Mode changes

Under Vapor Mode, single-file components are compiled so that updates translate into straight-line DOM manipulation: change this element's class, set this attribute, patch these specific nodes. The virtual tree and the diffing pass that normally reconcile it are bypassed entirely. Bundle sizes shrink because the runtime machinery for diffing is no longer needed, and updates get faster because only the operations that are actually required get executed.

The dev.to author's framing is notable: the virtual DOM's main job was never raw speed — it exists to make development easier, letting programmers describe a view as a function of state and hand off the work of computing minimal updates to the framework. Diffing is the price of that convenience. Vapor Mode's wager is that a compiler can preserve the declarative authoring style while emitting the kind of targeted update code a developer would write by hand if there were no runtime to lean on.

Lessons from writing browser games without a framework

The author's evidence comes from an unusual side project: a set of hand-built logic games published on a personal site — a nonogram, a minesweeper variant whose generated grids are verified by a solver so players never face forced guesses, numberlink, mastermind, a 3D Rubik's cube with several built-in solving methods, and a speedcubing timer. Each game is a single page, built framework-free with no heavyweight dependencies, relying on plain state and direct DOM manipulation.

Three lessons stand out. First, think in deltas: a click on a nonogram cell changes one cell and a couple of clue indicators, and the correct response is exactly those writes and nothing more. Second, batch aggressively: when a minesweeper flood-fill uncovers dozens of cells at once, the full set of changes is computed in plain JavaScript and applied in one pass, so no DOM node is touched unnecessarily. Third, keep the interesting work in the state model: once the Rubik's cube's render layer merely reflected its state, rendering stopped being the hard part of the app.

The author argues this is essentially a manual preview of what Vapor Mode does, with a human doing the job the compiler now performs.

Where the gains actually land

The post is candid about the ceiling. High-frequency, localised mutations on large grids are the best case for direct DOM updates. A typical application built from forms and tables re-renders so rarely that virtual DOM overhead is effectively inaudible; for those apps, the main win from Vapor Mode is a smaller bundle rather than snappier interactions, and it is worth being clear about which of the two benefits matters for your app.

The discipline also generalises: keeping component state separate from the DOM is what makes components fast under any rendering strategy. Entangled state defeats every optimisation a framework can throw at it.

Why it matters

Vapor Mode narrows a long-standing trade-off in declarative frameworks, where ergonomics were bought with runtime cost. A compiler that emits surgical DOM updates keeps the ergonomics and refunds much of the cost, turning a technique once reserved for hand-written, low-level code into the default output of ordinary component code. For a major frontend framework to ship that as a supported mode — not a fork or an experiment — is a real shift in what its standard runtime looks like.

The usual release-candidate caution applies. Feature-complete is not stable, and the author, who uses Vue daily in client work, is not deploying 3.6 to production projects until the stable release lands. Even after it does, the hand-written games will stay framework-free — a deliberate choice for longevity and for the enjoyment of writing the update logic by hand — while product work moves toward Vapor once it is stable.