15 ms·

TypeScript vs. Haxe

90 points by larsiusprime 11y ago

gamesbrainiac 11y ago
How has this escaped popular notice for so long? EDIT: How has Haxe as a language escaped popular notice for so long?
- jdmichal 11y ago
  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 11y ago
    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 11y ago
      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.
  - yoklov 11y ago
    I don't think Haxe really is trying to fix JS, any more than it tries to fix C#, C++ or Java. It's similar enough to JS due to being a ES4 (ActionScript) derivative, but that's mostly a coincidence due to it's legacy.
- agd 11y ago
  I started out using Haxe and eventually switched to Typescript because: - it didn't easily integrate with existing JS code/libraries - small community - low resources (compiler bugs existed and weren't quickly fixed) The community was a dealbreaker really. Lots of JS libraries already have TS type definitions so it's easy to get started, and TS keeps up-to-date with new JS features. I prefered the Haxe typesystem, but it didn't really make business sense to keep using it.
  - enriquecastl 11y ago
    The first point applies to TypeScript too. It's hard to integrate a library that doesn't have a type definition or don't play well with its module system. This week I started to work on a Node hobby project and decided to use TypeScript. I rolled back my decision after noticing that it was not possible to include installed node npm modules using the ES6 syntax. They'll probably fix this issue sooner rather than later but in the meanwhile it's a critical issue.
    - Glide 11y ago
      Wait.. Are you talking about what's described here: https://github.com/Microsoft/TypeScript/issues/2242 https://github.com/Microsoft/TypeScript/issues/2242 I just did a small typescript prototype and used the import syntax there. It might have been your typescript version as 1.5 recently came out (and I was using the 1.5 beta 2). The hardest part is what you described at the start. If it doesn't have a type definition it's hard. DefinitelyTyped helps a lot (https://github.com/DefinitelyTyped/tsd https://github.com/DefinitelyTyped/tsd) I had to create a type definition for something that wasn't there. It was annoying because I had to make the equivalent of a header file before I could use a library.
    - nothrabannosir 11y ago
      Am I missing something here? Let's say you want to include Chart.js, and imagine there are no type definitions: declare var Chart: any; atop your file, and you can use it the same way you would in JS: without type info. No need to create any type definitions. Or do you mean something different?
- mjfisher 11y ago
  I have no idea. We've been using it for a couple of years or so now, and have a wonderfully varied set of products built using Haxe and its libraries. If anyone browsing the comments section is interested in a familiar-ish, statically typed and fairly powerful language that cross compiles to a huge range of back-ends and platforms, take a couple of minutes to visit haxe.org. It's worth the time.
- explorigin 11y ago
  Pretty simple. Haxe is a small project supported by some niche-market companies. It's just now starting to break out of that. Typescript is from Microsoft and was integrated into Visual Studio straight away. Aside from that, it has a longer learning curve than TS. This article does a great job of outlining some of the differences.
- nadams 11y ago
  > How has Haxe as a language escaped popular notice for so long? Simple really - other languages, framework, and SDKs have filled the programming needs of people. I've found most source-to-source compilers to either be completely broken, too complicated to use, or not enough features (I've seen a number of Python to C compilers started and never even close to finished). I discovered Haxe many years ago when I had the idea for my own source-to-source compiler (and created my own lexer, parser, compiler, and virtual machine in C++). I personally haven't used Haxe yet but I found it's documentation to be pretty good and it seems to have good reviews. HLA [1] might also be interesting to you. [1] http://www.plantation-productions.com/Webster/ http://www.plantation-productions.com/Webster/
- deleted 11y ago
  [deleted]
- aikah 11y ago
  A few things in my opinion that slowed down Haxe: - Language barrier (Since Haxe docs are first and foremost handled by europeans like me, I know English natives always find it a bit ghetto when they feel the writer isn't a native, but there is very little we can do about it) - It's not as easy to use as it seems, though OpenFL made it a bit easier. - Backward compatibility breaks between versions, I'm sorry but a language designer should never do that. I know it's tough to get things right on the first iteration,but v2 libs not working in v3 can slow down a language adoption. We've seen this countless times. It only piss off early adopters. - Maybe too focused on Flash at first ( But the C++ and JS targets work quite well, in fact, both Android and IOS targets use C++ ). - written in OCAML... makes it more difficult for people to contribute to the core. I'd say wait a few more years until the stuff is mature. EDIT: if you are writing a game it is a no brainer. Your app will run in the browser with JS, Flash and natively on Ios and Android with a single codebase and very very little tweaking.
- yoklov 11y ago
  It's fairly well known in game development circles, at least for indies. It also has a bunch of weird features that can be off-putting. Abstracts and macros, for example, are both fairly weird, although seem to be extremely powerful. And... not having a large company like MS backing it doesn't help it out any.
- chipsy 11y ago
  To put it dramatically, Haxe is a parasitic environment. It can't offer tooling quite as robust or exact as a ground-up language environment. In exchange it allows projects to change direction very rapidly and bolt together the union of technologies native to a platform, and technologies made portable within Haxe. This has made the language a hard sell in its first decade. Lots of people have passed through, made something amazing, and then wandered off. The compiler has always been solid, but the rest of the ecosystem regularly encounters missing pieces. A "full-stack" mentality is nearly a must to ship a project in Haxe. But since it's made it this far, it's only likely to keep improving from here. After all, "prevent lock-in" and "reduce portability costs" are powerful selling points.
- treve 11y ago
  The reason I dismissed Haxe, was that back in the day the original author basically annoyed the hell out of everyone on the flash mailing lists (in particular OSFlash), being extremely arrogant and constantly pushing his technology in unrelated threads. I wonder if that guy is still at the helm.
explorigin 11y ago
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)
untog 11y ago
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.
- chii 11y ago
  the power of haxe to me, comes from the compile time macros (which is also written in haxe, ala lisp, just less dynamic). You basically get access to the AST during compilation, and directly write out new code. Great for adding in overhead-free abstractions, or even, dsl like languages.
- seivan 11y ago
  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 11y ago
    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
nothrabannosir 11y ago
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 11y ago
  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 11y ago
spion 11y ago
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 11y ago
  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.
  - 11y ago
larsiusprime 11y ago
We killed the server! Mirror here: https://github.com/andyli/blog/blob/master/content/posts/2015/2015-08-05_typescript-vs-haxe.md https://github.com/andyli/blog/blob/master/content/posts/201... EDIT: Looks like it's back up.
zamalek 11y ago
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 11y ago
  atom-typescript is awesome too
klibertp 11y ago
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.html http://haxe.org/documentation/introduction/language-features... 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.
neals 11y ago
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 11y ago
  Could you share more information about writing gulp (+plugins) in Haxe? I can't wait to learn it.
snarkyturtle 11y ago
Haxe doesn't have decorators doesn't it? Wonder if it's on their roadmap...
- andyonthewings 11y ago
  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 11y ago
The article shortchanged Haxe a little by omitting mention of its vast, varied, and flexible runtime library.
jestar_jokin 11y ago
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).

TypeScript vs. Haxe

90 points by larsiusprime 11y ago

gamesbrainiac 11y ago

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

jdmichal 11y ago
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 11y ago
  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 11y ago
    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.
- yoklov 11y ago
  I don't think Haxe really is trying to fix JS, any more than it tries to fix C#, C++ or Java. It's similar enough to JS due to being a ES4 (ActionScript) derivative, but that's mostly a coincidence due to it's legacy.
agd 11y ago
I started out using Haxe and eventually switched to Typescript because: - it didn't easily integrate with existing JS code/libraries - small community - low resources (compiler bugs existed and weren't quickly fixed) The community was a dealbreaker really. Lots of JS libraries already have TS type definitions so it's easy to get started, and TS keeps up-to-date with new JS features. I prefered the Haxe typesystem, but it didn't really make business sense to keep using it.
- enriquecastl 11y ago
  The first point applies to TypeScript too. It's hard to integrate a library that doesn't have a type definition or don't play well with its module system. This week I started to work on a Node hobby project and decided to use TypeScript. I rolled back my decision after noticing that it was not possible to include installed node npm modules using the ES6 syntax. They'll probably fix this issue sooner rather than later but in the meanwhile it's a critical issue.
  - Glide 11y ago
    Wait.. Are you talking about what's described here: https://github.com/Microsoft/TypeScript/issues/2242 https://github.com/Microsoft/TypeScript/issues/2242 I just did a small typescript prototype and used the import syntax there. It might have been your typescript version as 1.5 recently came out (and I was using the 1.5 beta 2). The hardest part is what you described at the start. If it doesn't have a type definition it's hard. DefinitelyTyped helps a lot (https://github.com/DefinitelyTyped/tsd https://github.com/DefinitelyTyped/tsd) I had to create a type definition for something that wasn't there. It was annoying because I had to make the equivalent of a header file before I could use a library.
  - nothrabannosir 11y ago
    Am I missing something here? Let's say you want to include Chart.js, and imagine there are no type definitions: declare var Chart: any; atop your file, and you can use it the same way you would in JS: without type info. No need to create any type definitions. Or do you mean something different?
mjfisher 11y ago
I have no idea. We've been using it for a couple of years or so now, and have a wonderfully varied set of products built using Haxe and its libraries. If anyone browsing the comments section is interested in a familiar-ish, statically typed and fairly powerful language that cross compiles to a huge range of back-ends and platforms, take a couple of minutes to visit haxe.org. It's worth the time.
explorigin 11y ago
Pretty simple. Haxe is a small project supported by some niche-market companies. It's just now starting to break out of that. Typescript is from Microsoft and was integrated into Visual Studio straight away. Aside from that, it has a longer learning curve than TS. This article does a great job of outlining some of the differences.
nadams 11y ago
> How has Haxe as a language escaped popular notice for so long? Simple really - other languages, framework, and SDKs have filled the programming needs of people. I've found most source-to-source compilers to either be completely broken, too complicated to use, or not enough features (I've seen a number of Python to C compilers started and never even close to finished). I discovered Haxe many years ago when I had the idea for my own source-to-source compiler (and created my own lexer, parser, compiler, and virtual machine in C++). I personally haven't used Haxe yet but I found it's documentation to be pretty good and it seems to have good reviews. HLA [1] might also be interesting to you. [1] http://www.plantation-productions.com/Webster/ http://www.plantation-productions.com/Webster/
deleted 11y ago
[deleted]
aikah 11y ago
A few things in my opinion that slowed down Haxe: - Language barrier (Since Haxe docs are first and foremost handled by europeans like me, I know English natives always find it a bit ghetto when they feel the writer isn't a native, but there is very little we can do about it) - It's not as easy to use as it seems, though OpenFL made it a bit easier. - Backward compatibility breaks between versions, I'm sorry but a language designer should never do that. I know it's tough to get things right on the first iteration,but v2 libs not working in v3 can slow down a language adoption. We've seen this countless times. It only piss off early adopters. - Maybe too focused on Flash at first ( But the C++ and JS targets work quite well, in fact, both Android and IOS targets use C++ ). - written in OCAML... makes it more difficult for people to contribute to the core. I'd say wait a few more years until the stuff is mature. EDIT: if you are writing a game it is a no brainer. Your app will run in the browser with JS, Flash and natively on Ios and Android with a single codebase and very very little tweaking.
yoklov 11y ago
It's fairly well known in game development circles, at least for indies. It also has a bunch of weird features that can be off-putting. Abstracts and macros, for example, are both fairly weird, although seem to be extremely powerful. And... not having a large company like MS backing it doesn't help it out any.
chipsy 11y ago
To put it dramatically, Haxe is a parasitic environment. It can't offer tooling quite as robust or exact as a ground-up language environment. In exchange it allows projects to change direction very rapidly and bolt together the union of technologies native to a platform, and technologies made portable within Haxe. This has made the language a hard sell in its first decade. Lots of people have passed through, made something amazing, and then wandered off. The compiler has always been solid, but the rest of the ecosystem regularly encounters missing pieces. A "full-stack" mentality is nearly a must to ship a project in Haxe. But since it's made it this far, it's only likely to keep improving from here. After all, "prevent lock-in" and "reduce portability costs" are powerful selling points.
treve 11y ago
The reason I dismissed Haxe, was that back in the day the original author basically annoyed the hell out of everyone on the flash mailing lists (in particular OSFlash), being extremely arrogant and constantly pushing his technology in unrelated threads. I wonder if that guy is still at the helm.

explorigin 11y ago

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)

untog 11y ago

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.

chii 11y ago
the power of haxe to me, comes from the compile time macros (which is also written in haxe, ala lisp, just less dynamic). You basically get access to the AST during compilation, and directly write out new code. Great for adding in overhead-free abstractions, or even, dsl like languages.
seivan 11y ago
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 11y ago
  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

nothrabannosir 11y ago

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 11y ago
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 11y ago

spion 11y ago

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 11y ago
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.
- 11y ago

larsiusprime 11y ago

We killed the server! Mirror here: https://github.com/andyli/blog/blob/master/content/posts/2015/2015-08-05_typescript-vs-haxe.md https://github.com/andyli/blog/blob/master/content/posts/201... EDIT: Looks like it's back up.

zamalek 11y ago

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 11y ago
atom-typescript is awesome too

klibertp 11y ago

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.html http://haxe.org/documentation/introduction/language-features... 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.

neals 11y ago

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 11y ago
Could you share more information about writing gulp (+plugins) in Haxe? I can't wait to learn it.

snarkyturtle 11y ago

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

andyonthewings 11y ago
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 11y ago

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

jestar_jokin 11y ago

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