Neko is also worth a look, it is another solution from Nicolas ( haxe's creator ) and can easily be targeted from haxe, it is often a more robust solution than PHP in the form of Neko vm, the concept of targetting PHP and then remapping to Neko, when traffic increases is really powerful.
http://nekovm.org/
Spod ( ORM mapping ) is being unified between backend targets, allowing Haxe3 to work easily with databases in an OOP structured approach, while still allowing the same code base to compile to Neko and PHP solutions.
http://haxe.org/doc/neko/spod
Haxe remoting allows objects to transfer between targets, so from flash, to Javascript or to PHP/Neko/Nodejs.
http://haxe.org/doc/remoting
There are many other examples of haxe/haxe related workflows that make the haxe eco system worth exploring, my thoughts are that you probably won't want to work directly in any other language after using Haxe, I certainly resent clients that want me to use as3 and the thought of raw js is enough to send one to an early grave. Really worth using haxe a pragmatic practical choice for rapid lite developement.
I really enjoyed reading this - Haxe is one of those things I've been aware of for a long time, but there's precious little discussion about it, so it's nice to read a technical analysis of some of the features.
Don't forget the 'inline' keyword for functions, it saved my bacon in some audio-processing code that was starting to choke, repeating stuff for every sample in a tight loop - copy-pasting away the function calls wasn't really feasible - type 'inline' in a couple of places, now it's tidy and fast. I came more-or-less directly to Haxe as a better ActionScript, and had to check whether I could have done the same in AS3, and found that no, it doesn't have that keyword. I was so relieved at my language choice just then, else I would have been screwed. (Still half expecting for someone to tell me I've missed some aspect of ActionScript there.)
The Polygonal data structures library (http://polygonal.github.com/ds/doc/) is also thoughtfully designed with STL-like abstractions, and excellently documented right down to time-complexity of methods being stated. If you ask me it should be folded into the Haxe standard library. One admitted difficulty I've had using the standard data structures is not really being sure what the most efficient one to use is, when even if you're sticking to one language - say JavaScript - your 'array' could really be a linked-list underneath and vice-versa, and if you're writing to make use of Haxe's cross-platformability (which I haven't yet) then God knows where you actually stand.
It's now (finally) possible to inline with newest actionscript compiler and it's included in the recently released FlashBuilder 4.7: http://www.bytearray.org/?p=4789
Just compile with the -inline argument. The compiler sometimes chokes in some rare cases where it can't inline, and it makes debugging much harder as the line offsets don't match the source code anymore. But the performance gains can be huge as function calls are rather expensive in Flash, and you can just debug without the -inline argument.
As well as consuming Haxe AST fragments, macros can have compiler-managed dependencies on external files. We have an Omnigraffle parser that can run within the macro environment and do some simple code generation from diagrams.
He mentions macros briefly, but they are certainly worth noting more prominently.
FWIW, the AS2 target is also quite solid. I did a lot of haxe programming targeting AS2 when I was working for chumby and we were using AS2 long after the rest of the Flash-using world had moved on to AS3. haxe was a lifesaver because AS2 was a lot more terrible than AS3 (IMO).
I had a very complete reactive UI layout and data binding system similar to the one in Flex but written in haxe, mostly using macros.
The UI was described in XML like:
<Panel id="rootPanel">
<Panel id="header"
width="{rootPanel.width}"
height="{rootPanel.height * 0.1}">
... (bunch of header controls described here) ...
</Panel>
<Panel id="content"
width="{rootPanel.width}"
height="{rootPanel.height - header.height}"
y="{header.height}">
... (bunch of content controls described here) ...
</Panel>
<Code>
... (bunch of arbitrary haxe code pulled into the class the XML is describing) ...
</Code>
</Panel>
The macro system would, at project build time, pull in all the XML files, look at the attributes, figure out which ones had dynamic data binding and would set up closures for them which would register to be called if any of the data items they depended upon were changed. Since all of this was set up at compile time using the haxe macro system, the app developer didn't have to worry about it when dependent properties changed, it just worked like magic. (Though it also did have a runtime API so the developer could register a closure to be called if particularly object properties were modified).
This is of course all very similar to what Flex did with code generation and data binding but the system was much lighter-weight as it was implemented in haxe itself and the macro system allowed it to do a lot of fancy type determination that kept the overall logic quite simple.
It could target AS3 or AS2 prior to the end of working on it since we did eventually ship a beta firmware for chumby devices to run ActionScript3/FlashLite4 code.
I haven't really had occasion to use haxe since, but I highly recommend it to anyone who would otherwise be stuck using the 'native' languages of a runtime like Flash or JavaScript.
In the past I've had to build minor widgets for the Flash runtime like a chromeless video player, or a 'sound manager', and Haxe has worked out great.
A 'text-editor and compiler' environment, no licence fees, and none of the battling with the timeline that I have to do when I work in Flash. I'm a Haxe novice, but still found it much easier than Flash (with which I've got a fair bit of experience).
Not saying it's better in all cases than using Flash, but it has suited my needs much better.
I've been interested in Haxe for some time, but I've never really felt the urge to start anew. I have released a few AS3 games using a loose common engine. It was relatively painless to port from AS3 to pure JavaScript. I think it's time to make the jump to porting it to Haxe to see if I'm ready to develop full-time in Haxe.
Yes, I agree.
Haxe has been that nifty little platform and language I've been contemplating on the side, tried a little, but never really had the opportunity to use seriously.
