JavaScript runs in all browsers, but its native development environments are impoverished. These facts make it an attractive target for compilers from other languages, and for extensions and enhanced tooling.
We have discussed a couple of languages that compile to JavaScript: Google's Dart and Microsoft's Typescript. These are but two well-publicized examples of a much larger phenomenon. The perceived deficiencies of JavaScript as a language and as an environment for development -- especially large-scale development -- have spurred a number of individuals and groups to try to improve on what JavaScript can offer on its own.
Let's begin with what may be the master list of alternatives to JavaScript. At this writing it lists 134 projects, languages, and packages that relate in some way to extending or improving JavaScript. The list includes everything from the semi-official testbeds for next-generation ECMAScript, to backends for various language compilers, to tools for compiler writers such as abstract syntax-tree generators.
Andre Rieussec has posted a long piece, the first in what promises to be a series, on using JavaScript (and the HTML5 Canvas element) to develop games that run in-browser and cross-platform. He begins with a review of some of the categories of compile-to-JS tools: supersets of JavaScript, and new and existing languages that produce JavaScript out the back end.
Two oddballs in this mix are Emscripten and JSIL. They work from intermediate languages to produce JavaScript. Emscripten translates from LLVM bitcode, which many compilers can produce; and JSIL generates JavaScript from the native .NET executable format, CIL bytecode, which can start out life as C# or VB code.
Rieussec outlines some of the motivations behind the JavaScript enhancement projects:
Rieussec concludes his piece with the beginning framework for a game developed in C# and Visual Studio but delivered via JavaScript courtesy of the Blade compiler. He promises to put more flesh on the bones in future posts.
One downside of generated JavaScript
Last spring Stuart Langridge posted an argument against the rise of generated JavaScript. The main point is that the practice breaks the usefulness of View Source, which is the universal way everyone involved with Web development learns new tricks and techniques. (It's also the way that many of us learned Web development in the first place.) "If you're trying to learn from code that isn't the code that the author actually wrote, you're always going to be at a gargantuan disadvantage," Langridge declares.
The sheer number of compile-to-JavaScript projects indicates that Langridge is not likely to win this argument. Convenience, expressive power, and leverage for the developer are going to trump the altruistic motive of improving ease of learning in the Web commons.
Related links