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.

Comments

Dear lord why

[Anonymous Coward]

Compiling to JS is like having a shit for dinner, you're doing it wrong.

Compile to JS vs WebASM

[Dutch Gun]

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. I think it will be a nice day when developers can choose a web language based on its merits rather than its ubiquitous nature.

Re:Compile to JS vs WebASM

[thisisauniqueid]

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.

Not that bad

[monkeyxpress]

I know this is going to get a lot of hate, but JavaScript is really not as bad as people make out. There are some stupid design decisions (mostly around scoping and built-in type consistency) but once you know what these are it is pretty easy to work with them. The main problem I think most people have is that it does not really offer any sort of hand-holding in terms of how you should structure your program. But in a way it is quite beautiful how you can create usable frameworks for OO, imperative, or functional programming with the same language. The problem I mostly see is that people get stuck with a poor design decision, but rather than having to re-factor their object structure (like C# would force you to do), they can just hack in a solution that breaks basically every principle of good programming imaginable. They then dump this solution on the world and declare it is because JavaScript sucks. The real issue is that they are bad programmers who came up with a poor design and then used the (somewhat excessive) flexibility of JavaScript to get them out of a corner. Same thing has happened in C/C++ for years.

I really don't think JavaScript should have become the language of the web, but competent programmers shouldn't listen to all the hate that gets spread around. It is a decent way to introduce yourself to a lot of new programming concepts if you've come from a static OO language background. Once you understand some fundamentals CoffeeScript, TypeScript etc are pretty straight forward and their applicability is obvious.

For what it's worth, if you are doing large programs then something like TypeScript can be very useful. The problem it solves is really an issue with dynamic languages in general though, rather than JavaScript. There are ways to create large maintainable code bases with a dynamic prototypical language, but sometimes the classic OO model just fits a problem better.