What if:

1. JS supports JSX literals so

   let elDef = <div id="some">Text</div>;

will be compiled into

   let elDef = ["div", {id:"some"}, ["Text"]];

2. We extend DOM API to accept such constructs:

   element.append(elDef);  // same thing as element.append("<div id=some>Text</div>");
   element.prepend(elDef); // ditto
   element.patch(elDef);   // patch element's DOM by elDef

3. Add appropriate events: componentDidMount, componentWillUnmount, etc. for cases when tag in JSX (uppercased) resolves to a class or function.

4. Add render() support. A method that generates tree of elDef's. It gets called by append(),prepend() and patch().

And we will get native React implementation. This will be quite useful and allowed to marry React alike approach with WebComponents into single mechanism.

1...4 is how it is implemented in my Sciter as the Reactor thing, see: https://docs.sciter.com/docs/Reactor/

If you are making it native to the browser, why have a "virtual DOM" "definition language" middleman and not just jump straight to real DOM, the browser's existing bread and butter?

  let ele = <div id="some">Text</div> // ele is now HTMLDivElement

Doing that `element.append(ele)` just works with existing DOM APIs.

Instead of supporting classes and functions in browser-supported JSX with their own life cycle model, you can just require registered Web Components and reuse existing Web Component life cycles.

I think if Browser-native JSX support were to happen it should probably either be real DOM or remain a function tree so that at least some tree operations can be amortized by the function compiler.

Which is that most JSX is actually compiled to nested calls like:

    let elDef = jsx("div", {id:"some"}, "Text", jsx("div", {id: "inner"}, "Text2"), ...otherChildren)

The `jsx` function can potentially avoid some future tree walks/recursion by the nature of being unrolled by the compiler into nested calls instead. That's a useful property lost in trying to agree on a single virtual tree definition. It's also one maybe unnecessary if just relying on real DOM trees, because browsers have their own optimizations for DOM tree walking.

> On most platforms it's quite easy to embed a browser in a frame

Citing other answer here "This is a common misconception among programmers, and is actually the opposite of the truth."

If platform is Windows then you need three different mechanisms for doing so, depends on OS version. And be ready to the fact that it can be no browser installed in standard way.

And if platform is Linux... Good luck with that in general... GTK may help here but be ready to GTK2/GTK3/GTK4 zoo. And sure you will not be happy with performance of the result.

> There is no real alternative.

Not sure if my Sciter qualifies as a native solution.

Check this chat alike virtual list with MD items: https://sciter.com/wp-content/uploads/2026/05/virtual-list-m...

Yes, MD gets translated to DOM tree. But virtual list implementation in Sciter is a native thing. Load whole chat is not an option usually. Yes, JS is used in process but mostly as a configuration option: take output of one native function -> transform it -> pass as an input to other native function.

Essentially there is no so significant difference with any other SwiftUI/TextKit solution. It is just a difference in terms - SwiftUI uses tree of Views that is conceptually the same as DOM tree in terms of Sciter.

> Is there a good reason browsers could and or should not support ts out of the box?

Yes, there is a reason. Most critical requirement for the "language-behind-web-UI" is to be efficiently parseable (parsing speed and memory). So it should have one-pass compiler/interpreter without the need of building AST (syntax tree). Speed of execution and type strictness is on the third and tenth places correspondingly.

JS matches that basic requirement but TS is not.

There are proposals with some traction that would enable webbrowsers to parse TS, but simply ignore the types. I think it's a bad idea, because tooling handles that perfectly well and I think browsers should generally avoid building functionality that could be equally well provided outside it, but I guess enough people have been asking for it, so it might happen.

> lack of browser engine implemented basic UI elements as default HTML.

I'd argue that browsers already have full set basic UI elements.

But the thing is that "basic set" is different for each developer / site and that is OK.

Attempt to make a browser to include everything is a path nowhere. Today we have carousel as the thing, tomorrow something else.

That's the moving target. And don't forget about versioning. Each feature has to have a fallback:

   <carousel>
      ...
   </carousel>  
   <nocarousel>
      ...
   </nocarousel>

Old browsers and old machines are still there.

Instead we should have really handy component system like

   <section class="carousel">
      ...
   </section>  

   <style>
      section.carousel {
        controller: Carousel url(/js/carousel-desktop.js); 
      }
      @media handheld { 
        section.carousel {
          controller: Carousel url(/js/carousel-mobile.js); 
        }
      }  

    </style>

USSR at big extent was there too.

Like OGAS[1] - a unified economic management system. The idea was simple yet technocratically rational: if the system has enough sensors and effectors on society then it can reach a maximum of satisfaction for the society as a whole (with the given set of common resources).

[1]https://museum.dataart.com/short-stories/ogas-the-red-bit-sy...

Yeah, that's definitely needed.

That's why I've added Graphics.Text (https://docs.sciter.com/docs/Graphics/Text) in Sciter.

Graphics.Text is basically a detached <p> element that can be rendered on canvas with all CSS bells and whistles.

It is not. Not to that extent at least.

I am developing Sciter[1] engine that works on all desktops: Windows, MacOS, Linux (3 distinct backends: pure X11, pure Wayland and GTK4).

Among all those, Windows API is still the most consistent and stable.

Whole of Windows functionality can still be accessed by plain C. For some things (COM) is better to use C++ but C works too.

Just in case: I am in this business for 20+ years.

[1] sciter.com

> cross platform GUIs are ugly by default,

... was said reading it in a browser on who knows what OS/DWM.

I mean that 90% (if not more) of all UI interactions happen now in a browser or in multi-platform applications (e.g. messengers, SublimeText, VSCode, etc).

WYSIWYG is #1 reason I believe.

Markdown is fundamentally WYSIWYG - you edit something and you get it rendered 1 to 1. Either in plain text (a.k.a. "source") or when it converted to HTML/CSS and then presented.

WYSIWYG requires 1:1 mapping between "source" and "presentation". Markdown is exactly that. While HTML/CSS is 1:N mapping - same presentation can be achieved with many combinations of HTML/CSS rules. That's why "true WYSIWYG" is barely achievable with HTML/CSS.