
TypeScript vs. Haxe - larsiusprime
http://blog.onthewings.net/2015/08/05/typescript-vs-haxe/
======
nothrabannosir
_Of course, the ES6 block scoped let declaration is also supported by
TypeScript. But it is kind of a pity that TypeScript has to maintain the old
scoping strategy of var and goes to support let instead of “fixing” var
declaration directly like Haxe…_

This quote fits the spirit of the article well, in missing the most important
point about TypeScript: the driving principle of TypeScript is, and always has
been, to resemble JavaScript as closely as possible. The point is to be a
superset of JavaScript. How would you do that if you start changing the
semantics of existing constructs?

It's just one quote, but the rest of the article carries the same smell.
Telling omission: the comparison between the compiled versions of the
presented code snippets. TypeScript code emission tries to resemble the
original JS. How does Haxe hold up?

I do not doubt for a second that Haxe, as a language, is better than
TypeScript. I don't know it, but it's not a hard task. Almost any language is
better than TypeScript. The only one that isn't, in fact, is JavaScript.

Being a good language was never the point of TypeScript. Just being better
than JS, while resembling it so much that nobody in their right mind could
make a compelling argument against it, but in favor of JS.

EDIT: larsiusprime makes a good point, which I would have noticed had I
actually read the conclusion instead of stopping half-way through: the author
already addresses this.

~~~
larsiusprime
The article fully acknowledges this:

"However, at the core, TypeScript and Haxe have different design philosophies.
TypeScript is a superset of JS. It means it cannot modify the existing JS
syntax and semantics. It adds a static type system and some new constructs
(e.g. “proper” class/interface). It is not interested in optimizing the
program in any way. Haxe looks like JS, but is more similar to other popular
compiled languages like Java/C# regarding to semantics, the use of types, code
organization, and optimizations. It also brings in a lot of advanced
functional programming concepts.

Which is the better compile-to-JS language? It depends. Existing JS developers
will favor TypeScript as they are more similar in many ways. They can utilize
their existing skills immediately."

EDIT:

As for how Haxe holds up on generated JS code, you can see for yourself online
right here:

[http://try.haxe.org/](http://try.haxe.org/)

~~~
rictic
Playing around with that site, I think that the parent had a good point in
bringing up what the output would look like. The output of Haxe is compiler
output. Variables are renamed and in some cases elided. If Haxe wasn't working
out for a team, they could not easily convert to javascript, as their
generated code would be illegible.

Typescript on the other hand produces the ES5 that I would have written if I
wasn't using Typescript. Variable names are kept, nothing is elided. You can
even ask Typescript to translate code with type errors and it happily
compiles.

------
neals
I love Haxe so much. I have been using it as a blazing-fast replacement for
Gulp. I have < 10ms build times for large js libraries, where Gulp would take
a second or 2. I like to do alt-tab F5 really fast after I save and thanks to
Haxe I don't have to wait a second :).

I wrote a lot of features that I used to need in gulp (+ plugins) in Haxe,
which is a great way of learning to use it, and a great way to find out how
nice it is to have type safety.

Also, the language allows a simple JS / AS dev like me to build multithreaded
apps that carry extremly heavy weights.

~~~
drethemadrapper
Could you share more information about writing gulp (+plugins) in Haxe?

I can't wait to learn it.

------
klibertp
I wrote a tiny bit of Haxe some time ago as an attempt to learn the language:
[https://github.com/piotrklibert/dirlist/blob/master/Main.hx](https://github.com/piotrklibert/dirlist/blob/master/Main.hx)
\- it's a part of my larger series of blog posts, I just didn't write the one
about Haxe yet (I have Nim and OCaml covered already).

As a language Haxe has some interesting features (although when compared with
the other languages I chose (Nim, OCaml, Dylan, C++, Racket, Tcl...) they look
fairly normal). There's an overview of Haxe features here:
[http://haxe.org/documentation/introduction/language-
features...](http://haxe.org/documentation/introduction/language-
features.html)

Haxe is a really good language. It's dynamic, reflective language with static
type system with local type inference. It supports GADTs and pattern matching,
along with the usual exhaustiveness checks. It allows for adding methods to a
class from outside (a `using` keyword). It has hygienic macros similar to
those of Dylan, Elixir or Sweet.js. It's type system gives you control over
variance of types, which is really nice (OCaml and Scala do this too).

I think Haxe is a pretty solid language which works well for general purpose
apps (from command line utilities to games) and it excels at multi-platform
development. This includes backend and frontend development in web dev - with
Haxe you not only can share your code between platforms (browser and node),
but you also have a choice of compile target, so you can compile the same set
of functions to JavaScript or Flash on the frontend and to C++ or PHP on the
backend. And you can easilly switch from one target to another, for example I
used the default neko target in development (blazing fast compilation) and C++
target for running on the remote server.

------
untog
As a JS-y type dev, Typescript still looks better than Haxe to me. _But_ then
when you go the Haxe web site and discover its compilation targets (JS, C++,
C#, Java, Python) you see the real utility.

IMO Haxe is something very, very different to Typescript, and is a lot more
powerful.

~~~
seivan
Seems like TypeScript is better suited for building web applications (backend
and front-end) but HaXe has OpenFL that makes it amazing for games.

~~~
larsiusprime
OpenFL is just one of the many Haxe frameworks, to be sure.

For instance, Haxe is great for web applications too -- one of it's chief
draws is that you can share the same code on the front end and the back end,
but target whichever language is best for that. JS on the front,
PHP/NodeJS/Neko/Etc/ on the back.

UFront is just one great example: [http://ufront.net/](http://ufront.net/)

As for other multimedia frameworks, here's my best attempt at an exhaustive
list:

OpenFL - [http://www.openfl.org](http://www.openfl.org)

SnowKit - [http://snowkit.org/](http://snowkit.org/)

Kha - [http://tech.ktxsoftware.com/](http://tech.ktxsoftware.com/)

NME - [https://github.com/haxenme/nme](https://github.com/haxenme/nme)

Flambe - [http://getflambe.com/](http://getflambe.com/)

HEAPS -
[https://github.com/ncannasse/heaps](https://github.com/ncannasse/heaps)

And things built on top of those:

HaxeFlixel - [http://haxeflixel.com/](http://haxeflixel.com/)

HaxePunk - [http://haxepunk.com/](http://haxepunk.com/)

Luxe Engine - [http://luxeengine.com/docs/](http://luxeengine.com/docs/)

Away3D - [https://github.com/away3d/away3d-core-
openfl](https://github.com/away3d/away3d-core-openfl)

HaxeUI - [http://haxeui.org/](http://haxeui.org/)

KhaPunk -
[https://bitbucket.org/stalei/khapunk](https://bitbucket.org/stalei/khapunk)

------
zamalek
The lack of comparison regarding the tooling is very unfortunate. A nicely
designed language is always slick but that doesn't drastically alter how
productive I can be with a language (at least within the range of difference
between TS and Haxe).

The differences explored in the article are borderline 'religious' reasons.

Why Typescript? Simple: VSCode. One of the things that Microsoft does best is
IDEs/editors and the Typescript experience in VSCode (and VIM and what-have-
you) is no exception.

~~~
Matthias247
atom-typescript is awesome too

------
gamesbrainiac
How has this escaped popular notice for so long?

EDIT: How has Haxe as a language escaped popular notice for so long?

~~~
jdmichal
At the risk of sounding like a JavaScript interviewer, define "this". The
article was posted today, so I doubt that's what you're referring to.

EDIT: My guess would be that it was originally too focused in its use case as
an ActionScript replacement for Flash. In current times, I would say that it
has made the same mistake that everything other than TypeScript has: It tries
to "fix" JavaScript / ECMAScript. That means learning yet another slightly-
different thing, and also porting if it's not a new project. TypeScript has
picked up a lot of momentum by taking the superset approach, allowing
progressive enhancement of existing codebases. Just start throwing your
JavaScript into the TypeScript compiler and you're done.

~~~
larsiusprime
Are you sure it isn't also the fact that it's historically had a tiny
community of open source hackers and TypeScript has all the momentum of MS
behind it?

~~~
jdmichal
I'm sure that also plays into it. Though DefinitelyTyped was started by
someone who AFAIK is unaffiliated with MS, and I would say that is pretty
critical to its success.

I should have specified that the above is the reason I would choose TypeScript
over Haxe now. There's a lot of times when I will prototype a project in
vanilla JavaScript, then set up the TypeScript build infrastructure and start
enhancing.

------
spion
I also wish more things in JS were expressions - having var statements as
expressions in particular would help a lot with arrow functions.

Algebraic data types (and pattern matching) are definitely features that
should be present in every language - the difference of modeling things
without and with them is like night and day.

TypeScript's type system is indeed more forgiving, but mostly because the
language is designed for migrating existing JS codebases to it. You can then
tighten the grip significantly by adding `--noImplicitAny`. The most
unfortunate TS unsoundness issue at the moment is that null/undefined are
acceptable values for all types - I really wish they'd fix that...

What are the options for JS FFI in Haxe? Is there something less awkward to
use (perhaps a more user friendly FFI library) than
[http://old.haxe.org/doc/advanced/magic#javascript-
magic](http://old.haxe.org/doc/advanced/magic#javascript-magic) ?

-

Side note: automatic semicolon insertion was not a huge mistake, and Douglas
Crockford saying it was doesn't make it so. If you follow 2 simple rules, you
wont need any semicolons:

1) Dont put a new line between `return`/`throw`, and the returned/thrown
expression (newlines inside the expression are fine)

2) Prepend `;` to a line starting with `(`

Crockford had a minifier bug related to #2 and solved someone else's problem
with #1 then declared a rule to always use semicolons (which doesn't even help
with #1)

~~~
pluma
Here's the rules you need to follow if you use semicolons:

1) Use a semicolon.

2) There is no rule 2.

EDIT: This may seem flippant but the point is that humans make mistakes and
the more rules you have to obey, the more mistakes they will make. Especially
beginners.

ASI (automatic semicolon insertion) and double-equals (weak comparison vs
triple-equals strict comparison) aren't bad because they don't work, they are
bad because they allow for unnecessary mistakes in return for a minimal
reduction of characters you need to type.

Despite all the rationalizations, the primary reason some programmers prefer
to rely on ASI is purely aesthetics. That's okay, but there's no point in
trying to construct artificial arguments to defend that preference.

If a future version of the language somehow manages to eliminate the need for
those rules, I'll be the last person to tell you to stick to your semicolons.
Until then, it's still a voluntary handicap.

~~~
spion
Even if you use semicolons, you still need the extra rule about return/throw
statements. Otherwise the following will surprise you:

    
    
      return
      {
        property: value
      };
    

(Whats the value returned? Its `undefined`)

Therefore, "Use a semicolon" is insufficient. Or rather, its about as
sufficient as "Don't start a line with (".

Which means that the rule(s) for using semicolons are no more complex than the
rules for not using them.

This is precisely why "follow these simple rules" is not enough. I believe
that us programmers would really benefit if we stopped following and
perpetuating best practices without understanding (and explaining) the reasons
behind them very throughly.

If you want less cognitive overload, use a language with less warts, or a
language with a type system. Lint-like rules that don't come with a reason are
useless and result in a false sense of security

------
explorigin
The article does a good job of comparing the two. Here's an example TodoMVC in
Haxe for a better understanding of what front-end development looks like:
[https://github.com/explorigin/todomvc-
haxe](https://github.com/explorigin/todomvc-haxe)

(full-disclosure...my project)

------
larsiusprime
We killed the server!

Mirror here:
[https://github.com/andyli/blog/blob/master/content/posts/201...](https://github.com/andyli/blog/blob/master/content/posts/2015/2015-08-05_typescript-
vs-haxe.md)

EDIT: Looks like it's back up.

------
snarkyturtle
Haxe doesn't have decorators doesn't it? Wonder if it's on their roadmap...

~~~
andyonthewings
Do you mean python decorator? It can be emulated with "metadata" and "macros"
in Haxe.

metadata: [http://haxe.org/manual/lf-metadata.html](http://haxe.org/manual/lf-
metadata.html)

macros: [http://haxe.org/manual/macro.html](http://haxe.org/manual/macro.html)

------
tomcam
The article shortchanged Haxe a little by omitting mention of its vast,
varied, and flexible runtime library.

------
jestar_jokin
I've had my eye on Haxe for a long time, and the language has a lot of
features that I like - it's cross-paradigm: primarily OO, but good support for
functional programming; plus, macros are amazing and can extend the language
to do whatever you want.

The project that made me see its potential was "Haxe-WavPack-Decoder", an
audio decoder for the WavPack file format. It targets Neko, C++, C#, Java and
Javascript. Imagine using Haxe to write reference implementations for file
formats (or anything, really), then spitting out implementations for any other
target language, so you could include it in a project using any runtime of
your choosing.

The problems I see are:

* The language itself is not a high-level wrapper for each platform/target, so you still need to write different code for each platform. (OpenFL/Lime does a great job at handling this for you for games)

* The compiled output might have surprising runtime characteristics. For example, I tried writing an audio rendering app where I targeted C++, and had a naive two-dimensional array (a Vector of Vectors of Floats). When I tried retrieving an inner array, it would attempt to cast the array and its entire contents. This happened _every time_ the array was accessed, and it was accessed multiple times per second. When I flattened the arrays to a single array and used a calculated index, it reduced the processing time from ~30mins to ~5mins.

* You can't necessarily make use of each target language's strengths. For example, I think the Java target does not support annotations.

* If you want to make use of platform libs/tech, you'll need to define externs for each lib. (There's some efforts to use a TypeScript->Haxe converter to convert all of the DefinitelyTyped definitions to externs, so the JS target is looking promising.)

* It seems like a lot of developers come from a Flash/ActionScript background, so there's lots of ports of AS libs with documentation that just says "See the AS lib documentation". This is not helpful for general developers.

* Due to having so many use-cases, it's very hard to share knowledge for "Haxe" \- are you looking for info on Haxe for games on desktop, or Haxe for games on HTML5, or Haxe for webapps on PHP, or Haxe for webapps on NodeJS...? This is a tribute to its versatility, but it means the developer mindshare gets splintered into separate tribes.

* Due to targeting other languages, you kind of have to be an expert in that language/platform already, which means you need to translate from the target language to Haxe in your head.

* Since macros can extend the language to do anything else, libraries will splinter based on capabilities and implementations of those capabilities. Some libraries might use an "Optional" macro, some might use "Maybe", and they'll do roughly the same thing but be incompatible.

* I believe libraries written in Haxe can only be distributed as source code, limiting commercial investment in developing libs. (Although, JS also has this problem but doesn't seem to suffered.)

* Still has nulls. :( It does make some efforts to make developers treat nullable values differently, but it seems inconsistent (and probably dependent on target).

