The change I expected to be free (or a win)​

The DOM renderer builds a subtree with an iterative depth-first walk. Each node the walker touches used to allocate three short-lived objects:

• the traversal frame ({schema, parent, index, …}),
• a context object ({element, scope}) threaded to that node's children,
• and a {context, children} wrapper returned by the visitor.

I collapsed that. The visitor stopped returning a wrapper and started writing onto the frame directly, and I merged the context into the frame too — so element and scope became fields on the walk node itself:

// before: visitor returns a fresh wrapper + context object per node
return { context: { element, scope }, children };

// after: visitor writes onto the node it was handed
node.element = element;
node.scope = scope;
node.children = children;

Three allocations per node became one. On a ~1200-node tree that is ~2400 fewer short-lived objects per build. Obvious win, right?

The measurement said no​

I ran a controlled A/B: the old build path and the new one, same tree, same machine state, interleaved sample-by-sample with a forced GC before each sample, reporting the full spread (not a single median).

             min     p25     median  p75     max     [ms/mount]
OLD    :   0.820   1.060   1.100   1.160   2.180
NEW    :   0.900   1.160   1.220   1.280   2.440
Δ median (NEW vs OLD): +10.9%  → NEW slower

Fewer allocations, 11% slower. And note the shape of it: the slowdown is uniform — min moved +9.8%, median +10.9%, max +11.9%. That detail is the whole diagnosis.

Reading the shape​

A regression that lives only in the tail (p95/max) usually means GC — occasional pauses inside the timed region. But this shifted the min too. The cleanest, GC-free sample got slower. That can't be GC; it's more CPU on every single node. So the extra work had to be per-node, systematic, and small.

Which is strange, because I removed work (two allocations). Where did per-node CPU appear?

The cause: V8 sizes properties at birth​

V8 decides how many in-object property slots an object gets when it is created, from the shape of the literal. An object born as {schema, parent, children} gets room for exactly those three, stored inline and accessed by a fixed offset.

The new visitor then added element and scope after creation. Each addition:

1. drives a hidden-class (map) transition, and
2. once the object outgrows its in-object capacity, spills the overflow into a separate out-of-line property store — an extra allocation, and every later read of element/scope now goes through an indirection.

So I didn't remove an allocation for free. I traded a cheap one (a young-generation object the scavenger reclaims almost for nothing) for a slower object representation on all 1200 nodes. The old code, by contrast, built every object as a complete literal — all fields present at creation, everything in-object, no post-hoc growth. More objects, but each one cheap and flat.

The lesson in one line: growing an object field-by-field is not the same cost as allocating it whole — even when "whole" means allocating more objects.

The proof (and the fix)​

If the diagnosis is right, then giving the node all its slots at birth — so the visitor only writes into existing slots — should erase the gap without giving back the allocation win. It did:

             min     p25     median  p75     max     [ms/mount]
OLD          :   0.840   1.000   1.060   1.100   1.340
NEW (pre-sized): 0.780   1.020   1.080   1.120   1.280
Δ median: +1.9%  → tie (within noise)

Back to parity — and the pre-sized version actually beats the old code on min and max, while still allocating one object per node instead of three. Hypothesis confirmed, not asserted.

The shippable form keeps core generic: walkSchema doesn't know DOM field names, so the caller supplies the node factory and is responsible for pre-declaring its own context slots:

// in the DOM renderer — node born with every slot the visitor will fill
const createBuildNode = (schema, parent) =>
    ({ schema, parent, children: undefined, element: undefined, scope: undefined });

walkSchema(root, visit, createBuildNode);

What I'm taking away​

• "Fewer allocations" is not automatically faster. Object representation (in-object vs. spilled backing store) and hidden-class transitions can dominate the allocation you saved — especially when the saved object was a cheap young-gen one.
• Build objects complete. One literal with every field beats creating a small object and growing it. Give V8 the final shape up front.
• The shape of a regression names its cause. Tail-only → suspect GC. min moved too → per-operation CPU. Look at the whole distribution, never a lone median.
• Only a controlled A/B tells the truth. The same change looked like anything from +8% to +18% against a third framework across runs — pure cross-run noise. Old-vs-new, one machine, interleaved, GC'd, was the only measurement that didn't lie.

The refactor shipped: the cleanup stayed, the allocation count dropped, and the build is no slower than before — because the node is now born whole.

The Problem: Runtime Type Checking Kills Performance​

Traditional frameworks mix all props together:

// React/Solid approach - looks simple, but...
<div id="static" onClick={handler} items={list}>

Behind the scenes, the framework must check EVERY prop:

// What frameworks do internally
for (const prop of props) {
  if (isEvent(prop)) handleEvent(prop);
  else if (isReactive(prop)) setupReactivity(prop);
  else if (isList(prop)) setupListTracking(prop);
  else setStaticProp(prop);
}

The Cost Adds Up​

Consider a typical app with 10,000 elements and ~5 props each — roughly 50,000 prop reads. In a runtime-dispatch model, each read asks the same question ("is this reactive? an event handler? a plain attribute?") and does it on every render cycle. Any single check is trivially cheap; the point is that it's work you keep paying. Exodra pays it once, at compile time, and never again at runtime.

Death by a thousand cuts.

Our Solution: Three Attributes Architecture​

We explicitly separate attributes at compile time:

// Exodra approach - explicit and fast
<div 
  static={{ id: 'container', class: 'box' }}
  bindable={{ onClick: handler }}
  bindableList={{ items: list }}
/>

Zero Runtime Checks​

With Three Attributes, the runtime knows exactly what to do:

// Static attributes - set once, never check again
if (attributes.static) {
  Object.assign(element, attributes.static);
}

// Bindable attributes - set up reactivity
if (attributes.bindable) {
  setupBindings(element, attributes.bindable);
}

// Lists - optimize for array operations
if (attributes.bindableList) {
  setupListBinding(element, attributes.bindableList);
}

No type checking. No guessing. No overhead.

Performance Impact​

We don't ship a "runtime-type-checking" variant of Exodra to A/B against, so we won't quote a made-up "with checks vs without" delta. What we can show is how the architecture holds up against other reactive frameworks.

In the project's benchmark suite (npm run bench), rendering a large tree — the case that actually does work at a measurable scale — Exodra lands in the top tier: as fast as the fastest (neck‑and‑neck with Solid, well ahead of React and Svelte) without a memory premium. Full numbers, including retained heap and honest caveats, live on the dedicated Benchmarks page — with the fair print that Solid's memory footprint is actually a touch smaller than ours. We're not claiming a permanent "fastest" crown from our own harness.

Fine-grained updates (a single signal or list op) complete in sub-millisecond time for both Exodra and Solid — below the timer's resolution — so we treat those as a tie, not a headline multiplier.

Caveats worth stating plainly: this is Exodra's own harness (headless Chromium via Playwright), not an independent benchmark, and numbers move with hardware and framework versions. Run npm run bench and see for yourself. The point isn't "we win every micro-benchmark" — it's that pre-separating props at compile time removes a class of per-update work, and that shows up on real render workloads.

Why Not Just Use a Compiler?​

"Why not let a compiler figure this out?"

We do! Our Babel plugin transforms JSX into Three Attributes. But here's the key: the runtime still knows the separation.

Other frameworks compile to a mixed format and still need runtime checks. We compile to a pre-separated format that needs zero runtime decisions.

Developer Experience​

Yes, it's more verbose. But it's also:

1. Explicit - You know exactly what's reactive and what's not
2. Predictable - No surprising re-renders from static props
3. Debuggable - Clear separation in DevTools
4. Fast - Measurably, significantly faster

The Philosophy​

We believe developers should control performance, not hope for it. By making the cost visible, we make it avoidable.

Every bindable prop is a conscious choice. Every static prop is a performance win. Every bindableList is optimized for its specific use case.

Real-World Impact​

We won't quote before/after figures from a "production app" you can't re-run — that's how you end up trusting invented numbers. What you can run is the benchmark suite: npm run bench renders a large tree, and Exodra lands in the top tier in our harness — on par with Solid, ahead of Svelte and React (hardware/version dependent). The architectural claim doesn't hinge on the exact figure: pre-separating props at compile time removes a category of per-update work, and that shows up on real render workloads.

Conclusion​

The Three Attributes Architecture isn't about following trends or making things "simple." It's about giving developers the tools to build genuinely fast applications.

We didn't want to drag type checking everywhere. So we didn't. We separated attributes at the architecture level, eliminated runtime overhead, and gave you maximum performance.

The cost of clarity is verbosity. The reward is speed.

The Problem with Legacy Core​

The legacy core relied on manual cleanup and reference counting:

// Legacy approach - manual disposal required
const nodeData = {};
function dispose(node) {
  delete nodeData[node.id];
  node.children.forEach(dispose);
}

This approach had several issues:

• Memory leaks when developers forgot to call dispose
• Performance overhead from manual tracking
• Complex lifecycle management in dynamic UIs

Enter WeakMap Core​

WeakMap provides automatic memory management:

// WeakMap approach - automatic cleanup
const nodeCache = new WeakMap();
// When node is GC'd, WeakMap entry is automatically removed

Why This Is a Design Win (Not a Benchmark Claim)​

We're going to be honest here: Exodra does not ship a maintained "legacy vs WeakMap" microbenchmark, so this post won't quote a measured "X% faster" delta — doing so would be inventing numbers. The case for the WeakMap core is architectural, and it stands on its own:

• Node creation avoids allocating a per-node bookkeeping object and wiring up manual parent/child tracking — there's simply less work per node.
• Memory after unmount is reclaimed by the garbage collector: when a subtree's nodes become unreachable, their WeakMap entries go with them. There is no retained-metadata table to grow or forget to clear.
• Cache lookups (clone-caching static subtrees) are a direct WeakMap get keyed by the schema node — no scanning, no auxiliary index.

If you want real, reproducible numbers, run the cross-framework suite with npm run bench: on a large-tree initial render Exodra lands around ~1 ms median — top-tier in our harness (neck-and-neck with Solid, ahead of Svelte and React). Those are Exodra's own benchmarks and are hardware/version dependent — reproduce them yourself rather than trusting a marketing figure.

Real-World Benefits​

1. Caching & Reusability​

WeakMap enables powerful caching patterns:

const compiledTemplates = new WeakMap();
function getTemplate(node) {
  if (!compiledTemplates.has(node)) {
    compiledTemplates.set(node, compile(node));
  }
  return compiledTemplates.get(node);
}

2. Zero Memory Management​

No dispose, no cleanup, no leaks:

• Components unmount → references drop → memory freed
• WeakMap automatically cleans up entries
• No manual intervention required

3. Steady Performance at Scale​

Because there's no manually-managed metadata table accumulating over an app's lifetime, per-update cost doesn't drift upward as the app runs — freed nodes are collected, and there's no growing structure to walk. This is a property of the design, not a number we're quoting from a synthetic 50k-update loop.

Why It's a Better Model​

The WeakMap core wins on properties, not just speed:

1. Separation of concerns: memory management is handled by the runtime/GC
2. Hard to leak: you can't forget to clean up what you never manually manage
3. Cache-friendly: a natural fit for memoization and clone-caching
4. Steady at scale: no manually-grown metadata table to drift with app size

Conclusion​

The WeakMap core is an architectural improvement in how Exodra manages memory: it removes per-node bookkeeping and the whole "did I remember to dispose?" class of bugs. We're framing it as a design win rather than a benchmark headline on purpose — for numbers, npm run bench is the honest source.

Bottom line: the WeakMap core does less work per node, leans on the GC for cleanup instead of manual disposal, and makes clone-cache lookups a direct keyed get. The win is that it's hard to misuse and easy to reason about — and for actual, reproducible timings, npm run bench is the source of truth, not this post.