I have seen the light and I believe that Haxe awesome – why don’t you want to use it?
Alright, you probably heard about Haxe (some people are annoyingly fanatic), maybe even used it at some point in the past (it probably sucked).
But you don’t know Haxe – it has changed, you have changed, let’s talk.
It ranges from "it’s too complicated for me" to "it offers a Flash/Java-like write once, run anywhere?". Let’s clear those:
Haxe isn’t too complicated
Haxe the language used to be rough around the edges, that’s not the case anymore. The language has been greatly refined to become a real jewel: easy to approach, rewarding to master.
People inexperienced in Haxe that we hire in my company become proficient enough in a few days/weeks. This is nothing compared to the difficulty to getting familiar with large projects and libraries codebases.
You can read a fantastic primer of Haxe language features here. Indeed there are a few really advanced topics but you don’t need them to get the best out of Haxe quickly.
But not all targets are equal
Not every target are easy to use – you probably should not look into C#/Java/C++ targets unless you are really good in these languages and you are really looking to leverage Haxe’s cross-targets compilation.
Haxe isn’t like Flash or Java
Haxe is native to the platform you target: no VM, no Flash-like API.
Haxe includes a minimal, well tested, crossplatform API, centered around common application logic needs (http requests, Xml, Json, binary streams, files,…) but otherwise you are supposed to use the target platform’s native API.
OpenFL (forked from NME which still lives in the shadow of OpenFL) is an abstraction, offering a Flash-like API on all supported platforms.
Lime is the platform abstraction powering OpenFL. It offers an openGl-like API and provides the tools needed to create mobile apps. You can use it directly if you’re hardcore.
Flambe is another library and toolchain to target HTML5 and Flash (browser and AIR) using a single original API.
Those libraries and tools are leveraging the Haxe language and compiler, but they are completely optional and independant from Haxe.
Also to be completely honest, OpenFL still has not reached the stability/performace/ease of use that would make it advisable to everybody (especially if you’re not ready for C++ debugging). On the other side, Flambe is a very stable option.
My precious productivity
This is a very reasonable reaction, and the cost of changing languages is real and should be carefully weighted: new tooling, new libraries, porting possibly a lot of code… it add up quickly.
As anyone I felt too productive to switch to Haxe although I had followed closely the language since its creation in 2006. I only really got into Haxe around 2012.
Some individuals and companies, like Massive Interactive, created more or less from scratch an entire ecosystem of libraries needed to do serious development. So you don’t have to: Haxe now has all the signals, mvc, unit-testing, mocking, code coverage libraries you can wish for.
It’s always impressive to present big successes like TiVo or Prezi, porting huge codebases to Haxe. Those were carefully planned risks (Prezi still prefers a native iOS client) and they were thankfully a big success. But that’s extreme switching.
For the rest of us there has to be a low friction first project to get started.
- Starling – easy to use when targeting Flash/AIR,
- Flambe – popular for web games (and AIR mobile) and marketing websites (mix with DOM elements),
- OpenFL, HaxeFlixel, HaxePunk – crossplatform mobile games.
Using existing libraries is simple: either in an untyped fashion (aka JS as usual) or in a typed way, with special definitions for the compiler.
But there’s a catch
Some aspects of Haxe aren’t for the faint of heart: if you just want to follow the trend and copy and paste instructions without too much thinking from blog posts and detailed tutorials, Haxe is probably not for you.
Tooling for instance is a bit hit-and-miss. There are many editors offering Haxe code completion, but none will really have the maturity of ActionScript 3 tooling for instance. Stick with the most popular options (FlashDevelop, Sublime Text, IntelliJ) but take the time to test different editors. I’d say FlashDevelop is probably the most complete option but I’m a bit biased and that’s a Windows app 😉
That said, if you’re up for a rewarding challenge find yourself a mentor, hang out in the IRC channel, and ask questions on the mailing list.