Somewhat familiar with them, but can't say I've ever built anything with them. I'm curious though: are you aware that people already consider React and its cousins to be immediate mode style APIs for the Web? At least, as close as you can reasonably get when your rendering target is the DOM? That's why `UI = f(state)` is so often cited in React literature; components are functions that don't know anything about the "widget tree" or "instances" or anything like that, you always just return the latest output that you want with the data/input you receive, as if you are rendering "from scratch" each time. Components don't really know whether they're "initializing" or "updating" or anything like that, they just know they're "rendering"; React takes care of reconciling that output with the actual DOM.

So, if that's not good enough for you, what would an even more faithful immediate mode API even look like? (And if your idea includes ditching the DOM as the render target, which is inherently "retained mode" and could never be otherwise due to performance and DOM state (like focus), I'm afraid it's a nonstarter.)

https://github.com/jquery/jquery/blob/df16f7360d4db41de64589...

> It is still a string, even if a template string or whatever it is called, no?

No.

> That still leaves the door open for XSS.

The door for that in React is called `dangerouslySetInnerHTML`, but it's extremely rarely used.

> jsx needs to rename HTML attributes, because of overlap with JS keywords like "class"

That's not really inherent to JSX, just React's use of it. SolidJS, for example, uses `class` instead. But in any case – JSX didn't make up those names. Those are the property names on JavaScript's DOM classes. The fact that there's confusion between "attributes" and "properties" is pretty baked-in to the Web platform, even causing confusion in standard Web Components. Every DOM library and framework (even jQuery) has needed to decide whether it's operating on properties or attributes.

    const div = document.createElement('div');
    div.className = 'foo';

The DOM has the same concept, DocumentFragment. How else would you represent e.g. "two sibling nodes with no parent node"?

> It lacks the awareness of context and therefore is not truly like HTML.

On the contrary, I'd argue it has way more context. It knows, and will warn you, if you try to do any DOM element nesting that the HTML spec forbids, for example.

> can be structurally pattern matched upon and iterated through, like a proper tree structure.

You are literally describing the output of JSX. Glad you like it ;)

I'd give people the benefit of the doubt. Personally, having built UI with Win32, WinForms, VisualBasic, Cocoa/Interface Builder, Qt, Tcl/Tk, XSLT, vanilla HTML/JS, jQuery, Backbone, Ember, Knockout, Bootstrap, MooTools, YUI, ExtJS, Svelte, Web Components, and React (including Preact, SolidJS…)… I'll happily choose the React approach. The only other one I would even describe as "good" was Qt.

I also don't get why "XML-like syntax in the JS code" is even a point worth complaining about. If anything, we should be encouraging people to experiment with more DSLs for building UIs. Make your tools suit the task. Who the fuck cares, if it's clear and productive?

It would be possible to have it decode the .dts and .dif formats on demand - that was my original plan - just much less efficient for users, as the .glb files are about 1/5 of the file size on average. (I also assume glTF loading/rendering has had a lot more optimization work put into it than what I'd be able to accomplish.) For these reasons it seemed more productive to have it work on the Blender addons as a starting point rather than JavaScript/TypeScript parsers for the original formats. I still ship the original assets alongside the .glb files (meaning they have URLs just aren't loaded) in case I want to switch it someday.

Some of the custom features you may be referring to I implemented as custom properties in the glTF output - like surface flags. "Outside Visible" is one example, it's a flag baked into each .dif surface that determines whether rays can reach it from the outside, so the engine knows whether to apply the map's directional sunlight, or just ambient and light map lighting. So, even though it technically could try to render with modern PBR, dynamic lighting/shadows and all that, it instead renders as close to the original as possible using the same (or similar) techniques. Comparing screenshots with actual Tribes 2 renders is often indistinguishable unless you really know what to look for!