Anybody have an opinion on how HaxeUI stacks up against FeathersUI? Why would I choose one over the other?
Howdy,
Its hard to say really, there are a few things that jump to mind that i think differ quite alot with between the two:
-
The most obvious is probably that feathers is an openfl lib and haxeui has a number of backends, one of which is openfl (with the ability technically to create an infinite number of backends, like the text only pdcurses backend). I think there are pros and cons to both of these, for example, feathers doesnt really have to worry about breaking a load of backends with a simple change. It may not seem like a big deal, but it can be quite a burden on maintaining the libs (not that that really matters much to the user of haxeui/backend), on the other hand, if something “just wont work” in openfl, well, you are kinda stuck. This is actually the main reason haxeui is abstract: a long time ago openfl text input was a real problem, wouldnt accept non american key input, etc and a whole lot of other problems. Haxeui was an openfl only lib at that time, and the lack of proper text input essentially rendered my app (and really haxeui version 1) useless, this left a bad taste in my mouth so i wanted to redesign it so there was never any framework lockin again - in the meantime, of course, openfl text input has become alot more bearable.
-
Next it would probably be that, because of the abstraction in haxeui-core, haxeui can create 100% native apps (haxeui-hxwidgets, haxeui-qt, haxeui-android), these to me are really useful backends (as well as haxeui-html, which is
<div/>based dom backed). Generally (and personally) when im writing or using an application i like it to be actually native, not custom drawn - it just usually feels a little better to me - that said, there are plenty of folks who dont feel that way - but again, with the abstraction, thats fine, you can have native, or not… your call. -
Another, probably quite small thing, is the render loop: openfl has one, this means that your app is sitting there eating up power even when doing nothing, this isnt an openfl specific issue of course, kha and heaps are the same (and therefore haxeui-openfl, haxeui-kha and haxeui-heaps exhibit this behavior - feathers too presumably). With the haxeui-html or the native backends this isnt the case, there is no render loop (iirc openfl is pretty good, now, in that dept. but at one point i remember being able to watch the battery go down on my phone while running a fairly simple app)
-
Finally, its the xml and the macros. This very well could be a personal choice again as know plenty of people who use neither the xml nor macro parts of haxeui (which i still dont get
), but personally, the ease of using xml to design and layout components (and custom components) is invaluable to me - apart from the ability to create native uis, id say its probably the first thing i look for in a ui system. To be fair, feathers is still alpha and i dont know if its on the road map, and even if its not, it wouldnt be hard to create something like it for feathers.
So, really, its kinda a “up to you” type answer, i would take both for a spin and see which you prefer and “gets it done” for you with your style. Hell, you could even write a haxeui backend for feathers ui, haxeui-feathersui, heh heh
Not really sure if that helps in the slightest, but its the best i could think of off the top of my head!
Cheers,
Ian
2 Likes
That is fantastic Ian, thank you. Your thoughts about being locked into a back end resonated with me. That same philosophy is what drew me to use Haxe in the first place, and also PureMVC. Technologies and platforms change all the time and I like the idea of investing in skills that will transfer for a long time into the future. I’ve long had HaxeUI on my list of things to learn but I haven’t had a project in which I would need it yet.
1 Like
I got a >good answer from Josh over at the FeathersUI forum< if anyone is interested. Good time to be a Haxe developer!
2 Likes
I’ve done a little more exploring today. I suffer from a constant search for the Holy Grail of website building unfortunately. I was quite interested in the capability of FeathersUI to integrate with HTML history API using the RouterNavigator component. Part of the reason for my interest is that my own project Glory Framework has its own browser history integration and its own XML-based layout system. I built it to facilitate building sites/apps from a designer’s paradigm and have used it successfully but I wonder if I would do well to either integrate it or replace it with another system with a longer track record. I don’t see any HTML history or routing stuff for HaxeUI—has it been done before?
Its an interesting sub system, for sure. But, unfortunately, nope, at this time there isnt anything like the RouteNavigator in haxeui. 
1 Like