Haxe survey 2019 - Final results and discussion

Disclaimer: It’s my opinion about the results of the survey. It may be a wrong assumption, so be alert. If you want to participate in a discussion.

Is Haxe used as a better javascript?
Maybe. One thing is sure, the web is important and for that javascript target too.
( Haxe is in top 5 transpilers https://www.slant.co/topics/101/~best-languages-that-compile-to-javascript and https://www.sitepoint.com/10-languages-compile-javascript/ )

Who uses Haxe?
Mostly experienced developers with 7 or more years of experience. They come from javascript, flash, C#, Java and PHP ecosystems and about half of them use Haxe professionally . More of them are newcomers using Haxe between 2-6 years. About 60% of them are from Europe.

How is Haxe used?
Games are still important part of Haxe. Mostly desktop games follow by Web and Mobile games.
Many use Haxe for web development - back and front-end, but not so many use Haxe for export to PHP or python ( server-side scripting languages )
So for what reason devs used Haxe in web development? Maybe for backbone for other libraries such as node, React, Vue, Pixi, ASP, JSP and so on.
Is this make the Haxe more beautiful alternative of TypeScript and that should be one of the strongest market point of Haxe? Check here for TypeScript alternative where Haxe is already mentions: https://www.slant.co/options/378/alternatives/~typescript-alternatives
Haxe used as command-line utilities? Why not? Many use Haxe for that which make it a nice alternative of python and bash scripts.
I do not see many Haxe libs for command tools (an example is mlib and tink_cli ), and the most recent one is hxp ( https://github.com/openfl/hxp ) . So using Haxe for command-line utilities are mostly custom solution tools ( for test, compilation, deploy , etc. ) right?
After that is used in desktop and mobile applications and in sotfware Libraries.

Which 2d/3d framework is popular?
The most used 2d/3d framework is OpenFL, followed by Heaps and Kha.

Your favorite lib?
Most lovable is Tink ( 18%) , followed by OpenFL ( 14%) . Others are HaxeFlixel (8%), Buddy (6%), Heaps(6%), Nape, HaxeUI. So Tink is a thing.

Which target do you use?
Again web with javascript is on the first position follow by C++ ( for native and mobile exports) , Neko and Flash is still a something.
For what is use neko? Is it part of fast compilation tests and deploys, console tools or used as a mod in the web servers?

Other targets?
WebAssembly , ES6 and Swift.
Well, ES6 maybe is coming [js] ES6-class generation support by nadako · Pull Request #7806 · HaxeFoundation/haxe · GitHub
About WebAssembly I think it will come sooner or later using HashLink or Hxcpp compiled to pure WebAssembly
And there is some work in progress for Swift : GitHub - rwthompsonii/haxe-add-swift-target: adds a swift target to the haxe language. ) . If you want to know more about “What is needed to develop a compilation target?” and want to help, check here What is needed to develop a compilation target? - Haxe

Where you publish your Haxe app?
Again, mostly on the web follow up by native ( mobile and desktop)

What OS do you use?
Primary desktop and mobile os is Windows and Android and preferred IDE Visual studio.
Macros are a strong part of Haxe using by 60% of developers.
haxe9 haxe10 haxe11 haxe12

One of these for me, too
The most wanted feature - concurrency support or way to write asynchronous code ( using await, async, yield, coroutines )
There some libs for that: GitHub - haxetink/tink_await: Haxe async/await , GitHub - nadako/haxe-coroutines
Do you want to be a core feature? Maybe you should make a proposal on haxe evolution - GitHub - HaxeFoundation/haxe-evolution: Repository for maintaining proposal for changes to the Haxe programming language ?
Also, better IDE integration, better debug support and more documentation is one of the most eager features.

Conclusions, Haxe is:
Strong used in web development
Strong used for games
Strong used as a command utility tool

So what is Haxe?
It’s a language used to write games, web development and command-line utility tools. It is used as transpiler to JS by developers who looking to publish on the web and to C++ for mobile and desktop. It’s not for beginners, but anyone can find something cool and interesting for himself

One last question which bugs me. TypeScript is more popular than Haxe. According to latest PYPL is on position 11( PYPL PopularitY of Programming Language index )

What makes TypeScript better than Haxe ?

  • Nothing. Haxe is better.
  • The big company behind it
  • Better JS integration and more feature-rich API
  • Better tooling ( IDE , debug support ), big community and documentation

0 voters

Full results of survey here : Haxe Survey


Thanks for doing the survey and putting so much time in it! Very interesting to see the results!! :fire:

This is a trick question. There is no Haxe vs Typescript. Both are similar but different tools with different purposes and goals. For a webdeveloper typescript might be enough, but for a full stack developer Haxe might be more interesting. Also you know there are more Haxe developers here, so the result to this question will be biased / skewed. I personally don’t see why you ask this very specific question. Also, in theory Haxe could have a typescript target.

When I tried to summarize results I find something interesting - some people search for Typescript alternatives and there Haxe was shown as good and appropriate alternative . So I ask myself , if I need to write to javascript , but don’t like pure JS what will use ?
Obviously , for most developers the answer maybe is Typescript, but why they not choose Haxe ? What miss to Haxe to be the first choice when someone want to write Javascript ? Is it marketing point of view or something else ? For that I ask that question and yes, I know Haxe could have a typescript target , but why not typescript to have a Haxe target , why need Haxe to be a second choice ?

I just want to add something.
When someone approaches Haxe the first question is why I should choose Haxe?
In many sites, the first things which you’ll see are benchmark graphics.
They show how this language/framework is better than others - how produce smaller code size, better performance and so on ( example elm ). So if this is a strong part of Haxe it should be shown.

These results are interesting. Thank you for gathering them.

When drawing conclusions, please remember the subset of the community that answered this survey are, in general, small and independent entities. Developers in larger development groups tend to have their own support structures and therefore generally don’t frequent forums either to answer or to look for help. Therefore, the conclusions may not (likely don’t) apply to the thinking of larger organizations.

Don’t take this to mean that the results are inconsequential (or that I think they are). They can and should be used to drive decision making when small consultancies or very small development teams are the primary consideration. Because of the sample, they cannot provide deep insights into the market as a whole.

When someone approaches Haxe the first question is why I should choose Haxe?

I don’t think so; I think it’s “Can Haxe be my (product’s) savior?” Generally, people are looking to solve a problem, and are really asking whether Haxe will solve it. For instance a large set of developers looking to Haxe already have applications in the marketplace and are looking for a way to take their current products to other platforms. Or their product is on a dying platform (ahem, Flash) and are looking to leverage their old investments into renewed products.

People who use Haxe for new projects tend to be folks who have already learned and used it for another project. I’d love it if Haxe had the cachet of, say, Ruby (in its heyday) or Typescript (now). The truth is that it has never had the eye of mainstream development, so it’s not even considered for most new projects. Changing that is likely to take some truly unique innovation from the language or libraries.

Presuming I’m correct that the entry point for most new engineers/companies is saving current development, then the question becomes, what will it take to make the conversion of current projects really, really, simple. That may have been (and in some cases may still be) getting a really great version of as3tohx. Right now, for front-end programming, it’s probably something like a Javascript converter and a rock-solid webasm output. If we can add a great platform that creates RESTful interfaces as easy as, say, Rails does, then we might be able to gain some traction.

In the end, attracting more users is all about development speed. We actually have a good system for that, particularly when deploying to multiple platforms. We need a huge success at a very large industry player. Even TiVo – a household name – porting to Haxe wasn’t a big enough splash to garner the attention of Silicon Valley.


What a wonderful survey! Very well done indeed. I think it makes it clear who are target audience is and who we have to target henceforth. Its kinda interesting to note that everyone who uses haxe has >7 years of experience, makes me wonder if we can target the newbies too, to drive up adoption rates.

I think we also need to improve documentation. I had no idea something like Tink even existed. Haxelib is so full of stuff its impossible to know which ones are actually useful. Maybe we should advertise the important libs on a per-platform basis.

I am also thinking you are correct with this assumption. And since JS runs everywhere nowadays, and therefore Haxe JS target is so valuable I would think it would be great if ts2hx (GitHub - Simn/ts2hx: Typescript external definitions to haxe converter) would be rock solid.

I think almost every relevant JS Lib has typescript definition files today. It would be huge if you would not need to write any externs for all those JS libs anymore, because you can just generate them automatically. You could even automate that and just take all from Definitely typed. Possibly even the vscode haxe extension could have some automation to generate (or get) your externs if you target JS.

We established that ts2hx was the wrong approach: Instead of parsing TypeScript in Haxe, we should hack into the TypeScript compiler and emit Haxe from there. The problem is that nobody went ahead and spearheaded such an operation.


Well, what ever approach is best. As long you could tap into the huge pile of typescript definition files for Haxe externs. I think this would be hugely beneficial.

1 Like