Slashdot Mirror
Compiling to JavaScript: TypeScript vs. Haxe
lars_doucet writes: Released in 2012, Microsoft's TypeScript is perhaps the best-known "compile to JS" language, but it wasn't the first. One of the earliest was Haxe, whose JS target first appeared in 2006. In his illuminating article, TypeScript vs Haxe, Andy Li gives an excellent rundown of the two languages' various merits, but the bottom line is: "Existing JS developers will favor TypeScript as they are more similar in many ways. They can utilize their existing skills immediately. Non-JS developers with backgrounds like Java/C# or even from the functional programming world will appreciate Haxe more since it fixes a lot of weirdness of JS." The full article includes an excellent rundown of the type systems, syntax, scope handling, compilers, and overall language design philosophy.
How is that web assembly project coming along? It seems like a perfect fit for alternative languages like this instead of having to compile to JS.
WebAssembly is not currently a suitable target for Javascript compilation, because it lacks a garbage collector. Only languages that can base themselves on (the equivalent of) malloc/free can currently target wasm. Eventually garbage collection facilities will be provided, but they're not on the immediate drawing board, and even once garbage collection is possible, it's likely to be a long time before JS->wasm approaches the performance of v8 or similar. (Note that asm.js doesn't do garbage collection either.)
The nice things about wasm are (1) it gives the creators a chance to re-invent the web runtime from the ground up (e.g. native threads will be there almost from the start), (2) languages can evolve independently of the web platform, and the web platform becomes language agnostic, and (3) *all* the major players are fully on-board.
One of the nicest features of wasm, in my opinion, is that the intermediate representation is an AST of expressions to be computed. This is a far more sensible and flexible IR than some stack-based or register-based VM bytecode system. My prediction is that wasm will become the preferred compilation target for desktop/server applications, not just web applications: the same toolchain will be used to generate binaries for running in server containers as well as within a browser.
What's actually wrong with Javascript as a compile target?
Where to even begin... maybe the fact that Javascript doesn't even have integers? Or that (other than in asm.js) it doesn't support C-style malloc/free heap-based allocation? Or that (again, other than in asm.js) the runtime is garbage collected? Or that it doesn't properly support threads (a huge deal given the demands of modern computing), or sharing of memory between WebWorkers and the main thread?
Sure you can argue the problems with the language itself but when it's a compile target all of those are abstracted away, the thing that is important then is speed. And it's not exactly slow, could it be faster? Most likely. Does it need to be? For most cases probably not.
Javascript wastes petawatt-hours of energy per year across the globe due to its computational inefficiency. That means your power bill is higher than it could be, your phone battery doesn't last as long as it could, and polar bears are dying in the Arctic because Javascript has been deemed "efficient enough".
UI latency irks our subconscious. Once we have native WebAssembly support in browsers, and a significant percentage of the major websites have moved across to compiling from better languages into WebAssembly, those new sites are going to feel amazingly snappy, and people aren't going to want to use old Javascript sites, because they'll feel janky.
Um, I know that ECMAScript "IS" Javascript. Typescript is becoming much bigger than Microsoft itself. The only Microsoft products I have ever been interested in using before Typescript are their keyboards and mice. Typescript is, quite shockingly, actually really, really good, and Microsoft, even more shockingly, is suddenly becoming a really good citizen in the open source / Free software world, at least as far as some projects are concerned, and the stuff they're putting out there is really good. (See also: Visual Studio Code.)
Microsoft have also, quite suddenly and inexplicably, become extremely open about the development process of some of these newer open source projects, and they are working with, and responding to, other key players in the open source ecosystem. (Google adopted Typescript for Angular2, and Microsoft merged Angular's "AtScript" extensions into Typescript, and made Typescript a strict superset of ECMAScript 7, in order to satisfy Google's requirements, and to make Typescript a better player in the Javascript world. Microsoft was a key presenter at, and participant in, ng-conf 2015. etc. etc.