I want to start some pet projects in Haxe.What is the status of some of the backends?

I am aware of how many backends Haxe supports and that it is used by some large game companies but I am still skeptical when it comes to Haxe future. So far it seems that haxe did not attract the critical mass it needs to thrive.
Nonetheless I’d like to write some pet projects in Haxe. I work in a MS shop (so mostly C# and friends with a few java applications here and there).

I’d like to know the status of Haxe’s backends how usable they are and how easy it is to integrate existing libraries / packages with Haxe’s code / or generated project (binaries, files…etc).

I saw few topics that interest me like how MSSQL can be used with Haxe and so on.
This is critical as these types of components are usually used by other applications.

Welcome on board! Help us to thrive! :slight_smile:

1 Like

I can say for some of them (tho I come from game dev side):

C# is very much usable, although some generated code could be nicer, performance-wise (e.g. anonymous objects), but it’s not an issue most of the time. I used it successfully to compile a DLL with game logic for use from Unity. Using existing libraries is just -net-lib Some.dll - it’ll read the bytecode and create extern types automatically. From what I know, Java backend is very similar.

JS is one of the best targets right now, considering the quality of generated code. Integrating with existing libraries requires writing extern definitions, which is pretty simple and there are a lot already.

Lua target is similar to JS, although it’s newer and the generated code is not as minimalistic as JS (mostly due to lua specifics), but I had some success writing stuff for the Defold game engine using it, so should be fine!

I did a library for our QA guys on my previous job, using Python target - it’s okay, although using external libs might be a bit tricky due to heavy usage of duck typing, operator overloading and args/kwargs argument handling in native python code.

HashLink seems to be a beautiful new target - really well optimized code generation and efficient data structures, can generate pure C or bytecode that is JIT-ed to machine code on load. Already battle-proven, tho I personally haven’t used it for non-helloworld projects. Integrating with native libs requires some C glue, that can often be generated automatically. The overhead is minimal to none.

Thansk for the reply.

For the C#/Java targets how is it possible to use the raw code from those languages ? Do people do it ? How hard it is to “attach” existing projects in those ?

I read somewhere that JS lacks something like react. How difficult is to use the JS target with existing JS frameworks / libs like React/Vue etc ?

How is the CPP target and the same question about existing libs / code. Does it compile to a self contained executable with GC ?

This is a great library for Haxe/JavaScript + React

Also for vue

Just a little feedback about using haxe + react. I use them together with GitHub - massiveinteractive/haxe-react: React JS applications development using the Haxe language and GitHub - jasononeil/webpack-haxe-loader: Webpack loader for the Haxe programming language. on several projects for more than 2 years now and am very happy about it versus using react + ES6.

Using external js libs with haxe is really not an issue today. You would have to get/write type definitions with typescript too anyway.

I’ve just started using https://github.com/haxe-react/haxe-react-native on a new project so it’s a bit early to give any feedback there…

However, I can confirm that haxe + react js (+ webpack haxe loader) is definitively production ready.

C# target is solid, using libs is easy (you don’t need externs, just the lib’s dll and a -net-lib Some.dll in your hxml like nadako said). I am using it for dotnet core, not for unity.

Things get harder when you want to integrate the generated C# code into a C# project. The C# project uses a lot of my classes and functions.

Signatures may not be what you want them to be at first try (some types are lost to object, nullable needs to be explicit instead of using haxe nullability, etc.), typeof is a little tricky with type parameters, using generic methods can be tedious (and fallback to object as type parameter), Linq expression do not seem to be well supported (but you can construct them yourself). There are tools (@:nativeGen, @:meta(Path.To.My.Attribute), Nullable<T>, etc.) to get there, but it can be a little hard at first.

I am an experienced haxe developper but just started using the c# target (and the c# language).

Are you (or have you been) using hxlinq?

No, it wouldn’t help (unless I missed something) for constructing linq expressions like lambdas, I am not using the LINQ query features atm.