Haxe VS AS3 VS JS Comparison Chart
Posted on Aug 21 2011
A simple comparison that say it all :
AS3 | Javascript | Haxe | |
---|---|---|---|
Compile to Flash | Y | N | Y |
Compile to JavaScript | N | Y | Y |
Compile to C++ | N | N | Y |
Compile to PHP/NekoVM | N | N | Y |
Language Features | |||
Native iterators | N | N | Y |
this Closures | Y | N | Y |
Conditional Compilation | N | N | Y |
Macros | N | N | Y |
Community-Driven | N | N | Y |
Type system Features | |||
Static Type System | Y | N | Y |
Type Inference | N | Y | |
Generics | N | Y | |
Enums | N | Y | |
Typed Structures | N | Y | |
Inline Functions | N | Y | |
Standard Library | |||
Xml | Y | N | Y |
Serialization | N | N | Y |
Reflection | N | Y | Y |
Maybe I forgot something ?
16 comments
Haxe kick ass ! nothing else to say !
I'm curious, why would you state that AS3 doesn't have conditional compilation, serialization or reflection?
Haxe is many unique/richer features but your comparison chart isn't totally fair:
- Flash has: reflection, AMF serialization, (some) conditional compilation and arrays generics, and arguably the best native XML support,
- Javascript has: a few specialized typed arrays, JSON serialization.
That said, imho, haxe problem really isn't about features - it's about (the lack of) strategy. But we already discussed it many times :)
I agree with Phillipe, I like both Haxe and AS3. But we can't just compare them on features.
Hi,
I am not sur about the need of strategy, must be an interesting discussion :)
A few ideas:
What about execution time, it should appear here right? Also the browsers and platforms they target
There are sources available for haxe compiler but not as3
The "community driven" aspect of haxe and js? And what about lisences?
The creation dates and histories of these languages would be nice too...
The learning curve when you do not know web dev?
This chart is a very good initiative for a better communication!
JavaScript does have native iterators, ala __iterator__ generators, and ECMAScript 5 has native iterators via Proxies. JavaScript has native XML parsing and serialization support (E4X), and for normal ECMAScript in a browser, there's the DOM (DOMParser and XMLSerializer). As for "community-driven", I can hardly see how it's not. Development of ECMAScript is done over an open mailing list and wiki.
I get more impressed by these kind of list from the community than by its maker :p
Github project
Javascript : 17597
Actionscript : 921
HaXe : 55
How about:
finally (as in try/finally): AS3 Y, JS Y, Haxe N
When I noticed this was missing, I was shocked, so I skimmed through Haxe source to see what was used instead, say, for guaranteeing files get closed, and it looks to me like no guarantees were in place at all. Sorry no time to review to give a pointer to source code on this at the moment. It was some while back that I went through this exercise.
No RAII that I could find, either. Exceptions are worthless without some way to guarantee cleanup (and the pain of writing cleanup calls twice everywhere is horrific).
Or am I missing some feature in Haxe that handles this?
I have other issues, too, but this is one of the most glaring, in my opinion.
And also
Possibility to have the same laguage on the server side : as3 N, Js Y, haxe Y
Share the classes with server side scripts : as3 Y (amfphp) js N haxe Y
Another key feature is the popularity of a language, and the size of its community, as pointed out by @oizo.
This is probably the biggest lack of Haxe : the technology is good and its cross-technology feature is unique, it "just" misses a big community like the one of Node.js for exemple, which is very dynamic and innovative, with its hundreds of modules.
I don't know what could be done to increase Haxe popularity ; but it's the biggest feature to work on, imho.
Adobe's asc compiler was released as part of the open source Flex tools. The compiler can be used to compile JS into Flash. They also released an interpreter for the abc code, to run from console.
Current JS implementations do have typed structures, such as the Typed Array semantics. That said, the JS spec does not. They're part of the WebIDL implementations included in most engines.
I don't know if you're just trying to advertise Haxe, but whether you are or not, it's making me want to use it!
yes nicolas you forget something...
haxe has good features, and it's not necessary to forget others ones
...some come from targets,
AS3 have
reflexion via describeType and JSON avmlPlus
serialisation via IExternalizable / BiteArray (AMF is serialization)
AS3 can compile to iOS plateform android... Air target windows and Mac... Air apps are not native binary but platform are targeted
AS3 have conditional compilation...
there are example of AS3 running on serverside version of tamarin (a uggly gadget like Node.js)
C++ code can be handled by avm2 via Alchemy and a lot of IR generator to llvm are developped... we can imaging java targeted to avm2 via gcc in near futur...
what about native extension... haxe and AS3 via Air have both
AS3 sound API come from community request ... a simple NO is too strong about community driven section..
for each is basicaly an iterator over array and dictionnary
ha and AS3 have native hashMap via Dictionnary
;)
@Tom: finally (as in try/finally): AS3 Y, JS Y, Haxe N
Did you check Haxe documentation http://haxe.org/doc/cross/exceptions
So: AS3 Y, JS Y, Haxe Y
@Sam The documentation explicitly leaves out any mention of a "finally" mechanism. So no, Haxe does not have "finally" (or at least the documentation does not specify it).