I played with Ceramic a bit and it was nice to have built-in imgui support out of the box.
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.
Shrug. I think this is a good illustration: it’s not the language that’s the issue, it’s the DOM. The DOM was and continues to be a terrible UI abstraction for applications.
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.
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.
>It was heavily inspired by ActionScript 3 which was the basis for the EcmaScript 4 proposal abandoned around 2008 iirc.
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"
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.
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...
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).
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.
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.
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.
Examples on the website are more focused on things that can work directly in the browser, but Ceramic has been used to ship mobile games in production. Pointer events are working on both desktop and mobile platforms by default, with optional multitouch support on mobile if needed.
I played with Ceramic a bit and it was nice to have built-in imgui support out of the box.
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 could have taken TypeScript's place
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.
Shrug. I think this is a good illustration: it’s not the language that’s the issue, it’s the DOM. The DOM was and continues to be a terrible UI abstraction for applications.
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.
Ideas are worth communicating clearly. What does "DOM" mean here? You said XUL, but there was never XUL without the DOM.
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.
> it’s not the language that’s the issue
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.
Firefox and Thunderbird provide a 20+ year old existence proof to the contrary.
>It was heavily inspired by ActionScript 3 which was the basis for the EcmaScript 4 proposal abandoned around 2008 iirc.
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"
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.
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...
That kind of makes sense for a lowest common denominator.
Then what is it good for? Just simple apps?
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).
Does it have WASM support yet? That might be a good fit.
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.
> 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.
Besides OpenFL, there is also HaxeUI. Any experience with that? Thanks.
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.
Thanks for a detailed note sharing your experience. Very informative.
A bit strange that it doesn't have an example of mobile input, the main gaming platform of these days.
Examples on the website are more focused on things that can work directly in the browser, but Ceramic has been used to ship mobile games in production. Pointer events are working on both desktop and mobile platforms by default, with optional multitouch support on mobile if needed.