Ask HN: Should browsers natively support React-like UI patterns?

3 points by xfr 238 days ago | 1 comment

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 237 days ago |

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(`
      <div>
        <p>Paragraph to inject into shadow DOM.
          <button onclick="alert('You clicked the button with value ${state.key}!')">Click me</button>
        </p>
        <script src="path/to/a/module.js" type="module"><\/script>
        <p data-id="${state.key}">Para with <code>data-id</code> attribute with value <code>${state.key}</code></p>
      </div>
          `)
        }
      })
    });

(where `setHTML` is the pending API here, the navigation API available in chrome, and polyfill available for firefox/safari)

Yes this use of just setting a string is not giving all the nice things like diffing and all... but, we have then a state API tied to the browser navigation, along with a way to know the navigation was successful:

    await navigation.navigate("/somewhere", { state: { key: "value } }).finished;

Flipping things around a bit gives the power back to the browser like it seems you're after, rather than reaching for every tool available... but, a standard JSX feels a while away... maybe expressing JSX just for pure DOM elements would be enough though, without any functional components, but I guess that is what makes JSX, JSX.