Closed delahee closed 8 years ago
Hey David!
Good one. Alongside web development (which is getting better, specially because of haxe-js-kit
[0] from @clemos and also the libraries from @ciscoheat [1], and the latest Ufront
*[2] efforts from @jasononeil) this is one of main the Haxe weak (and sweet) spots.
When it comes to frameworks that allow access of native UI toolkis and deployment of binaries to multiple platforms, the following comes to my mind:
Those are the two I know work well. I have a friend whose startup is completely based off RubyMotion, his mobile app is entirely done in Ruby. RubyMotion is really getting some traction now and there are many nice libraries and frameworks available for it, many following the Ruby and or Rails way, which is a blessing for someone used to the Ruby eco-system.
I don't know much about Xamarin, but I have another friend that used it with great success as well. I can get more information about these use cases if someone is interested.
Suffice to say I think Haxe could have the edge here. Basis and BasisApple sounded promising, but for some reason, the author stopped investing time into it.
The question is, what do we need specifically to get a good quality library that allows easy API access to the native UIs without a lot of boilerplate code or needing to go down to the target language layer? I have iOS and Android in mind, mainly, but OSX, Windows and perhaps Linux UI toolkits would be nice, as well. Sharing most of the code would be best.
I know Quaxe
*[5] could be the answer to (most of) that, so maybe more focus and energey should be geared towards it?
Cheers.
[0] https://github.com/clemos/haxe-js-kit [1] http://ciscoheat.github.io/ [2] http://ufront.net/ [3] http://www.rubymotion.com/ [4] http://xamarin.com/ [5] http://quaxe.org/
Use NativeScript with haxe/js and be done with it ;)
Wow! I didn’t know about NativeScript, that looks great! I’ll certainly consider it, Juraj, thanks for sharing!
On Jul 10, 2015, at 3:48 PM, Juraj Kirchheim notifications@github.com wrote:
Use NativeScript https://www.nativescript.org/ with haxe/js and be done with it ;)
— Reply to this email directly or view it on GitHub https://github.com/HaxeFoundation/Project-Management/issues/40#issuecomment-120519494.
@back2dos
Have you used it ? In production ? is there anything necessary on the haxe side( haxelibs, whatever ) needed to ensure it is ok ?
If you would elaborate more than one line, this would really optimize the process of getting this subject done and canonized :)
Thanks !
@delahee This was half a joke. No, I haven't used it in production and I'm still waiting to see whether React Native won't become a better choice after all.
I have tried some of the demos and was amazed how straight forward it actually was. In principle I don't see why you would need anything particular to use it with Haxe, but of course tighter integration is often worth the trouble.
But I don't think this subject can be so easily "done". While both NativeScript and React Native give you native UIs, they are rather thick abstraction layers, which might sometimes get in the way. But it seems to me that of all the things available to Haxers here and now, they are currently the easiest way to a native UI.
additionnal reference :https://groups.google.com/forum/?hl=en#!topic/haxelang/9561xXEth9I more with wxWindows : https://github.com/nmehost/waxe https://github.com/therealglazou/waxe https://github.com/nmehost/waxe-works
hey @waneck What does it take to bind xamarin using haxe cs, have someone done it ?
It should work out-of-the-box with -net-lib
. However, the workflow might be a little clunky (e.g. integration with monodevelop). I still haven't heard of anyone that has tried it yet.
Will HF consider investing in a team to build a pure haxe solution for this topic?
With the yearly budget Nicolas presented at the WWX, I doubt the foundation can afford even a fraction of what is needed to build such a solution.
I've tried React Native and I must say I'm impressed. There's a lot of hype around it now, too, and the examples I've gone so far all look and feel very smooth, like a 100% native app. That might be a good option for Haxe developers to leverage.
The react native code doesn't seem to be standard js code. What I mean is the inline XML as shown below. Does haxe support that kind of syntax?
var App = React.createClass({
render: function() {
return (
<TabBarIOS>
<TabBarIOS.Item title="React Native" selected={true}>
<NavigatorIOS initialRoute={{ title: 'React Native' }} />
</TabBarIOS.Item>
</TabBarIOS>
);
},
});
Not quite I think, but with some macro magic, I think a syntax close to this can be achieved. Check out https://github.com/ciscoheat/mithril-hx, @ciscoheat did something along these lines for Mithril.
On Fri, Sep 18, 2015 at 9:55 PM, Kevin Leung notifications@github.com wrote:
The react native code doesn't seem to be standard js code. What I mean is the inline XML as shown below. Does haxe support that kind of syntax?
var App = React.createClass({ render: function() { return (
);
}, });
— Reply to this email directly or view it on GitHub https://github.com/HaxeFoundation/Project-Management/issues/40#issuecomment-141611600 .
linking https://github.com/Meychi/CreateJS-Haxe, if someon want to generate a react native binding, maybe we can build up something clever & cheap.
Yeah I'm still working on React integration / JSX like stuff. Unfortunately it's still extremely experimental and not documented whatsoever... I hope to be able to continue working on it in the next few weeks, and release something useable eventually...
@clemos awesome :)
We should also not forget about this: https://twitter.com/elsassph/status/644156820567797761, looks like Massive also has something in the works.
On Mon, Sep 21, 2015 at 7:47 AM, delahee notifications@github.com wrote:
@clemos https://github.com/clemos awesome :)
— Reply to this email directly or view it on GitHub https://github.com/HaxeFoundation/Project-Management/issues/40#issuecomment-141963949 .
And our future might lie here: https://twitter.com/IanHarrigan1982/status/662308080332488706 KUDO @ianharrigan
Probably a better representative example here: https://twitter.com/IanHarrigan1982/status/662586365389967360
I also think that waxe in general (outside of HaxeUI) would be something to revisit for native L&F - for people how would rather not use HaxeUI (for whatever reasons)... it works, and is fine, but there is lots and lots missing and doesnt really mimick the class structure of wxWidgets...
Its something that is totally doable of course, but would require quite a bit of time invested of course. It would probably also be nicer to move the fuller version (if / when it gets done) under a HF repo for clarity
Update from @ianharrigan: https://twitter.com/IanHarrigan1982/status/672816466325053440
I don't really understand the idea of dumping links here.
@delahee Can you put the relevant links on the website?
About wxWidgets: I worked a bit on an extern generator a couple of years ago (based on Hugh's waxe code). For an API as big as the wxWidgets one you definitely need a generator for externs IMO. wxWidgets has doxygen docs you can parse for that.
But as of now wxWidgets still doesn't really support any mobile platform, does it? It surely was interesting 5 years ago maybe, but today? Well, for pure desktop apps maybe...
I agree with @back2dos, that NativeScript is pretty interesting (only for mobile as of now). It offers a hook for transpiler integration: http://docs.nativescript.org/transpilers Might be interesting to try to integrate Haxe there. Also interesting how this will compete with the real big guys (Angular, React)...
I'm making (with a friend) a generator doxygen -> hxcpp https://github.com/LemDes/doxygen2hxcpp it's starting to be a bit of a mess, and there's still a lot of bugs to fix, it's a lot harder than I imagined.
We've been testing it on wxWidgets, I confirm what @mockey is saying, it's too big to do by hand. It's also too big to do it completely with a generator (missing or incomplete doc, macros ...)
It's also not the best lib I've seen (in design) but compared to using openfl/kha/snow for desktop app it'd be a lot better.
Correction: I didn't use the doxygen files back then. I parsed the header files in /interface/wx/
.
And yes, it's not so easy to get it right. I gave up pretty soon :-)
Maybe it's a bit better nowadays with the newer hxcpp features.
I don't see the point in this issue. What's the agenda here?
I guess the general idea was to synthesize the information collected here to arrive at an answer to the question "Well, this Haxe-thingy looks interesting, but can we use it for UIs outside games?". I have found a satisfactory answer for myself that resonates fine with potential clients, but I think if Haxe is ever to come out of the gamedev/webdev corner, it would certainly help if the were a solution that is (at least to some degree) officially endorsed by the Haxe Foundation.
I agree too that we need at some point a native UI toolkit that would work for mobile and web. However HF does not have the funds and manpower to build and promote such a solution. I think we should instead reuse something done by others (ReactNative, etc.) but being not myself in that area I'm not such what's the best choice available.
I think we all understand that. I just wanted to explain to @Simn what this issue was about.
I agree too that we need at some point a native UI toolkit that would work for mobile and web.
I think HaxeUI2 is gearing towards that path.
And ReactNative is a good alternative as of now to use with HaxeJS -- http://www.reactnative.com/.
Let's track here the "native" app competitors and see how it sorts.