I Built a UI Framework That Doesn’t Use a Virtual DOM

Introducing Zenith

Over the last few years, I’ve worked extensively with React, Vue, Next, Nuxt, Svelte, and compiler-adjacent tooling. Each of them solves real problems — but they also left me with a recurring question:

What if the compiler already knew everything before runtime ever existed?

That question is what led me to build Zenith.

Zenith is a compiler-first UI framework that intentionally does not use a Virtual DOM, runtime diffing, or reactive boundaries. Not because those tools are bad — but because I wanted to explore what becomes possible when certainty replaces reconciliation.

This post is an announcement, not a sales pitch. Zenith is different by design, and that difference is intentional.

---

Why I Started Building Zenith

Most modern UI frameworks share a common assumption:

UI updates are a runtime problem.

State changes, components re-run, virtual trees are recreated, and the framework figures out what changed after the fact.

Zenith flips that assumption:

UI updates are a compile-time problem.

Instead of asking “what changed?” at runtime, Zenith asks:

“What could ever change?”

…and answers that before runtime exists.

Once that answer is known, there’s nothing left to diff.

---

What Zenith Is (and Isn’t)

Zenith is:

• Compiler-driven
• Structural by default
• Predictable and explicit
• Minimal at runtime

Zenith is not:

• A Virtual DOM framework
• A reactive runtime
• A template engine
• A drop-in replacement for React or Vue

It’s a different axis entirely.

---

A Simple Counter Example

Let’s start with something familiar.

React

function Counter() {
  const [count, setCount] = useState(0)

  return (
    <button onClick={() => setCount(count + 1)}>
      Count: {count}
    </button>
  )
}

This works great — but under the hood:

• The component function re-executes
• A new Virtual DOM tree is created
• React diffs old vs new
• Then updates the DOM

All decisions happen at runtime.

---

Zenith

Zenith enforces a strict separation:

• Behavior lives in <script>
• Markup only declares bindings
• No inline expressions
• No directives
• No runtime interpretation

<script>
  state count = 0

  function increment() {
    count++
  }
</script>

<button onclick="increment">
  Count: {count}
</button>

That’s it.

---

What the Compiler Does

At compile time, Zenith:

• Resolves count as a state cell
• Resolves increment as a function reference
• Determines {count} affects a single text node

• Emits exact instructions:

  • One DOM event listener
  • One direct DOM text update

At runtime:

• The function runs
• State mutates
• The known DOM node updates directly

There is no re-render path.
There is no diffing step.
There is nothing to guess.

---

Why {} Exists in Zenith

In Zenith, {} does not mean “evaluate an expression.”

It means:

“Bind this node to a compiler-tracked value.”

That’s why these are invalid:

{count + 1}
{someFunction()}
onclick={count++}

Those require runtime evaluation — and Zenith rejects them at compile time.

The compiler must be certain, or it fails.

---

Components in Zenith Are Structural

One of Zenith’s core constraints is:

Components do not introduce behavior or reactivity.

They are purely structural transforms.

• No lifecycle hooks
• No hidden scopes
• No reactive boundaries

This allows:

• Slot content to retain its original scope
• State identity to remain intact
• The compiler to reason globally

This constraint is not accidental — it’s what makes the model possible.

---

Why No Virtual DOM?

The Virtual DOM is an elegant solution to a hard problem.

Zenith avoids the problem entirely.

VDOM frameworks:

• Recompute → then optimize
• Recover from uncertainty

Zenith:

• Prevents uncertainty
• Emits intent, not guesses

That’s not “better” — it’s different by construction.

---

Current Status

Zenith is:

• Actively developed
• Compiler-driven (Rust)
• Early, opinionated, and evolving

It’s not production-ready yet — and that’s okay.

Right now, Zenith is about exploring:

• What a compiler can guarantee
• How much runtime can be eliminated
• What UI looks like without reactive boundaries

---

Why I’m Sharing This Now

Zenith started as a question.

It grew into a compiler.

Now it’s a framework.

I’m sharing it early because:

• I value architectural discussion
• I want ideas challenged
• And I believe UI tooling still has unexplored space

If you’re curious, skeptical, or opinionated — that’s exactly the audience I want to hear from.

---

Final Thought

Zenith isn’t trying to replace React or Vue.

It’s asking a different question:

What if the compiler already knew everything?

Thanks for reading — more to come.