You are here

Is 2013 the year of Haxe?

Submitted by gregdove on March 29, 2013 - 6:30am

Haxe LogoI've been learning and using Haxe for a few years now. In the last year or so I would even describe myself as an active community member (my small contributions are mostly issue reports, patches, etc.). I consider Haxe to be still largely 'unknown' by many, but I think that 2013 could be a major growth year for Haxe.​ I'll explain why eventually (skip forward if you want to get there early), but first I think I'll cover a bit of history.

I started getting interested in Haxe when it became clear that Nicolas Cannasse, the creator of MTASC, was doing something new and different (and calling it 'Haxe'!). To reminisce a little, MTASC was a fast, command-line,  actionsript 2 (AS2) compiler, with extra features compared to Flash IDE compiler, which became popular around 2005/2006 if I recall correctly. The exact same AS2 code that compiled with MTASC could also be be compiled with the  Adobe (Macromedia at the time, I think) Flash IDE, although the reverse was not always true due to stricter rules for MTASC. Back then for AS2, I really liked MTASC because it was extremely fast, and offered stricter options to help prevent errors at compile-time, avoiding the need to debug those types of errors in compiled swfs. It also integrated well with my favourite external (to Flash IDE) code editor at the time, FlashDevelop. So after my familiarity with MTASC, it was interesting to see what the 'next big thing' from Nicolas Cannasse was going to be, and it turned out to be Haxe.

Haxe is different to MTASC in that it is both a new language and a compiler that still lets you also compile to swf and offers a lot of swf-related options. It also provides the option to output as3 source code. It permits you to target both avm1 (AS2) and avm2 (AS3) player targets from the same Haxe code (although the display object type support differs because it differs between the two avms, but it's possible to accomodate that in the same codebase via compilation switches). I expect the need for developing new avm1 content to disappear, for most of us I guess it already has, but this legacy platform remains supported. 

If you approach Haxe from a position of AS3 experience as I did, then it does require learning a language with some key differences, but also a lot of familiarity. I usually relate to this by thinking about how lots of people complained about the additional 'complexity' with the move from AS2 to AS3. Despite the initial 'hurdle', most of them (certainly those who had coding as a substantial part of their flash-related activity) subsequently grew to appreciate the benefits of stricter typing in AS3 along with the new api. If you count yourself among those who had this experience, then you would have a sense of how I feel about the the transition from AS3 to Haxe, because it feels like a similar advance to me.

In terms of making that transition, there are some quite new concepts to grapple with, some are familiar and others seem intuitive once you grasp an example. A couple of quick annotated examples, where there are differences but it's quite intuitive:

//type inference, typed Arrays var items = [3, 2, 1]; /* NOTES 1. items is now type-inferred to be Array<Int> 2. this could also have been written as var items:Array<Int> =[3, 2, 1]; similar to as3 3. Int is the integer type, typically used instead of int or uint in as3. 4. Array<Int> is roughly similar to Vector.<int> in as3, a strongly typed array. 5. With typed arrays you get type checking and code-completion for array element access/assignment */ //basic loop examples/iterators for (i in 0...items.length) trace(i); //0,1,2 for (intval in items) trace(intval); //3,2,1 /* Note: A semicolon is *mandatory* for end of statement/expressions */

There's no point going beyond a simple example like that in this post. After all, you can read about the details in the online docs.The basic point is that there are some things like the above that will seem different, but familiar enough to get used to quickly. There are some things that take a little more time. For me, Haxe enums, was one of those. The thing is, even for the advanced features that might take a while to get your head around, the payoff is usually well worth it once you get to that 'ahah!' moment. For as3 coders, Haxe also offers a lot of the features that were on the wishlist for the now shelved 'asNext' and a whole bunch more.

So, now I will circle back to the part where I said I think this will be a ground-swell year for Haxe. Here are four key areas that I think will contribute to that.

1. Extended target platforms. Haxe not only generates output for the flash platform but also has a number of other targets, which can all be targetted from the same Haxe codebase (with possible use of compiler switches for specific parts of the code). So re-use of code intended for the flash platform in javascript or in serverside targets for example, is easily possible. This provides flash developers with a more fluid option for adapting to changes in marketplace preferences. Or simply a way to easily extend what they currently do, to other target platforms. Haxe currently also generates output for javascript, neko (another VM), PHP, C++, Java, and C#. Java and C# have been in beta, but should be (I expect) new official targets from Haxe 3 onwards. This further extends the reach of the Haxe language. There are hints of others working on other targets which also may become available in time. Running unit tests simultaneously across many different targets is a real possibility from the single codebase (the Haxe unit tests themselves do this).

2. Perception. One of the potential criticisms leveled at Haxe from a cursory external review of it was that it was a "one-man-band" in terms of being overly dependent on Nicolas Cannasse (NC). The underlying concern there is what I call the bus effect*. It's true that NC is central to the continued development efforts of Haxe. But it is definitely not a "one-man-band", and hasn't been for some time. NC is now more the 'benevolent dictator' although of course he is still very active in coding. The core team has a number of highly skilled and committed developers who work on the compiler and standard library codebase with a passion. And the wider community is getting more and more active in providing ideas and support to bolster the use of Haxe. Most successful projects of this nature (e.g. Drupal, jQuery etc.) which started with individuals now have a central organisation structure which addresses the "one-man-band" image and coordinates community resources and planning. The organisations are funded through sponsorships or through offering their own paid-for consulting services. Such an organisation for Haxe now exists. I believe it will be instrumental in boosting the popularity of Haxe in practical terms (marketing, community etc.) but also in terms of being another box that is checked during technology review/selection processes, particularly for potential enterprise users who are likely to be more risk-averse.

3. Maturing libraries. The Haxe standard library has a great set of common functionality which works across all the targets. But there are many additional libraries that are original Haxe libraries or have been ported to Haxe from other languages. Some are cross-platform and others may be more for specific targets. One of the popular ones is NME which is often the first stop for new Haxe users coming from AS3. In general, where a Haxe port of a library is not available, it is relatively easy for most targets to use external native code (e.g. a javascript library) in Haxe by defining  'extern' classes. Using externs offers a way to get code completion and type checking working with use of external native code in your own Haxe code. Many of these externs are also released as libraries. Also there is a growing variety of UI libraries.

4. Evidence of growing popularity. I think popularity is often self-dependent (or perhaps somewhat recursive) in nature. Some things "become more popular" because they're already "popular". I think this is true with programming languages (and it's a an interesting challenge for open source technologies without the backing of a big marketing budget). So in the absence of marketing spend, there is likely a critical threshold where the population of current users makes enough noise (frequency and 'volume') to constantly promote the technology and attract new users. I don't think Haxe is there yet. But there is evidence of growth. I occasionally hang out in IRC channel #haxe - if you want to check it out and don't typically use an IRC client you can use the online one here. There is a fair proportion of lurkers as with any IRC channel, but there are also engaging discussions and regular participants with deep knowlege of Haxe and related technologies. But the one thing I have observed is that the levels of participants are at least double what they were a year ago, and the levels now are usually at least double the level of participants in the ##flash or #flex channels. I realise that comparing to flash/flex channels does not indicate anything in particular because there are a lot more online resources for flash platform support, and IRC is likely not a primary resource for flash/flex, but it does provide a reference point for #haxe channel activity. So there is definitely evidence of growth for Haxe (I wish we could see more indicative stuff - download counts by version, etc.). But I also understand the Haxe Foundation intends to invest time, effort and money on marketing this year, and if so, this will be the first time such a coordinated effort is planned, so I expect that will further enhance awareness and trial usage over what seems to be a burgeoning growth already.


In summary, I think this could be a really important year for Haxe, and on a personal level I certainly hope it provides more opportunities for me to offer Haxe coding services to new or existing clients. Most of my work is still Flex related, which I enjoy immensely, but I do like to keep my options open. In terms of moving towards 'html5', Haxe seems like a good way to avoid the disadvantages (that I see) with javascript while retaining flexibility to re-use code between different target platforms. I'm sure it's not the only way, but so far, for me at least, it seems like the best way to achieve both of those goals. At the time of writing, the latest Haxe release is 3.0 RC1, and there may possibly be one more RC before 3.0 release, although that is not confirmed yet. If you're an as3 developer and haven't yet tried Haxe, I absolutely recommend that you invest some time in giving it a try once 3.0 final is out. Make sure you leverage the Haxe community in terms of the google group and the IRC channel for support if you need it.

*If a developer steps onto the road and gets hit by a bus, what assurances are there that others are motivated enough and sufficiently familiar with the codebase to provide continuity of support, maintenance and future development?


Nice write up, I mostly agree, and finally have some big projects that are Haxe based which should keep me busy.  (If I get any extra Haxe work that I could send your way I'll flick you an email...)I'll add to the what you mentioned in the "Bus Effect" section ... a tonne of the work being done on the compiler now is being done by Simon Krajewski, just look at the activity on Google Code:  If the "bus incident" were to happen he'd definitely be able to keep going, and I'm sure once more people start sponsoring the Haxe Foundation we'll see even more developers working on it.Should be a pretty exciting year for a small haxe dev like me :)

Thanks for your comments Jason. It's great to hear you're well off the starting block with Haxe projects this year. And yes, Simon has made a huge difference in terms of momentum and progress leading up to Haxe 3, not only from his own code contributions, - which as you say, are substantial - but also in terms of coordinating others. If I'm not mistaken, his pretty much fulltime effort is due at least in part to support from the Haxe Foundation, which is great. And thanks for your offer of possible overflow work if it turns out you get overloaded with it, I certainly appreciate the thought. Let's hope we both get overloaded with it!

Add new comment

By submitting this form, you accept the Mollom privacy policy.