The point of systems like Haxe is "write once, run anywhere". You don't need to mimic the standard OS interface style to do so, especially not with games (as it's more important that the style of the interface suits the game).
That's great as long as you don't care about reusing your code. It's not just biz logic, services, utils, etc either, I'm talking about the fact that people put UIViews over SpriteKit games all the time and you can't rightly say that doesn't exist just because you get to downvote me.
Firstly, I didn't downvote you. Secondly, I don't know what point you're trying to prove. The people that create frameworks for Haxe have their own priorities, if those priorities don't align with your own that doesn't mean they lack merit for those that use them. Haxe has been used to create a number of successful apps and games. Instead of just looking for weaknesses, try also looking for strengths, try understanding why developers are choosing to use it.
I'm not sure why you responded if you didn't get my point then, but let's assume you're asking me in good faith. All I'm saying is that your premise of "write once, run anywhere" is still not true for everyone, everywhere. So I don't see why I have to accept it as if I'm being unfair to someone. I think it's not honest when people are not upfront about hidden limitations to their promises which are going to have material effects on the future. We ought not to sweep this problem under the rug when we have the chance to solve it. I don't buy that people have entirely their own priorities. We all need a solution to this problem, but who wants to dedicate their life to making "learn once write anywhere" an actual reality? Especially when the developers of top platforms "have their own priorities". Go ahead and call me esoteric but I guess I just prefer it if projects didn't overhype their capabilities when I'm supposed to be evaluating them for security- and business-sensitive contexts. :P
> "I'm not sure why you responded if you didn't get my point then"
For the sake of clarity.
> "All I'm saying is that your premise of "write once, run anywhere" is still not true for everyone, everywhere. So I don't see why I have to accept it as if I'm being unfair to someone."
Use of native UI widgets is not a prerequisite for "write once, run anywhere". Code runs just fine using custom UI widgets. From a styling point of view, native UI widgets are a nice-to-have option, but they're not a required feature.
Whether or not it's intentional on your part, you didn't understand what I pointed out at all. And you are literally making it up that "non native code runs just fine" and native code isnt a requirement. Do you think it makes it true just by insisting there's no way anyone might ever need native code? Lol. You're just displaying your ignorance and inexperience. However I at least am not tied by your choice not to have the real answer. Thanks for leading us down a completely useless rabbit hole after not understanding what I said at all. I'm sure you'll come up with all kinds of reasons why your point of view does not have to be discarded as invalid. But your "ideas" are exactly what led to have toolkits like Flash and HTML/CSS. Congrats. That's what happens when people are asleep.
Ah, I can see where you're getting confused now. Haxe compiles to multiple formats, including binary formats on platforms like iOS. Native support is not reliant on using the bundled UI framework, native support means compiling code to the native format expected by the OS.
To use an analogy, imagine I build a C++ app for MacOS but I use Qt instead of Cocoa for the UI. The end result is still a native app. Native is about the runtime, not the UI library.
