Vue 3.6's 13th release candidate: seven of eight fixes live in the Vapor compiler

Vue 3.6.0-rc.13 landed on October 23. Reaching a thirteenth release candidate is itself a signal: a minor version that only adds APIs does not get to rc.13. Open the changelog and seven of eight fixes are in compiler-vapor; the eighth is in runtime-core.

The shape of the list

Sorted by category rather than by order, the fixes look like this:

Area	What was fixed
Directive semantics	v-once now matches vdom behavior on v-else-if chains
Compiled output	long v-else-if chains compile to a flat createIfChain
Expressions	object shorthand aliases with defaults or computed keys now keep their key
HTML parsing	breakout elements in foreign content, text inside table parts created imperatively
Parser boundaries	a descendant gets its own template when the parser would close an ancestor
End tags	the end tag of a special element survives when its parent cannot close it
Built-ins	children of non-root Transition / KeepAlive are marked as a single root

Not one item is a feature. They are all semantic-equivalence bugs. Vapor compiles templates into code that touches the DOM directly, skipping the virtual DOM. But “skips vdom” does not mean “may behave differently”: when v-once skips an update, which branch of a v-else-if chain wins, whether a Transition child counts as a single root — those are established facts in vdom, and Vapor has to match them one by one.

Why long v-else-if chains get flattened

The createIfChain entry deserves its own paragraph. Take a chain of v-if / v-else-if / v-else-if ... / v-else. The naive compilation nests them: every v-else-if sits inside the else branch of the previous one. Ten branches means ten levels of nesting, evaluated level by level at runtime.

Flattened, it becomes a table: evaluate conditions in order, render the first match. With many branches the difference is not raw big-O — it is the length of the update path. In the nested version, changing the first condition means walking the whole nested structure again.

// roughly: the chain becomes an array of branches evaluated in order
const branches = [
  () => ok.value,      // v-if
  () => pending.value, // v-else-if
  () => true,          // v-else
];

This kind of change will not move a benchmark number. It fixes code size and update cost for deeply chained templates — and a real admin screen with five or six status branches inside a table cell is common.

The eighth fix: 200 milliseconds

The only non-compiler fix restores the default 200ms delay for async components.

defineAsyncComponent waits 200ms before showing a loading state, so that a 30ms load does not flash a spinner. That default was changed during the 3.6 cycle, and rc.13 changes it back.

I read it as a reminder that defaults are API. Any casual tweak to a default turns into a visible regression in real projects: a spinner that flashes, a skeleton that jumps. Users cannot name what is wrong, they just decide the site feels cheap.

Should you upgrade now

My answer: not on a production app yet; wait for the stable release. Not because Vapor is unstable, but because the rc number tells you fixes are still arriving daily — seven compiler semantics fixes in one release means edges remain. Vapor is opt-in, but the vue package you install is a single artifact, compiler included.

What is worth doing now is reading Vapor’s compiled output. The difference from vdom is not “a bit faster” — it is a different update path. vdom diffs two trees; Vapor knows at compile time which DOM node maps to which reactive dependency and writes straight to that node. Once that clicks, you can judge which patterns in your own component library get expensive under Vapor: heavy dynamic components, recursive components, runtime-built templates.

The stable release is probably not far off. The work worth doing before then is not the upgrade itself — it is auditing your templates for deep conditional chains and runtime-assembled markup.