Y U NO Haxe? Misconceptions!

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.

tl;dr: Haxe is a better JavaScript


Common misconceptions

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.

Otherwise, targeting Flash, JavaScript or PHP is comfortable.

Haxe isn’t like Flash or Java

Haxe is native to the platform you target: no VM, no Flash-like API.

In general, Haxe code is transpilled (source to source compilation), into the target platform’s language: JavaScript (browser, nodejs), C++, PHP, Java, C#, etc.

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.

In short, if you target JavaScript in the browser you will use the DOM. Haxe will just be a better JavaScript with a few built-in helper classes.

But OpenFL/Lime/NME/Flambe…?

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

JavaScript is my first professional language since 2001, then ActionScript 1, 2 and 3 since 2002, C# since 2005. That’s a lot of investment in tooling, libraries, workflow that you are supposed to risk for an unclear benefit.

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.

Switching

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.

My personal reasons were to play a bit with crossplatform 2D mobile games and to have a better JavaScript for the web.

2D games

  • 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.

A better JavaScript

The most important for me: Haxe is simply a better JavaScript/CoffeeScript/TypeScript/etc. The language is just a fantastic match with JavaScript, the generated code is clean, smart and efficient.

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.

6 thoughts on “Y U NO Haxe? Misconceptions!

  1. I tried to use openfl but my journey stopped even before I write a single line of code. The reason was the complicated installation process. but I tried flambe which seems to be a great option for html5 games.

  2. I cringe everytime – “Haxe is native to the platform you target: no VM, no Flash-like API.”

    Due to the fact that Haxe’s C++ garbage collector is extremely unoptimized and stupid and that OpenFL Android Audio has problems since the beginning of time, VM games (flash air exported or js wrapped) run FASTER and BETTER than HaXe Android exported ones!

  3. Amer and anonymous guy:
    Fair remarks, OpenFL has definitely not reached the stability, performance, and ease of use that would make it advisable to everybody. Hopefully the move to OpenAL should nail the Android audio problem. Garbage collection is a complicated topic, especially as some things behave differently in OpenFL and Flash/AIR; do you have a specific references of GC issues?

    I didn’t want to recommend OpenFL particularly and I’m mentioning it in the post to clarify that OpenFL and Haxe are distinct projects – I’ll add a warning about the problems this library has.

  4. I’m not surprised that Haxe proponents wonder why people still don’t use Haxe.

    A classical mistake by programmers is to be anaware of their own context (be it technological or intellectual). They make great tools, but usable only by .. themselves. When it comes to make those tools accessible to the general public, they suddenly realize the many details of un-documented settings on which these tools rely upon. Then the logical consequence is that the classical “initial setup” then take hours, in not days.
    OpenFL is apparently a good (bad) example.
    Flambe is cool, but forces to adopt an entirely new paradigm (Entities, animated value,…), the initial setup is not technological, but rather intellectual 😉
    Phaser: cool, but also reinvents the wheel everywhere.

    From what I’ve seen about Haxe, HAxe is ok and well designed, but the ecosystem (OpenFL, Flambe, ..) built upon it suffers from the limitations I just mentioned above.

    So if you still wonder why Haxe has not yet conquered the planet, probably think about accessibility. Putting effort in evangelizing new users to adopt the existing platform will only attract the same self-focused developers.
    I suggest putting effort into making the platform more accessible.

    flashDevelop, in comparison, should be praised as a remarquable effort put into accessibilty of use (at least compared to Eclipse, FDT) from a user point of you, but contains still many difficult stuff to setup (eg: setting up debugger, asdoc, java32,…)

  5. @glucide I have absolutely been conscious about this problem since the very creation of Haxe nearly 10 years ago. This serie of JS-orientated articles is precisely to try to contribute in making Haxe-JS more accessible.

Leave a Reply

Your email address will not be published. Required fields are marked *