HACKER Q&A
📣 xfr

Should browsers natively support React-like UI patterns?


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?

  👤 fabiancook Accepted Answer ✓
Do you want just JSX in browsers?

Or do you want a "native virtual DOM".... that is the DOM we have today.

There is various new tools coming available that make working with a browser so much easier.

In the past for example there was no way to do a SPA transition between pages, this was one of the big things handled by the likes of react alongside of the vdoms, but by tooling like react-router for the likes of react. This made it pretty much that you needed to use the likes of react to make state based changes to the DOM.

Now... we have the navigation API where you can have an async change happen on navigate and prevent

Very soon you'll be able to do this:

    navigation.addEventListener("navigate", event => {
      event.intercept({
        async handler() {
          const state = event.destination.getState();
          document.body.setHTML(`
      

        
Paragraph to inject into shadow DOM.