I've used Haxe in several production projects, and if I'm starting a new code-base from scratch I would pick it again. (I prefer type system, the cross-compilation options, and the meta programming)

But if you're migrating an existing code base, TypeScript has a more obvious path forward. Because TypeScript is a superset of JS, it means that all of the JS files in your project will be compiled by TypeScript as is. And you can add the extra typing information as you go, it doesn't have to be an "all or nothing" transition.

Compare to Haxe, where you have to create a separate *.hx file, with a slightly different syntax. You can either translate all of your code (a massive undertaking), or type external files as an `extern Class`, or just use `Dynamic` (equivalent of TypeScript's "any"). But all of these involve a little bit of work for every single part of your code base, so it's going to add up.

From what you say most of those problems are just syntactical, isn't it? Somehow I started to believe that it is a matter of visibility and self selling skills in the haxe community.

The problems you mention seems to be possible to solve with software (AST generation and transformation) however it still has to be done. Let's hope we will see soon a project like that in haxe-land.

You are right that the difference is syntax, but the thing is, JS syntax will always be different from Haxe syntax. You'll never be able to use "jQuery.js" as valid Haxe code, but it is valid TypeScript code.

There might be some interesting possibilities. For example back2dos has an example of Haxe seamlessly integrating with external ".as" files on the Flash target. This could be conceivable for other strict languages like Java or C# too. You might even be able to seamlessly integrate with ".ts" files, because they have some typing information. (That would be a fun project!)

But JS dynamic typing can be pretty crazy, and I'm not sure how feasible it is to be able to infer type information from JS source code without special type hints. It would end up just calling everything "Dynamic", and then you're getting no benefit.

Well, for one, Typescript is a superset of Javascript, meaning that all valid Javascript syntax will compile properly when passed through the Typescript compiler. This removes the need to rewrite 10k lines of code in another language, even if syntactically similar. Avoiding that overhead is a huge time saver - Javascript and Typescript are simply much closer than Javascript and Haxe, making the time savings a strong incentive.

You're talking about two different things. Haxe is a different language, while TS is a superset of JS (all JS is valid TS).

JS -> Haxe requires rewriting 10k lines before the program will run.

JS -> TS requires changing the file names, doing some imports, and adding "any" in a few places. The program will then run, and type information can be added gradually.

I do not see that much of differences between Haxe and JS, mostly because Haxe is a superset of EcmaScript. However the process is not that automatic because TypeScript is more permissive I would say (though there is already a convertor from typescript to haxe: ts2hx).

But that said, I am not really that much experienced with TypeScript.

According to Wikipedia, Haxe is not a superset of ES:

"Haxe is similar to ECMAScript, although almost no ECMAScript code will run on Haxe without modifications."

haxe have some incompatibility with syntax js. like don't support classic for and in if statement null must be explicited (you must do if (x==null)). but thanks to macros the porting of js generic more simple.

Is it easy to partially move things over to haxe? As in just translate one js file to haxe and have it properly populate the global namespace so that other js files can still use it?

It is easy enough to expose your classes and types from Haxe into the global namespace [0].

And it's easy enough to require() external JS code and use it seamlessly in your Haxe code.

What's not easy yet is using Haxe to generate small modules, so some modules in your codebase are written in Haxe, and some in JS (or Typescript or anything else). By default Haxe will output one big js file per compilation. The compiler is very configurable, so in theory you could output ES6 modules instead, but I haven't seen it done yet. (Though, there is a generator for outputting your code as AMD modules instead of one-big-JS-file [3], so it's definitely possible). But it's not easy yet, and that's why I think that for now migrating an existing JS codebase to Haxe would be harder than migrating it to TypeScript.

[0]: http://haxe.org/manual/target-javascript-expose.html [1]: http://haxe.org/manual/target-javascript-require.html [3]: https://github.com/explorigin/modular-js

Yes, you can expose Haxe classes so you can use them as any other API from JS. There is also the option to declare externs for existing JS and the require function.

It's a catch 22: relatively few people use haxe (that's purely guesswork from me) and it attracts less people because of that. I see marketing as one way to break that loop but there are other ways like offering something very useful and unique or being far ahead of the curve on something very important (like performance).