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

But while working on large enterprise applications with data-heavy interfaces, dashboards, and complex grids using frameworks like Sencha Ext JS, I started noticing something:

But while building large enterprise applications, I noticed something interesting:

The browser itself was rarely the bottleneck.

The expensive part was often everything happening before the browser update:

• virtual tree creation
• reconciliation
• diffing
• rerender propagation
• memory allocation

So I started building a UI framework that avoids the Virtual DOM entirely.

Instead of rerendering component trees, the framework uses direct reactive bindings.

When state changes:

• only affected bindings update
• only impacted DOM nodes change
• no component diff cycle runs

The architecture is heavily focused on:

• fine-grained reactivity
• deterministic updates
• low memory overhead
• minimal rerendering
• direct DOM targeting

What improved most:

• large tables and grids
• real-time dashboards
• deeply nested interfaces
• memory stability during long sessions

But removing the Virtual DOM also exposed hard problems:

• lifecycle cleanup
• async update ordering
• reactive debugging
• dependency tracking
• dynamic keyed lists

One major takeaway:

Modern browsers are already very good at DOM rendering.

The bigger challenge is reducing unnecessary work at the framework layer.

I don’t think the Virtual DOM is “bad.”

I just think frontend architecture is evolving toward more precise update systems.

Signals, compiler-driven rendering, and direct reactivity all point in that direction.

Would love to hear how other engineers think about this shift.