Cross-Platform Mobile Development with Haxe
"Mobile applications" are a necessity these days. Trouble is, when you want to write one, you ordinarily can't write just one. Every mobile platform has its own SDK, its own "favorite (or, only) language," and its own proprietary library suite and APIs. Thus, if you want to build "your app" for iOS and Android, say, you wind up creating two apps that share absolutely nothing with one another except appearances.
Native applications are always preferable, but traditionally they require totally-redundant development efforts, and the work of specialists who probably know only one platform well. You're not writing one application – you're writing two or more.
Haxe and "Transpiler" Technology:
Because the Haxe language is designed to generate source-code in a wide variety of languages – both "dynamically-typed" and "strongly-typed" – Haxe is "strongly typed." It requires the programmers to state their intentions more strongly in advance, so that it can detect logic errors (and, "simple tpyos") before they occur. Therefore, "if Haxe produces an output, the odds are quite good that it's correct."
But especially, Haxe is designed to generate source-code in a wide variety of languages and environments. Recognizing that "what you want to say" is the same in each (and every) one, Haxe isolates the language/environment specific issues away from your intentions. And, it detects your "liitle mistkaes" – how very costly such "little mistakes" can be! – before they actually happen.
Let's Take a Concrete Example ...
As an example from our own experience, we worked with an educational testing company to make-over their antiquated web application. We redesigned the format of the tests and of the associated on-line study materials to be XML-based, then were faced with the challenge of deploying this new system to the web, to Android-based tablets and to iOS-based tablets, all at the same time. (Schools, in the real world take, and use, what technology they can get.)
Each version of the app had to do basically the same thing: first, to accept test material from a secure back-end server and render it for the student. Then it had to also support a variety of on-line tools – calculators, compass and protractor, periodic table of the elements and so-on. Test progress had to be sent back to the server in real time so that a student could stop and resume work at any time and on any machine. (Batteries do run out, often at the most inopportune times.)
All of these requirements were the same for each platform, but the respective implementations were different. (For example, the web deployment was actually two – one which assumed Flash, the other which assumed HTML5.)
To write three (really, four ...) different applications would have been prohibitive, particularly given the short time constraints and very limited budget. But, Haxe provided an elegant solution which allowed us to construct all three deployments – and the server-side API with which all would communicate – from one Haxe source-code base.
(Plus, Haxe was also able to generate the server-side handler for this API!)
The resulting applications of course did not look exactly the same – we used API components which were native for each platform so that they "looked and felt right" for each one – but the application itself was, to our development teams, "only one application." We could create all of the logic just one time, with only small portions of the Haxe code being specific to any particular so-called "target." We didn't have to reconcile the differences between the platform because the developers of the Haxe packages which we were using had done so for us.
So, What's So Important About "Strongly Typed?"
One of the most important features of the Haxe language is that it is, as we say, "strongly typed." This means that the language requires the programmer to clearly specify exactly what "type" of data a particular variable may contain at a particular time. (Notice also that this concept is very-widely expanded, to include "programmer-defined types" as well.) This enables the language to provide a fundamental service: the "compile-time error."
Furthermore, these strictures allow Haxe to produce more efficient output source-code, in any language. Because the programmer has provided more information about his intentions, and because the source-code he provided has been verified at compile-time to conform to it, the output source-code can assume these things, as well.