Haxe is a fun language. It could have taken TypeScript's place, if they focused on improving the tooling and ergonomics for Web developement instead of game development 15 years ago.
It was heavily inspired by ActionScript 3 which was the basis for the EcmaScript 4 proposal abandoned around 2008 iirc.
We could have had something close to TS running natively in the browser 17 years ago.
What we really needed was Flex or XAML or Swing or even XUL, for that matter, to be built on a sandbox functional enough to make users happy but robust enough to run on the web. Instead each framework failed in turn to various platform dependency and/or security flaws until we ended up stuck with the DOM as our endgame.
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.
And yet we're drowned in build tools, configs, and whatnot to use TS because JS is not sufficient to write sophisticated client-side apps.
Even if there was something like XAML you'd still need a typed language.
What's interesting is
- surely it's inspired by actionscript (Flash) because it has a flash-compiler-predesscors, MTASC (Motion-Twin Actionscript Compiler), which was slightly faster than native flash! (slightly more optimized code)
- you may recognize that name, Motion Twin... this guy was their compiler guy, but this was a Flash games company.. still around today, some of you may have played their multi-platform game, "Dead Cells"
themerone•7mo ago
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.
_vya7•7mo ago
Then what is it good for? Just simple apps?
chii•7mo ago
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•7mo ago
chii•7mo ago
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•7mo ago
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•7mo ago
gr4vityWall•7mo ago
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•7mo ago
jeremyfa•7mo ago