Compiler: props literals with accessors are the largest SSR self-time bucket on composition cases (computed keys + closure-per-getter)

[ryansolid]

Status (Sep 17): finding 1 landed in #3514. Finding 2: options (a)/(b) below are withdrawn — prototype getters break {...props}/destructuring in reactive expressions, which is supported. The plan is (c) re-measured: per-site class behind a Proxy, SSR generate only, with a literal fallback for sites whose captured bindings aren't provably constant. Verdict, microbenchmarks, and the measured fallback rate (≤0.4% library / 2–4% apps): #3511 (comment)

Tracking item 6 of #3389. Profiling the composition cases in yak-bench (polymorphic-chain, tabs) after #3497/#3509 shows the compiled component code itself — not merge/omit, not the serializer — as the largest single self-time bucket on the server: 24–26% of SSR time on both cases, and ~18% of allocation. Almost all of it is the props literal the compiler emits at each component call site.

Exhibit

ButtonRoot from polymorphic-chain, as compiled (SSR, @solidjs/compiler; babel output is identical by parity):

function ButtonRoot(props) {
  const merged = merge({ type: "button", disabled: false, variant: "solid" }, props);
  const others = omit(merged, "as", "type", "disabled", "loading", "variant");
  return Polymorphic(merge({
    get as() { return merged.as ?? "button"; },
    get type() { return memo(() => merged.as === "a")() ? void 0 : merged.type; },
    get disabled() { return merged.disabled; },
    get ["aria-disabled"]() { return merged.disabled || void 0; },
    get ["data-disabled"]() { return merged.disabled ? "" : void 0; },
    get ["data-loading"]() { return merged.loading ? "" : void 0; },
    get ["data-variant"]() { return merged.variant; }
  }, others));
}

Every render of every ButtonRoot allocates seven closures and an accessor-bearing object literal. React's equivalent is { ...rest, type, disabled, "aria-disabled": ... } — one plain object.

What it costs

Microbenchmark of exactly this shape (7 getters over a captured merged; build the object, read all 7 keys once — what ssrElement does), min of 7 × 200k, Node 26:

form	TurboFan	--no-opt	retained
literal, computed keys — today	966 ns	715 ns	1274 B
literal, get "aria-disabled"() (string-literal keys)	525 ns	485 ns	1096 B
literal, all identifier keys	482 ns	482 ns	1096 B
own accessors, shared getters via Object.defineProperties	869 ns	—	400 B
per-site class, getters on the prototype	66 ns	68 ns	40 B
plain object (React's shape)	46 ns	45 ns	88 B

Two independent findings in that table.

1. Computed keys cost 45% on their own — pure codegen bug, zero semantics

Both compilers emit non-identifier keys as computed accessors:

• packages/babel-plugin/src/shared/component.ts — t.objectMethod("get", id, [], body, !t.isValidIdentifier(key)), three sites around L286–L318 (also ssr/element.ts L1041, universal/element.ts L457).
• packages/compiler/src/shared/ast.rs L220 — mirrors it deliberately: "Babel: … non-identifier getter keys are computed (get ["hyphen-ated"]())".

get ["aria-disabled"]() and get "aria-disabled"() are the same property, but a computed key in an object literal drops V8 off the literal boilerplate path into DefineKeyedOwnPropertyInLiteral per property. Every aria-*, data-*, and class prop pays it. Fix is to pass computed: false with a string-literal key (Babel accepts objectMethod("get", stringLiteral, …, false); oxc PropertyKey::StringLiteral likewise). Fixtures pinning the computed form: 14 files under packages/babel-plugin/test/__*_fixtures__/, plus packages/compiler/__tests__/fixtures/** and one expected-cross parity diff.

This is a small PR with no design question in it.

2. The accessor literal is structural — 7× time, 27× memory vs prototype getters

Even with identifier keys, a 7-getter literal is ~480 ns / 1.1 KB because each render allocates 7 closures plus an object whose accessor properties can't share a boilerplate. A per-call-site hidden class whose getters live on the prototype and read the captured scope through instance fields gets it to 66 ns / 40 B — within 1.5× of React's plain object, with the laziness intact:

// emitted once per call site
class ButtonRoot$props1 {
  constructor($0) { this.$0 = $0; }
  get as() { return this.$0.as ?? "button"; }
  get type() { return memo(() => this.$0.as === "a")() ? void 0 : this.$0.type; }
  get disabled() { return this.$0.disabled; }
  get "aria-disabled"() { return this.$0.disabled || void 0; }
  // …
  static keys = ["as", "type", "disabled", "aria-disabled", …];
}
// at the site
Polymorphic(merge(new ButtonRoot$props1(merged), others));

The compiler already knows each getter body's free variables (it has to, to hoist templates and detect statics), so the constructor's fields are mechanical.

The cost is own-key semantics. Prototype getters are not own properties, so:

• Object.keys(props), for…in, {...props}, Object.entries, Reflect.ownKeys all return ["$0"].
• Object.getOwnPropertyDescriptor(props, k) is undefined → isStatic() and the truthful-descriptor protocol from perf(signals,web): omit over a merge holds the merge record — one record per layer, one-pass owners walk for ssrElement #3497 need a prototype-aware path.
• merge/omit/ssrElement/spread today enumerate own keys of plain sources — they'd need to recognize the class (a static keys or a $KEYS symbol) and read via in/get. That part is contained: it's the same protocol surface that already special-cases views.
• User code doing splitProps/{...props} on props that arrived as a compiled literal would silently see nothing. Today it works because the literal has own accessors.

Which is why this can't be a silent codegen swap the way (1) can. Options as I see them:

• (a) Accept the semantics change for 2.0: compiled props objects are opaque and must be read through the protocol (merge/omit/splitProps/property access). Document that Object.keys(props) is unsupported — arguably already true in spirit, since props are often merge/omit views whose keys come from a trap.
• (b) Emit the class form only where the compiler can prove the receiver is a protocol consumer — i.e. the literal is an argument to merge()/omit()/spread at the same site (exactly ButtonRoot's case: merge({…}, others)). Direct Comp({…}) calls keep the literal. Covers the polymorphic pattern that dominates these profiles without touching user-visible props shape.
• (c) Make the class iterable/enumerable through a Proxy — no; that reintroduces the allocation and trap cost we're removing.

(b) is the conservative one and gets most of the measured win on these cases; (a) is the one that gets all of it. Either needs a decision before code.

Expected impact

Composition-case SSR: compiled components are 24–26% of self time. Fix (1) removes ~45% of literal-construction cost at sites with hyphenated keys (most of polymorphic-chain's are); how much of the bucket that is depends on the key mix, so it needs measuring in the harness rather than estimating. Fix (2) takes most of what remains. It also cuts ~18% of allocation → GC (13–15% of SSR time on these cases). Client hydrate/mount pay the same literal cost per component instance.

Repro: yak-bench nested2 lanes, node --cpu-prof on dist/nested2/solid-mprim/ssr/entry.js with --no-turbo-inlining, attributed via sourcemap; microbenchmark shape above.

— Claude via Cursor

[GabbeV]

@ryansolid
This could be taken further, avoiding storing individual captured properties in $0 etc. I had AI write up how it could work. The idea is that we replace the capture object v8 it self would allocate for the instance with a class and then use that class as the context to all props and closures.

The semantic changes would be the same as in your proposal here with props no longer being own properties and loss of tdz errors for locals.

AI:

Could the component scope itself become a shared state instance? Captured locals become fields, shared by props getters and methods. For an arrow like this, binding the method could avoid a separate lexical capture context.

Input:

function Parent(props) {
  const [count, setCount] = createSignal(0);
  const increment = () => setCount(count() + props.step);

  return [
    <Counter value={count()} onClick={increment} />,
    <Summary total={count() * props.step} />
  ];
}

Illustrative output:

class ParentState {
  constructor(props) {
    this.props = props;
    [this.count, this.setCount] = createSignal(0);
    this.increment = this.increment.bind(this);
  }

  increment() {
    this.setCount(this.count() + this.props.step);
  }
}

class CounterProps {
  #state;
  constructor(state) { this.#state = state; }

  get value() { return this.#state.count(); }
  get onClick() { return this.#state.increment; }
}

class SummaryProps {
  #state;
  constructor(state) { this.#state = state; }

  get total() {
    return this.#state.count() * this.#state.props.step;
  }
}

function Parent(props) {
  const state = new ParentState(props);
  return [
    Counter(new CounterProps(state)),
    Summary(new SummaryProps(state))
  ];
}

Both children and the callback share the same state instance. Beyond the signal’s own allocations: one state instance, one props instance per child, and one bound callback. Getter and method implementations are shared across instances. This assumes accepting the props-shape changes discussed above.

[ryansolid]

Status update — finding 1 landed, finding 2 narrowed to an SSR-only form, and the fallback rate is now measured.

Finding 1

Landed in #3514: both compilers emit non-identifier getter keys as string literals (get "aria-disabled"()), never computed. No design question, no fixture semantics change.

Finding 2 — the bare class is out

Options (a) and (b) above are withdrawn. Spreading and destructuring props inside a reactive expression (createMemo(() => ({ ...props })), const { a, b } = props in an effect) are supported usage, not an accident of the literal, and prototype getters make both silently return nothing. That's a correctness regression hiding in a perf change, in any generate.

Option (c) — the class behind a Proxy that preserves own-key semantics — was dismissed above on the assumption that it "reintroduces the allocation and trap cost." Measured, that's half right, and the half that's wrong is the one that matters for the server. Same 7-getter shape as the table above, post-#3514 baseline:

form	build	read props.x	retained
literal, string-literal keys (today, post-#3514)	437 ns	5 ns	1097 B
per-site class + Proxy (own-key semantics preserved)	132 ns	17 ns	80 B
per-site bare class (rejected)	53 ns	5 ns	40 B

The proxy is a construction win (3.3×, 14× less memory) and a per-read loss (3.4×). Break-even is ~25 reads per props object over its lifetime. ssrElement and the server-side merge/omit read each prop about once, so the server clears construction and stops. A client component's effects re-read their props on every run for as long as the component lives — an interactive component passes 25 reads in its first few updates and then keeps paying, and the loss compounds with app lifetime. So:

• SSR generate only. Client emission is unchanged, byte for byte.
• Hydration parity holds. Getter bodies evaluate at the same moments as the literal's (lazily, on read); static data props are own fields assigned in the constructor in source order; ownKeys returns the site's key list in source order. The server produces the same values, in the same order, as the client literal would.
• Bloat is server-only. Each site hoists a constructor, a prototype with the same getter bodies, and a keys array — 1.5–2× the literal's source, in the server bundle, parsed once per process. Smaller per site than the hoisted template strings we already emit for every element.

How a site qualifies (per-site capture, literal fallback)

Getter bodies move to a prototype and read their free variables through one captured-scope field. Module-scope bindings (imports, hoisted templates, top-level helpers) aren't captured — the prototype references them directly. A site takes the class form only if every function-local binding its getter bodies reference is:

• constant (Babel binding.constant / oxc symbol_is_mutated false), and
• declared before the site (no TDZ difference between eager capture and lazy read), and
• never written inside a getter body, including from nested arrows, and
• the bodies use no this / arguments / super / new.target.

Anything else and the site keeps today's literal. Scope analysis is exact, so every site either provably has identical semantics in both shapes or keeps the shape it has now. A fallback site is the client's shape, so it can't introduce drift.

Measured fallback rate

Two independent measurements over real code, which agree within a couple of sites per corpus. (1) A source-level survey that replicates the compiler's getter selection and applies the rules above. (2) Running the actual babel plugin (generate: "ssr", hydratable: true) over the same files, re-parsing the output, and classifying every emitted props literal that carries a getter. Tests and stories excluded. Column shown is (2), the SSR truth.

Library-shaped (where the SSR win lands):

corpus	props literals with getters	fallback
Kobalte solid2 core (2.0.0-rc.3)	390	1 (0.3%)
Kobalte docs app	1681	0
corvu	73	1 (1.4%)
solid-primitives	217	5 (2.3%, all in dev/ demos)
@ark-ui/solid	6317	17 (0.3%, all in examples/)
solid-ui (registry + docs)	1204	1 (0.1%)

App-shaped (the four largest real Kobalte consumers on GitHub, all Solid 1.x + Kobalte):

app	props literals with getters	fallback
opencode (packages/app + packages/ui)	2256	82 (3.6%)
Cap desktop	2402	46 (1.9%)
Primal web	2615	95 (3.6%)
MacroGraph	432	9 (2.1%)

So: ≤0.4% fallback in library code, 2–4% in apps. The fallbacks are two shapes, roughly even: a let ref passed to a component (<Popover.Content ref={el}> — Kobalte parts are components, so the compiler emits ref(r$){ el = r$ }) and then read by a sibling or enclosing getter; and mutable let state read in a getter or written by a handler nested inside a children getter. this/arguments and declared-after are real but rare (11 and 12 sites across ~7.7k app literals) — the checks are necessary, they don't drive the rate. Zero fallbacks came from anything else.

Capture is small: 3.3 locals per site in Kobalte core, 5.3 in corvu, under 1 in app code (children getters that only reference module-scope components) — consistent with the 80 B figure.

One implementation constraint from the same data: the SSR emitter hoists var _v$, _v$2 temporaries to the function scope and assigns them inside getters (get children() { return _v$ = _$ssrHydrationKey(), … }). That's 6% of Kobalte core literals and 25–44% of app literals. Those are the emitter's own; the class emission has to scope them into the getter body, or they'd become the dominant "fallback" by a wide margin.

Plan

1. SSR generate in both compilers: binding analysis, per-site class + proxy, literal fallback, _v$ scoping; parity fixtures.
2. Runtime brand so merge/omit/ssrElement unwrap to the target and read prototype getters directly — a perf add-on, not a correctness requirement; without it Object.keys(proxy) is still right, just through the traps.

— Claude via Cursor

[ryansolid]

@GabbeV thanks — this is a good comment and the direction is right. Where I land on it, with the numbers above in hand:

Where your form is genuinely better. It removes the reassignment fallback. In the per-site version a getter that reads a let assigned later has to fall back to the literal, because the field is a snapshot of the value. In yours the let lives in the state object and every write is rewritten to state.x = …, so getters read the live binding — that's the correct semantics rather than a snapshot, and it's exactly the shape of every fallback the survey found (mutable let, component refs, handlers nested in a children getter). Your version would take the app-shaped rate from 96–98% fast path to ~100%.

Where it isn't. Per-instance cost is the same: one props instance holding one pointer, whether that pointer is to a per-site capture object or a shared state object. And the state object doesn't save an allocation — V8's closure context for the component body is already a single shared allocation per invocation; the transform swaps a context for a userland object with the same fields. So the gain is coverage, not speed, and coverage is measured at 2–4% of sites in apps and ≤0.4% in libraries.

Against that, closure-converting the whole component body is an order of magnitude more compiler than "for this literal's getters, which local bindings are referenced, and are they constant?" — shadowing, nested functions that reference the locals, this inside them, destructuring patterns, hoisted function declarations, async/generator bodies, and it has to be done twice, in parity, on the path every server component takes. The per-site version is bounded work with a mechanically provable fallback.

Two smaller notes:

• The TDZ concession isn't needed in the per-site version — the declared-after check just bails (12 such sites in ~7.7k app literals, so it's real).
• If anyone builds the #state private-field variant: it only works behind the proxy if the get trap does t[k], not Reflect.get(t, k, receiver) — a private-field access with the proxy as receiver throws.

All of this is SSR-only, which the issue didn't make clear when you commented. The onClick={increment} / bound-method half of your example is a client concern, and the client keeps the literal regardless of which form we pick — not because the concept is foreign there (the closure context exists identically on the client) but because of the measured 3.4× read tax through the proxy, which the client pays for the component's whole lifetime and the server pays once.

So the plan is per-site capture first. Your shared-state form is a strict superset — same prototypes, same proxy, same key list; only what the captured-scope field points at changes — so if the fallback path ever shows up in a profile, it's the natural next step rather than a rewrite.

— Claude via Cursor

[ryansolid]

In-harness spike: the proxied class form is a regression without the runtime brand and the largest SSR win in the tracker with it — and the reason is that every accessor literal is a dictionary-mode object.

Method: a throwaway post-pass over yak-bench's bundled SSR entry (post-#3514 baseline, lanes/ region only, runtime untouched) that rewrites every component props literal into the per-site class + Proxy form with the capture rules above — 42 sites, 42 rewritten, 0 fallbacks; nested sites compose (Tab(new Proxy(new _P39(t, this.$props), …)) inside the outer children getter). All 15 cases render byte-identical HTML against baseline, hydration keys included, with no runtime change — the proxy goes through the existing plain-object path ($PROXY in o is false → SOURCE_PLAIN → Object.keys / in / [] via traps). Measured interleaved, 8 reps, CPU-µs per render (process.cpuUsage) and scavenge count at a fixed 1 MB semi-space; both load-independent.

Without the brand — a loss

case	cpu/render	scavenges
polymorphic-chain (n=400)	3357 → 3241 µs (−3.5%)	−3.7%
tabs (n=150)	3929 → 5195 µs (+32%)	+14%
multifile-composition (n=150)	3974 → 5213 µs (+31%)	+11%

Trap counts per tabs render: 2775 ownKeys, 6975 getOwnPropertyDescriptor, 6025 has, 9150 get — ~25k trap calls. The ownKeys + gOPD pairs are Object.keys(props) on a Proxy: the engine asks [[GetOwnProperty]] per key for enumerability and materializes each trap result into a fresh descriptor object. That is where the allocation increase comes from, and it is what the construction microbenchmark didn't model — the runtime's plain path (leafKeys, ssrElement's keysOf, yak's createStaticComponent) all key-walk with Object.keys.

With the brand — a large win

Same bundle plus three one-line consumer patches: the handler answers a $KEYS symbol with its static key list, and leafKeys, ssrElement, and yak's Object.keys(props) take it before falling back. ownKeys/gOPD traps drop to zero; HTML still byte-identical on all 15 cases.

case	cpu/render	scavenges
polymorphic-chain (n=400)	3324 → 1714 µs (−48%)	1520 → 1168 (−23%)
tabs (n=150)	3976 → 3423 µs (−14%)	−13%
multifile-composition (n=150)	3982 → 3434 µs (−14%)	−14%

Why −48%, not the −15–20% the construction cost predicted

%HasFastProperties on Node 26: any object literal containing a getter is a dictionary-mode object. One getter, seven getters, identifier keys or hyphenated, with or without data props — all false. Data-only literals, method-only literals, and class instances are true. So every compiled props object with a dynamic prop is a hash-table object, and every in, [], and Object.keys on it — through every merge/omit layer — is a slow-path lookup. The class form fixes the reads, not just the construction, and on the chain the reads through several layers were most of the cost. (The microbenchmark's 5 ns literal read was a monomorphic IC on one object in a tight loop; the harness's polymorphic, layered reads are the realistic case, and they disagree.)

What changes in the plan

• The runtime brand is a precondition, not a follow-on. Step 2 moves ahead of step 1's merge: leafKeys / sourceHas / sourceGet / sourceDescriptor / isStatic recognize the brand and read the key list, prototype getters, and a static descriptor table directly; ssrElement likewise.
• A public keys(props) (or equivalent) so component libraries stop calling Object.keys(props) — yak's createStaticComponent does, per instance, and pays the trap pair without it.
• The dictionary-mode fact reopens the client question I closed above. The "3.4× read tax" compared the proxy's 17 ns to a 5 ns literal read that the harness says isn't representative of layered reads on a dictionary-mode object. That needs its own in-harness measurement on hydrate/mount before any client decision; nothing here changes the client plan yet.

Spike artifacts: post-pass, brand patch, verifier, A/B driver and logs are kept locally; the two rewritten bundles diff byte-identical against baseline on every case.

— Claude via Cursor

[ryansolid]

The proxied class form is withdrawn. The fix for finding 2 is a class whose getters are own accessors defined from shared static descriptors, with the captured locals in a private field — a compiler-only change with the literal's exact semantics, and it beats the literal on every axis measured.

Why the Proxy form is out

The brand above made the runtime's reads fast, but the props object is also user code's object, and the spec makes enumerating a Proxy expensive by construction: Object.keys runs the ownKeys trap and then a getOwnPropertyDescriptor trap — a descriptor allocated — per key. Measured against today's literal (4 keys, 2 getters): Object.keys 17× slower, for…in 13.5×, {...props} 3.6×, one getOwnPropertyDescriptor 15×. structuredClone(props) throws; Node's console.log(props) prints the class internals. Telling libraries to use a keys() helper instead of Object.keys is a one-line swap; telling component authors not to for…in, spread, or rest-destructure their props on the server is not something we can ask. So the brand, the SOURCE_PROPS kind, and the keys() API are all withdrawn — none of it is needed.

The form

class _P1 {
  #m;                                         // captured locals: a private field is not a property
  static $disabled = { get() { return this.#m.disabled; }, enumerable: true, configurable: true };
  static $label    = { get() { return label(); },        enumerable: true, configurable: true };
  constructor(m) {
    this.#m = m;
    this.as = "a";                            // data props: fields
    this.class = "btn";
    Object.defineProperty(this, "aria-label", _P1.$label);   // getters: OWN accessors, shared descriptor
    Object.defineProperty(this, "disabled", _P1.$disabled);
  }
}
Trigger(new _P1(merged));

Every key is genuinely own, so Object.keys, for…in, spread, rest, hasOwn, JSON.stringify, structuredClone, console.log are the literal's. The getter function is shared (one per site, not one closure per instance), and V8 reuses the map transition when an accessor is defined with the same getter, so every instance of a site shares one hidden class and stays in fast mode (%HasFastProperties true, %HaveSameMap true across instances). The runtime needs no change: merge/omit/ssrElement/spread already walk plain objects, and this is one — just a fast one.

Numbers (Node 26, ns/op, min of 7×200k; same 4-key site)

	literal	Proxy form	own-accessor class
fast-mode	no (dictionary)	yes (target)	yes
structuredClone	ok	throws	ok
construct	175	11	100 (0.57×)
construct + read once (SSR shape)	186	68	110 (0.59×)
read ×4 (mono / poly)	16 / 16	64 / 65	12.5 / 13
Object.keys	41	709	4.1
for…in	59	796	5.6
{...o}	301	1077	33
Object.keys + read each (a consumer's walk)	111	770	25
"x" in o	7	24	6
getOwnPropertyDescriptor	9	136	8.5

Enumeration is 10× faster than the literal, not slower: a fast-mode object has an enum cache; a dictionary-mode object rebuilds its key list every time.

Scaling, construct + read all keys once, N getters + 2 data props: N=1 159 → 76 ns (0.48×), N=2 256 → 132 (0.52×), N=4 375 → 249 (0.66×), N=8 674 → 520 (0.77×). Each own accessor is one defineProperty runtime call (~45 ns; __defineGetter__ is ~30 ns if we ever want the legacy form), so the construction advantage narrows with getter count — still a win at every N measured, but this is the one axis where the Proxy form (11 ns) was better, and the trade is deliberate.

Heap per retained instance (200k, isolated processes): N=2 680 → 56 B, N=4 840 → 56 B, N=8 1544 → 56 B (the Proxy form: 96 B). The literal pays a dictionary backing store plus a closure per getter; the class instance holds its data fields and one private slot, with the accessors in the shared hidden class, so the size does not move with getter count. That is the "27× memory" from the opening comment, obtained without a Proxy.

Semantics

Identical to the literal with one edge: the shared getter reaches captured locals through this.#m, so a raw descriptor copy — Object.defineProperty(other, k, Object.getOwnPropertyDescriptor(props, k)) — throws a private-field brand TypeError when other.k is read, where the literal's closure would have worked. Solid's own mergeProps/splitProps (1.x and 2.x) read through the object rather than copying descriptors; the survey should count how often library code copies a props descriptor. Capture rules are unchanged from the per-site proposal above (the field is a snapshot; a reassigned let falls back to the literal), and the fallback rate stays ≤0.4% in library code.

Corrections to the record

• "Object.defineProperties is too slow" (opening comment) was true of the single-call form — 183 ns, slower than the literal — and I generalized it wrongly. Per-key defineProperty with a shared, static descriptor object is 45 ns a call, and that is what makes this work.
• The Proxy form's enumeration cost was estimated at 3–5× in discussion; it is 13–17×.

Plan

1. In-harness verification: the same post-pass method as the spike above (rewrite yak-bench's bundled SSR entry, byte-identical HTML on all 15 cases, CPU-µs + scavenges interleaved) with the own-accessor form instead of the Proxy, no runtime change at all — confirms the microbenchmark survives layered polymorphic reads the way the Proxy spike did not.
2. Compiler emission, Babel then oxc, SSR first. Because the object is a normal fast object, client emission is a code-size question (a class and N static descriptors per site vs a literal), not a semantics one — and the per-component-instance memory is a client win too. Separate decision, its own measurement.

— Claude via Cursor

[ryansolid]

In-harness: the own-accessor class reproduces the branded-Proxy result — with no runtime change and no Proxy.

Same method as the spike two comments up: a post-pass over yak-bench's bundled SSR entry (post-#3514 baseline, lanes/ region only, runtime untouched) rewriting every component props literal into the own-accessor class form described above. 42 sites, 42 rewritten, 0 fallbacks (1.86 getters and 1.14 captured locals per site); all 15 cases render byte-identical HTML against baseline, hydration keys included. Interleaved, 8 reps, CPU-µs per render (process.cpuUsage) and scavenge count at a fixed 1 MB semi-space.

case	cpu/render (median)	min	scavenges
polymorphic-chain (n=400)	3462 → 1783 µs (−48.5%)	3367 → 1617	1519 → 1146 (−24.6%)
tabs (n=150)	4334 → 3658 µs (−15.6%)	4182 → 3493	1725 → 1524 (−11.7%)
multifile-composition (n=150)	4346 → 3663 µs (−15.7%)	4209 → 3445	1704 → 1513 (−11.2%)

That is the "with the brand" table (−48 / −14 / −14) within a point — and nothing was branded. yak's Object.keys(props) in createStaticComponent runs unchanged against a fast-mode object; merge/omit/ssrElement walk it as the plain object it is. The dictionary-mode diagnosis holds: the win was never the Proxy or the brand, it was getting the props object out of dictionary mode, and this form does that while keeping every own-key semantic of the literal.

Conclusion for finding 2: a compiler-only change. No SOURCE_PROPS kind, no runtime brand, no keys() API, no ecosystem guidance. The Proxy plan and its runtime preconditions above are withdrawn in full.

What remains to vet before emission, all compiler-side: the per-site capture rules (unchanged from the survey; ≤0.4% library fallback), the descriptor-copy edge noted above (this.#m in a copied getter throws), key order (creation order must follow source order — the post-pass interleaves this.k = … and defineProperty to keep it), and client emission as a code-size question.

Emission sketch, from the post-pass output:

class _P1 {
  #props;
  static $d0 = { get() { return { transform: `translateX(${this.#props.translateX}px)` }; }, enumerable: true, configurable: true };
  static $d1 = { get() { return this.#props.children; }, enumerable: true, configurable: true };
  constructor(c_props) {
    this.#props = c_props;
    Object.defineProperty(this, "style", _P1.$d0);
    Object.defineProperty(this, "children", _P1.$d1);
  }
}
var TranslatedDot = props => Dot(new _P1(props));

A method prop (ref(r$) {…}) stays a per-instance arrow assigned in the constructor rather than a shared function: consumers call it detached (applyRef(r, el)), so it cannot depend on this.

— Claude via Cursor

[ryansolid]

Emission decision for finding 2: one class shape, one target fallback.

Default (target ≥ ES2022) — the own-accessor class exactly as measured above: captured locals in a private field, descriptors as static fields inside the class body (a private name is only valid lexically inside the class, so the descriptors live there):

class _P3 {
  #m;
  static $d0 = { get() { return this.#m.class; },    enumerable: true, configurable: true };
  static $d1 = { get() { return this.#m.children; }, enumerable: true, configurable: true };
  constructor(m, d0, d1) {
    this.#m = m;
    this.role = d0;
    this.onKeyDown = d1;
    Object.defineProperty(this, "class", _P3.$d0);
    Object.defineProperty(this, "children", _P3.$d1);
  }
}
var Tabs = props => TabList(new _P3(props, "tablist", handleKeyDown));

Single target fallback (target below ES2022, or an explicit opt-out) — the same class with the private field replaced by a symbol-keyed field, and the descriptors as module-level consts beside the class (no static-field syntax):

const $m = Symbol();                         // one per module
const _P3$d0 = { get() { return this[$m].class; },    enumerable: true, configurable: true };
const _P3$d1 = { get() { return this[$m].children; }, enumerable: true, configurable: true };
class _P3 {
  constructor(m, d0, d1) {
    this[$m] = m;
    this.role = d0;
    this.onKeyDown = d1;
    Object.defineProperty(this, "class", _P3$d0);
    Object.defineProperty(this, "children", _P3$d1);
  }
}

ES2015 floor (Chrome 49 — the no-Proxy TV runtimes the SUPPORTS_PROXY paths already serve), identical speed and hidden-class sharing (a plain field store, measured the same as the private field). The one observable difference is that the slot is an own enumerable symbol: {...props} and Object.assign carry it, Reflect.ownKeys lists it, merge's enumerable-key walk includes it (#2769). Shape noise, not a behavior change, and strictly better for those users than the dictionary-mode literal.

Not chosen: today's literal as the target fallback (worse on every measured axis for exactly the users who would get it), and a third slot variant (a non-enumerable symbol via defineProperty: an extra runtime call that costs half the construction win).

Per-site literal fallback remains as the correctness fallback only — a capture the class cannot snapshot (a let reassigned after the site, this/arguments in a getter, a spread inside the literal). ≤0.4% of library sites and 2–4% in app code, per the survey above. A per-site axis, independent of the target.

Runtime: no change in either form. The compiler PR (Babel then oxc, SSR generate first) carries the yak-bench byte-identity check as its acceptance test; client emission is a separate, later decision on code size.

— Claude via Cursor

[GabbeV]

Is there any advantage to it being a class left at this point or could it just as well be a object literal again just using Object.defineProperty with reused configuration objects?

[ryansolid]

Client half of the props-class spike (same post-pass as the SSR spike, applied to yak-bench's Chromium bundle; solid-mprim lane, Solid at the rc release, 42/42 sites rewritten, 0 fallbacks).

Three lanes served round-robin by the existing Playwright bench (4× CPU throttle, fresh page per sample): baseline literal client + literal SSR; class client + literal SSR; class client + class SSR. The SSR HTML of the class lane is byte-identical to baseline across all 15 cases, and the class-client-over-literal-SSR lane hydrated with no mismatch/reuse warnings — so client and server emission can diverge freely; hydration parity is about DOM shape, not the props object's shape.

Time — neutral. Broad run (15 cases, 15/11 samples) put the class lanes at 1.02–1.06× geomean, but the two class lanes serve byte-identical bytes and differed from each other by 4%, i.e. that spread is the noise floor. Focused re-run on the six component-heavy cases at 31 hydrate / 21 mount samples:

case	hydrate base → class	mount base → class
tabs (150)	67.9 → 68.4 (1.01×)	44.5 → 44.9 (1.01×)
polymorphic-chain (400)	53.8 → 54.4 (1.01×)	36.1 → 37.8 (1.05×)
multifile-shop (400)	100.1 → 99.1 (0.99×)	60.4 → 60.4 (1.00×)
realistic-button (1000)	62.9 → 61.9 (0.98×)	43.1 → 40.7 (0.94×)
btn-variant (1000)	39.5 → 39.7 (1.01×)	26.6 → 26.9 (1.01×)
compose-6 (1000)	14.8 → 15.0 (1.01×)	7.5 → 7.4 (0.99×)
geomean	1.00×	1.00×

The construction/read win that shows on the server does not surface on the client: props-object work is a small share of hydrate/mount next to DOM claiming and effect setup, and the larger script (parse/compile of 42 classes, Object.defineProperty builtin calls in cold code) eats what is left.

Retained heap — modest win on component-heavy pages, fixed cost everywhere. Forced GC after hydrate, minus the no-script page for the same markup, min of 3:

case	base	class	Δ
polymorphic-chain	4324 KB	3829 KB	−11%
multifile-shop / product-grid	8475 / 8440 KB	7889 / 7856 KB	−7%
tabs / multifile-composition	5300 KB	4992 KB	−6%
dyn-inline	2692 KB	2548 KB	−5%
realistic-button	5586 KB	5439 KB	−3%
button-variants, compose-* (no component-props sites exercised)	~908 KB	~977 KB	+70 KB

The +70 KB is the per-site fixed cost the literal form doesn't have: class declarations are evaluated at module init (constructor, prototype, static descriptor objects and their getter closures exist whether or not the site ever runs), plus the larger source. ~1.7 KB/site here. It is amortized only when a site is instantiated many times — which these workloads do (n = 150–1000 per site) and real apps mostly don't.

Bundle size (spike emission, untuned). Whole bundle 84.2 → 93.5 KB min (+11%), 29.8 → 30.7 KB gzip (+3%). App code alone 13.9 → 23.1 KB min (+67%), 3.7 → 4.6 KB gzip (+26%): about +220 B min / +23 B gzip per call site. A compiler emission with a shared defineProperty helper and descriptor factory would roughly halve that; it does not go to zero.

Decision: the class form is a server-side change only. On the client it is time-neutral, ships more bytes, and its memory win is small and conditional on high instance counts per site. Emission lands in generate: "ssr"; DOM output keeps today's literal, which hydrates fine against class-built SSR markup.

— Claude via Cursor