[exogen]

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?

[zelphirkalt]

But it is not really XML like syntax, is it? It is still a string, even if a template string or whatever it is called, no?

That still leaves the door open for XSS. A good (proper?) (e?)DSL would have the things that make the DOM as keywords in the language, and then we could ensure, that things which should merely be a text, are really only rendered as text, not injected DOM nodes. And the next failure is, that this DSL that is jsx needs to rename HTML attributes, because of overlap with JS keywords like "class". It lacks the awareness of context and therefore is not truly like HTML, no matter how hard it tries to be. It also comes with hacks like "<>" or fragment.

Overall it is usable, but not a particularly well made DSL. It might be as good as it gets with JS.

For inspiration check SXML in various lisps, which comes with immunity to XSS and which works just like the rest of the language, can be structurally pattern matched upon and iterated through, like a proper tree structure.

[exogen]

> 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';

> It also comes with hacks like "<>" or fragment.

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 ;)

[nananana9]

You're clearly well-traveled, but it's unfortunate that none of the frameworks you listed follow the only UI paradigm I actually find enjoyable to work with.

Look Immediate Mode UIs when you have some time to kill. It's a famous paradigm in videogame UI development, so unfortunately most publicly available IMGUI libraries are tailored for use in game engine editor tooling (not very style-able, simple layout algorithms and assumption that they're running in a 60FPS loop), but they're still a good place to look at, to get a general idea. The most famous library is Dear ImGui [1]

The biggest advantage of the immediate mode approach is that you get UI/state syncing for free without having to manage any callbacks/getters/setters/magic properties. It introduces new problems (widgets are now defined implicitly and you need a system for keeping track of them over time), but they're way easier to solve than the UI/state sync issue.

Examples of real-non-video-game software that uses it are File Pilot [2] and RAD Debugger [3], which are modern desktop UI applications with all the modern desktop UI application bells and whistles.

[1] https://github.com/ocornut/imgui [2] https://filepilot.tech/ [3] https://github.com/EpicGamesExt/raddebugger

[exogen]

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.)

[throwaway243123]

Whoa backbone, ember, knockout, what throwbacks right there.

[MarcelOlsz]

Will I ever wake up in a world where Vue is not slept on?

[snickell]

I would much rather use Vue than React too. That said, from a bird's eye view, I would say they're siblings. In a way I would say that Vue inherits the "react approach", and does it much (much) better, but its also not a fundamentally different approach.