Student Impressions of haXe
Two of the students in this term’s consulting course, Robert Beghian and Tom Plaskon, spent the term working with haXe. Their impressions of it are below…
HaXe is a high-level, object-oriented programming language for the development of web applications. Programs written in haXe can be compiled on several platforms including Javascript, Flash, and Neko. For this reason the official website calls haXe the “web oriented universal language.” HaXe’s syntax is similar to the Java and ActionScript syntaxes. However, despite these promising characteristics, haXe has many drawbacks. I will focus on three areas in my critique of haXe: documentation, tool support, and libraries.
The API documentation on the official haXe website is difficult to find and incomplete. The API documentation is not even present on the top-level navigation of the website (even though there is clearly enough room). To find the API one must scroll through dozens of screens on the reference page, to find the link to it at the very bottom (with no prior mention that it is even present there). Many of the API pages are completely without any explanatory text. The methods provided by a library are merely listed, leaving one wondering what their function is, and what the purpose of the library is. There is very little in the way of documentation offered anywhere other than the official site. Even worse, Amazon only lists a single book on haXe. The product information page details the book as having 600 pages. It would be helpful if the entire haXe website provided 100 hundred pages of documentation, especially considering is not available elsewhere.
The tool support in haXe is very poor. Although there is a Eclipse plugin for haXe it barely adds any functionality at all. It does not support the opening of definitions nor does it even have a hot-key for compilation. This has to be done using the context menu on the project. However, these are fairly minor issues in comparison to the biggest shortfall of the tool support for haXe, namely, that it does not have a symbolic debugger! The only method of debugging a haXe program is to catch exceptions and print them with trace statements. Furthermore, exceptions are not even automatically caught at the top of the execution stack, so if an exception does get that far, the programmer will simply be displayed a blank, white screen. Even Javascript has an error console built-in to every modern browser.
Lastly, I would like to discuss haXe’s libraries. The standard library contains only the most basic of XML support, allowing you to parse an XML string into a tree, and navigate this tree using the familial attributes of a node (parent and children). There is no built in support for any of the W3C DOM features, including even the lack of getElementById and getElementsByTagName functions. There is only a single library, by Daniel Cassidy, which implements the XPath W3C standard. This library is in an alpha state and although I could find the documentation for it, I could not find out where to download the library. In comparison, Python has several XML libraries (PyXML, libxml2, ElementTree, and 4suite) all of which have full XPath support. Web programmers expect a language to have excellent XML support. The official haXe website lists twenty-one libraries. Ten of these libraries are by two authors. That is to say, nearly 50% of the all libraries listed on the official website were committed by two programmers. Thankfully, there is a standard MySQL library, or I would say that would be the killing blow for the mainstream use of haXe.
Although haXe has many desirable traits (including support for many platforms and familiar syntax) one can only assume that the claim of it being the universal language refers to its multi-platform support and not its pervasiveness. The contributors to the haXe community appear to be few and this shows. In comparison to Python with its endless libraries and PHP with its plethora of user-submitted samples and tutorials (the bottom of every page on PHP.net contains a wealth of very helpful, user-submitted information), haXe is likely to be found wanting by the average web programmer. HaXe’s lack of good documentation makes it difficult for new users to quickly learn, while it’s lack of tool support (especially a debugger) and libraries make it difficult to be very productive in.
hmm… if the docu is really bad, i dont want to try it
i have had enough of promising languages that go without docu. creators should realize that docu is not only about documenting, it is about teaching people just as well (teaching how to use your stuff)
anyway guess i will simply postpone my desire to play with it for one year and see if things are better
ElementTree does not have full XPath support. It’s very basic even in the 1.3 alpha version.
Why did they use haxe? Did they have to?
For the sake of balance, I’ll offer a few positives to go along with the negatives…
We used Haxe because Flash is proprietary, and our client wanted an open source compiler. The other alternative found was mtasc, which is slower and only works with Flash Player 8 and earlier.
The Haxe syntax is very similar to ActionScript but often results in much cleaner code – it requires strict typing, but has a modern type inference system.
The documentation on their site is… sparse… however most of the classes you are using are found in ActionScript. And, luckily, Adobe has pretty good documentation for those:
http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/
If you simply want to play with the language, Haxe is more then ready. If you’re looking to do some heavy-duty work with it, I would suggest you hold off for a little while.
Your comments are valid on several aspects : current website is lacking organization and API documentation is incomplete. These two things are currently being addressed by building a new website which will be entirely reorganized for better productivity.
OTOH, for good IDE support you should either use FlashDevelop or TextMate bundle which are the two most advanced IDE for haXe so far.
Concerning debugger, you can debug Flash9 content but you can’t debug JS since the browser doesn’t have a JS debugger included.
You can trace and have exceptions stored in the Javascript console (or Firebug one if you’re using it) and when compiling with -debug you will get the stack traces as well. This is as far as things can go with Javascript.
I have been using haXe as an alternative to the Flash CS3 IDE and compiler. In addition, my interest was peaked by a language that seemed to be groomed for best practices (unit testing, strong-typing, etc.). After about 5 months of development, of which I produced a Myspace application in conjunction with a Flex UI (currently the app receives hundreds of hits per second on server), I have been pleasantly surprised by not only haXe’s ability to conform to best practices, but it’s ease of use.
I use the FlashDevelop IDE in order to compile my haXe projects and have found it light years faster than the Flex (Eclipse) IDE and SDK compiler. It’s also much faster than the CS3 IDE/compiler, too. More importantly, the projects created with haXe are extremely light. Flex tends to add tons of extra junk that makes it bloated and slow.
Support for haXe is there, you just have to look for it. I used PureMVC which fully supports the haXe language. When I need and answer, I have been able to find it in the haXe lists (lists.motion-twin.com).
I do agree that there is not enough documentation, but the book is quite good (mine is bent and battered) and the rewards are definitely there.