
From AS3 to Haxe - johnfn
http://www.grantmathews.com/43
======
JLM_
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.

------
Father
Another good feature I didn't see mentioned is haxes' quick memory access.
<http://haxe.org/api/flash/memory> It's basically an api for the opcodes which
adobe alchemy used if you compiled c/c++ to flash. More on it here
<http://ncannasse.fr/blog/virtual_memory_api>

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

~~~
johnfn
Thank you.

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

~~~
NetMonkey
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.

------
nickmain
The Haxe macro system is also pretty powerful.

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.

~~~
georgemcbay
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.

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

Related blog post here: [http://primesolid.com/blog/archives/Full-page-flash-
video-ba...](http://primesolid.com/blog/archives/Full-page-flash-video-
background/)

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

~~~
dheavy
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.

------
neovive
Haxe is very promising in the world of game development. I really like some of
the off-soot projects such as Stencyl 3.

