[themerone]

Have is a nice language, but it doesn't live up to it's promises.

It's really cool that it can compile itself to a bunch of different languages, but the API isn't consistent enough for complex applications to work with all of its backends.

[jeremyfa]

Standard library is not that bad. It makes sense that there are inherently differences between, say, JS/Web runtime and native/C++ system platforms. Haxe does provide relevant cross platform API when available: file system access, threading etc...

[_vya7]

That kind of makes sense for a lowest common denominator.

Then what is it good for? Just simple apps?

[chii]

it's good for apps that don't have _that_ much platform specific parts, but have lots of application logic. Such as games.

It's an OK language for backend server - esp. if you also have a frontend client in the same language (such as the game and the multiplayer server backend).

[captn3m0]

Does it have WASM support yet? That might be a good fit.

[chii]

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.

[gr4vityWall]

> Then what is it good for? Just simple apps?

It fits the niche of people who have legacy applications written in Flash, and want to rewrite them in a modern stack. There's a battle tested, free, cross-platform implementation of the Flash API called OpenFL. For people who were familiar with that stack, Haxe offers a natural path to migrate.

So, tl;dr its typical use cases are game development and making legacy Flash projects maintainable.

The C++, JS and Hashlink VM targets are generally well maintained. The situation with libraries is meh, mostly due to being a not-so-mainstream programming language that is almost 20 years old. So, there are a lot of libraries that weren't updated in a decade. Some of them may work on new Haxe versions, some won't. Some have been consistently maintained for very long, but are a one man show and the documentation is often subpar. Ceramic is one of such libraries, although the documentation for it is better than the usual for Haxe, IMO.

Overall I find the language itself amazing and pleasant to use. Kinda wish the C# target was still a thing with first-class support, so we could enjoy their hot reloading.

[alok-g]

Besides OpenFL, there is also HaxeUI. Any experience with that? Thanks.

[gr4vityWall]

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.

[alok-g]

Thanks for a detailed note sharing your experience. Very informative.