haXe is a high-level programming language for web development. It can be compiled into .js files for JavaScript developers or into .swf files for Flash, and it also supports the Neko virtual machine. Before going into the details of haXe, I’ll explain how it came to be and how it is related to the evolution of Flash, ActionScript, and some of the other open source Flash tools. Let’s start then with a bit of history …
Flash for developers
Traditionally, Flash was a tool for designers, and programming was used for adding a little bit of “scripting” and interactivity to the different parts of a Flash project. That was ActionScript I. But when programmers began using the language and some designers started digging deeper into ActionScript, they began building applications that even Macromedia1 could not have envisioned: rich Internet applications, web games, complete content management systems, code-generated graphics… the list goes on. From the web developer perspective, Flash morphed from a tool for building ads and animations into a tool that could be used to increase the user experience on websites by doing things that were not possible in a traditional HTML-based website. Some of these Flash usages clearly went overboard (haven’t we all seen complete Flash-based websites that no one is able to use correctly?). But the most important thing is that web developers learned from their mistakes and began using Flash in the right places where it had the greatest benefit for the end users.
So, with developers adopting Flash, the development tools were found to be wanting. This wasn’t initially noticed, however, because most of the first Flash designers and developers were learning programming with ActionScript I and were happy with the available set of tools. But when developers with Java and PHP backgrounds started using Flash, they struggled with the IDE. Although they found some code-editing support in the Flash IDE, these developers were already used to their own powerful and customizable code editors or IDEs, and Flash was nowhere near as powerful or as easy to use.
What is nice when you are a programmer is that you can “scratch your own itch.” Some external ActionScript editors were built at that time (such as the popular SEPY; http://osflash.org/sepy). These editors were customizable enough for developers to find themselves “at home” and ready to write code. By adding some “hacks” to be able to remotely run the Build command in the Flash IDE, programmers were then able to “compile and test” their code, just like they used to do with other programming languages.
Watching the interests of programmers using Flash and understanding the need for more developer support, Macromedia introduced ActionScript 2, an evolution of the original ActionScript language. ActionScript 2 maintains backward compatibility with ActionScript 1, with the additional ability to define classes in external .as files. In addition to classes, ActionScript 2 adds the possibility to specify optional types for variables and functions, and the compiler will check that these types are correctly matched by the actual program. This is a kind of optional Java-styled type system, which is widely known among programmers coming from other languages.
With the introduction of ActionScript 2, Flash developers were now able to build bigger applications faster, thanks to classes and types that ensure good coherency among all parts of the code, meaning fewer bugs occurring at runtime. Although ActionScript I was (and is) still used for small Flash projects, bigger projects profit from using a higher-level programming language.
Actually, ActionScript 2 was not an entirely new language; it just added syntax (classes) and rules (types) to ActionScript I, so in the end ActionScript 2 code will be compiled into ActionScript I by the Flash IDE. Then that ActionScript I code will be turned into bytecode (binary low-level operations) that is stored in the final SWF file. The problem with ActionScript 2 was the time-to-test speed. With each compilation, the Flash IDE compiled all the classes, checked all the types, built all the graphical resources, compressed all the sounds, and did a lot of operations to build the final SWF file available for testing.
This required a lot of time, which increased with the size of the project—from a few seconds to sometimes several minutes spent building the SWF. And that had to be done every time you wanted to test your code! The Flash IDE added a cache system to speed up ActionScript 2 compilation, but it was found to be buggy and prevented users from seeing modifications being made until they cleared the ASO cache.
With long delays between each test, programming Flash at that time was not fun. Even the smallest change required you to wait, making you lose concentration and making the whole programming process painful.
The arrival of MTASC
In response to this, we created MTASC. MTASC was able to fix all these problems by taking a different approach to Flash compilation. Instead of having the compiler integrated into the Flash IDE, MTASC is a command-line compiler, which enables any developer to integrate it within an IDE. Instead of rebuilding the whole SWF for every compilation, MTASC just “updates” the SWF by replacing the old version of the code with the new one. With this single improvement, the whole team workflow for Flash projects changed.
Instead of having developers and designers working on the same FLA file, things were now clearly separated:
■ Designers work on the FLA and then build a SWF to hand to developers.
■ Developers use MTASC and the code IDE of their choice to update the SWF with their code and can directly test the modifications they make.
Although these improvements alone would have been helpful to developers, MTASC also uses an improved compiler technology—a language called OCaml—that enables it to compile ActionScript 2 code a lot faster than the Flash IDE compiler.
With all these great features, MTASC would have sold well among Flash developers. But it wasn’t my or my company’s intention to sell MTASC licenses.
MTASC stands for “Motion-Twin ActionScript 2 Compiler,” and Motion-Twin is the name of my company. We are based in Bordeaux, France, and we make a living by creating games. We are developers, and we use a lot of open source software such as MySQL, Apache, and PHP. Thanks to this software, we were able to get started without big initial funds, so we wanted to give back to the community what we got for free. That’s why MTASC was released as open source software, freely downloadable by everyone at the http://www.mtasc.org website.
MTASC was initially released in October 2004, and then version 1.0 arrived in January 2005, followed by regular releases up to 1.13 in February 2007. During this time, a lot of people started developing great open source ActionScript libraries. There was open source before in the Flash world, but an active community quickly formed around MTASC, which later became the OSFlash.org community because people were not talking anymore about MTASC only but about all the tools and libraries that were becoming available. The thing I could see during 2005-2006 was that having MTASC be open source clearly inspired a lot of people to work on open source software as well. MTASC seemed to play a catalyst role in the evolution of OSFlash, and that was a great experience that continues to this day.
ActionScript 3
In October 2005, MTASC was already quite popular and was getting really stable. Only a few bugs were reported, so releases were getting more spaced apart. Some experimental, nonstandard features were added, such as strict typing and typed arrays, but going further to bring more features to users would mean changing the ActionScript language. This was not possible, since one of MTASC’s goals was to keep compatibility with the Flash IDE compiler.
It was at this time that ActionScript 3 was announced.
The immediate question that every MTASC user asked at that time was “Will MTASC support ActionScript 3?” ActionScript 3 was something very different from ActionScript I and ActionScript 2; it had a new API, a new language with different features, no backward compatibility, a new virtual machine for faster execution, and so on. Implementing ActionScript 3 support for MTASC would mean rewriting the compiler from scratch. Doing so would be only an attempt to “keep up” with Macromedia. Also, MTASC was a success because it was improving things over the traditional Flash workflow. It was helping developers “scratch their itches.” With a new language and a new workflow, who knew what particular itch would need scratching?
Let’s look at the points that made MTASC a success and compare them with the new features that ActionScript 3 would bring:
■ Stand-alone command-line compiler: The ActionScript 3 compiler was also stand-alone.
■ Speed: The ActionScript 3 compiler was using a new Java-based technology, so there was a good chance that Macromedia (and Adobe later) improved things here too.
■ Free and open source: Most of the MTASC users were professional Flash users who already owned a Flash IDE license, so they wouldn’t save money by using MTASC and would not hesitate to choose the “official” compiler over the open source one if price was its only advantage.
After giving the subject some serious thought, I decided that MTASC should go another way. To innovate even further, more freedom was needed. That’s the reason why a new programming language was announced at the OFLA conference in October 2005.
That language would become haXe a few months later.
The birth of haXe
The original goals of haXe were the following:
■ Build a language more powerful than ActionScript 2 and ActionScript 3.
■ Be able to easily port an ActionScript 2 application to haXe.
■ Be able to use this language for Flash 6, 7, 8, and 9.
■ Be able to use this language for JavaScript/Ajax.
■ Be able to use this language for server-side programming, instead of PHP or Java.
The idea of supporting Flash, JavaScript, and the server in the same language was the most ambitious aspect of the proposal. In a traditional website, developers need to use a lot of different technologies: PHP or another server-side language to access databases and generate HTML, ActionScript to develop the Flash parts of the website, JavaScript to manipulate HTML and forms in the browser, and some kind of XML protocol to communicate between the different components when needed.
The idea of haXe was to be able to write all these parts using one single programming language and to provide transparent communication as part of the standard library. This would trigger a workflow improvement similar to the one MTASC brought about before.
When you are developing several parts of the website, you no longer have to switch between different languages during the development phase. You can have one language, with its standard library, working the same on every platform. Ifyou are developing as part of a team of developers, a single language will improve communication between members. Transparent communications will simplify protocols. And code reuse: the same classes can be compiled at the same time for the server and for the client side, when some data needs to be shared between the two, for example.
Also, for users who didn’t want or couldn’t make the “big jump” and use haXe for the whole website, haXe needed to bring enough features to improve their workflow. In particular, for Flash users, haXe needed to prove itself to be more useful than alternatives such as MTASC or ActionScript 3.
At the time of this writing, 16 months since the initial proposal was made, all these goals have been fulfilled, beyond all expectations.
haXe for Flash
Covering the three platforms of haXe—Flash, JavaScript, and Neko—would take too much time and goes beyond the scope of this topic. This topic will mostly focus on haXe for the Flash developer. It will introduce the differences between haXe and ActionScript and give a good overview of the haXe features and tools that help Flash developers get their jobs done.
Installing haXe
haXe is available to download from http://haxe.org. An installer is available for each of the main operating systems: Windows, OS X, and Linux. The installer downloads and installs the latest haXe and Neko versions, so it can also be used to upgrade a previous haXe installation when a new version is available.
Once haXe is installed, you are ready to use it and can start writing your first haXe program. The file extension of haXe files is .hx.
haXe IDE
The recommended IDE for haXe is FlashDevelop (http:// www.flashdevelop.org). Ifyou already have FlashDevelop 2 installed, then you can install the haxeFD plug-in, which is available at http://haxe.org/haxefd. The upcoming FD3 version will directly support haXe without the need to install a specific plug-in.
The following screenshot shows the FlashDevelop IDE with haXe support, with some autocompletion information.
Sadly, FlashDevelop runs only on Windows right now. But if you are not running Windows, you can also use your favorite editor to edit .hx files. Some support for others editors is available on http://haxe.org. Ifyou don’t find any for your favorite editors, try using a syntax mode such as Java or ActionScript 2 for a start. Since there are not so many syntax differences, it should be enough right now.
Hello, haXe!
The following is a typical “Hello, World” class in haXe/Flash. As you can see, it is similar to a corresponding ActionScript 2 class.
Save this class in a Hello.hx file.
Now, you have to compile this class by using haXe so you can get a SWF file. Ifyou are familiar with MTASC or other command-line compilers, you can open a command-line console, go to the directory where the Hello.hx file is saved, and run the following command:
This creates a hello.swf file that, once opened with Flash Player or in a web browser, displays the magic sentence.
HXML files
There is an easier way to use the haXe compiler. First, you have to create an HXML file and put the different command-line arguments inside it, one per line. Here, for example, is the hello.hxml file content:
Save it into the same directory as your Hello.hx file. Ifyou are on Windows, you can double-click it to start compilation. This will open a console window that will run the haXe compiler. If errors occur, the console will display them and wait for you to press the Enter key. If no error occurs, then the console will close as soon as the compilation is finished.
Double-clicking HXML files is available only for Windows users, but you can run the HXML file from the command line by simply doing this:
This results in the same output as the previous command.
Displaying the SWF
Once the compilation is successful, you should have a hello.swf file in your project directory. This is the compiled code that was produced by the haXe compiler. It includes the Hello class as well as the basic haXe library that extends the Flash standard library.
To display the SWF, you can double-click it if you have the stand-alone Flash Player installed, or you can put it into an HTML page such as the following:
Save this content in the hello.html file, and open it in your web browser. It should display the trace that was done in the Hello.hx file.
haXe trace
Please notice that the trace itself is different from ActionScript. First, the trace is directly displayed on the screen. This is a default behavior, and it can be customized. Also, the trace displays both the file name and the line number where the trace call was made. This gives useful information to the developer to quickly find where the error messages came from.
Now, it’s not always easy to have a lot of traces being made on the screen while testing a SWF. For ActionScript 2, several programs exist that capture the traces into a separate window. For haXe, you could also use these programs by redefining the haxe.Log.trace method, but there is already a very good alternative directly available in the haXe standard library: haXe Firebug traces.
To use the haXe Firebug traces, you need to install the following software:
■ Firefox, available from http://getfirefox.com
■ The Firebug plug-in for Firefox, available from http://getfirebug.com
Once Firebug is installed, restart Firefox and then modify the Hello.hx file with the following content:
Save and compile again, and open the hello.html file in your browser. You can see the trace by opening the Firebug console with the F12 shortcut or with the menu options View > Firebug. Then navigate to the Console tab, as shown in the following screenshot.
If you want to disable all traces in your program, you can compile with the additional option -trace no in the hello.hxml file.
You have seen so far how to install and set up haXe and how to display traces. You will now learn about the specifics of the haXe language, including what is different and improved compared to ActionScript.
haXe vs. ActionScript
haXe and ActionScript are related. They come from the same family of object-oriented programming languages, and their syntax comes from the C++ language family.
Since the goal of haXe was not to reinvent the wheel, most of the programs you wrote in ActionScript will compile and work the same way in haXe. However, since the language has some differences and makes some improvements over ActionScript, there will always be some changes needed in order to compile your code in haXe.
