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.
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