using the examples listed as being needed (like swing and flex), it would seem that they meant a visual components library that has "everything" needed for an app.

The "DOM" in this case is referring to the basic elements of a html page. It's like bricks, for which an app UI could be built, but it will be different for every app (both visually, as well as code-wise).

The thesis in the poster's remarks is that there should've been a common application GUI library for the web.

Firefox and Thunderbird provide a 20+ year old existence proof to the contrary.

not natively, but because haxe compiles into C++, you can setup a wasm pipeline from that (presumably). Probably not something commonly done so there's no premade tooling for it.

Edit: it seems someone has setup a hello world example of using emscripten to compile haxe into wasm: https://gist.github.com/MatthijsKamstra/cbae06ae1dc3561621e4... - it's not that difficult apparently!? Color me surprised.

I have played with it a bit on side-projects. TL;DR: would not recommend it unless you're building a game or is in unique circumstances. Pick something with a faster feedback loop for development GUIs.

While HaxeUI is usable, you'll be on your own a lot: * Documentation is scarce * You'll likely run into bugs the moment you try to go beyond hello world examples * No promises of regular releases or API stability whatsoever. You're expected to run versions directly from GitHub * wxWidgets backend sometimes segfaults with the examples from its HaxeUI's website * tooling is subpar for GUI apps in Haxe; forget having anything as good as any modern frontend framework with Vite. Hot-reload somewhat works on HashLink, but there's almost no documentation on how to use it.

It's maintained by a very nice dude, who does a good job considering the coverage of his libraries, the fact that he does that by himself, and the fact that the OpenFL-based backends work well. HaxeUI is used in production by a few people who work with the HaxeUI developer.

FeathersUI is another option, with much, much better documentation (probably one of the best for Haxe libraries), but smaller component coverage than HaxeUI. I ran into less bugs with it in general, and the dev seems more focused on consistent, well-tested releases. Also a really nice guy from my experience, just like the HaxeUI dev.

But overall, iteration times of GUI applications is just not good with Haxe. You'll suffer if you are used to modern frontend tooling. The accessibility story is nonexistent. And I'm not sure the performance would even be better than just opening a WebView. Definitely not on mobile.

I would only recommend using those two libraries in three circumstances: * You are building a one-off GUI tool that has a simple interface. Think something like LunarIPS. In that case, you can get something usable pretty quickly which will look good if you don't care about following the native toolkit (don't go the hxWidgets path, it's guaranteed suffering). * You are building some interface which will be used inside a game made with Haxe. Say, a login form inside your multiplayer game. In that case, it makes perfect sense to use one of those two libraries. * Your application, for whatever reason (personal taste included), will have a more game-y UI, and it makes more sense to code it in a game engine than the DOM or Qt or whatever.

A fourth reason that is valid for anything is if you're in a Haxe shop, and want to maintain a single language for all projects. Those places do exist (like Shiro Games).

I think that if I __had__ to build a GUI program in Haxe these days, I'd build a prototype with vanilla JS or React first, iterate on it, and only start a HaxeUI/FeathersUI version later.