xfr

Every major web framework today (React, Vue, Solid, etc.) ends up re-implementing the same ideas in JavaScript: component trees, diffing, and DOM reconciliation. This means every frame of UI work runs through an interpreted, garbage-collected layer that the browser ultimately has to translate back into the real DOM anyway.

I’ve been thinking about what would happen if browsers added native, framework-agnostic primitives for this kind of work. A sort of "WebUI API", analogous to how WebGL and WebGPU expose low-level graphics primitives.

Imagine if the browser exposed a small set of APIs for:

- Creating and updating virtual UI trees natively

- Performing diff and patch operations in optimized C++/native code rather than JS

- Integrating directly with the rendering pipeline (layout, paint, composite)

- Managing component lifecycle hooks and update scheduling

Frameworks like React could detect and use this interface automatically, just like they detect `navigator.gpu` today. This would eliminate a huge amount of JS overhead without "baking React into the web."

In short: treat UI diffing and reconciliation as a first-class workload, not something libraries must implement manually

Has anyone tried to push something like this through WICG or WHATWG? Are there good reasons browsers haven’t done it (besides standards politics)? And what pitfalls do you see in letting the browser handle the virtual DOM natively?