I'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.
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.
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.
*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?