3 ms·

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 strate

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
  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.
andyonthewings 11y ago
Here is a comparison of all the outputs of the popular compile-to-JS langs: https://gist.github.com/mattmccray/3916195 https://gist.github.com/mattmccray/3916195 Specifically, Haxe's output is here: https://gist.github.com/mattmccray/3916195#file-haxe-js https://gist.github.com/mattmccray/3916195#file-haxe-js In my opinion it is super readable.
- thomasfoster96 11y ago
  Well, from that I gather that Dart transpiles to a huge lump of mostly useless code. It'd be nice to see a non-trivial script written in those languages run through uglify or the closure compiler to see how well they can be simplified.
  - cwyers 11y ago
    Holy wow. Typescript: 15 lines Haxe: 18 lines Coffeescript: 26 lines JSX: 228 lines Dart: 791 lines
  - munificent 11y ago
    > I gather that Dart transpiles to a huge lump of mostly useless code. It transpiles your code to a small lump of useful code. It also includes a runtime library which takes up a chunk of space. That ends up being a large fraction of the overall result when the application in question is "hello, world!", but in a real-world app, it's a relatively small piece of the pie. I'll also note that the Gist is from 2012. Dart is twice as old today as it was when that Gist was published. Here's what the output looks like today [1]. We have two compilers right now: dart2js is designed to produce output that runs as fast as possible and is as small as possible. You can think of it as "-O3". Optimize all the things at the expense of readability. The dart2js output on the simple example is 170 lines, or 5K of JS (before gzip). Still kind of big, but like I said, most of that is runtime library that amortizes better in large programs. dev_compiler, or "ddc" is for producing human-readable, debuggable output. It's like "gcc -g". No optimizations or minifications, fast compile times, maximum readability. Its output for this is 29 lines. This does not include the runtime library, since it compiles that to separate (also readable) files. The output uses ES6 and looks like: dart_library.library('simple', null, /* Imports */[ "dart_runtime/dart", 'dart/core' ], /* Lazy imports */[ ], function(exports, dart, core) { 'use strict'; let dartx = dart.dartx; class Simple extends core.Object { Simple(name) { this.name = name; } greet(who) { return `Greetings ${who}, I'm ${this.name}!`; } } dart.setSignature(Simple, { constructors: () => ({Simple: [Simple, [core.String]]}), methods: () => ({greet: [dart.dynamic, [dart.dynamic]]}) }); function main() { let s = new Simple('Flyn'); core.print(s.greet('Program')); } dart.fn(main); // Exports: exports.Simple = Simple; exports.main = main; }); //# sourceMappingURL=simple.js.map Pretty readable, I think, especially given how young ddc is. The team is still hard at work on it. [1]: https://gist.github.com/munificent/bde42b3d02c563fb4a9c https://gist.github.com/munificent/bde42b3d02c563fb4a9c
serve_yay 11y ago
Inner functions and function arguments have function scope anyway, so it's not just about `var`. From the acceptance of ES6 forward, JS devs (and devs of whatever languages consider themselves to be a superset of JS) need to accept that both function scope and block scope exist in the language.

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

andyonthewings 11y ago

Here is a comparison of all the outputs of the popular compile-to-JS langs: https://gist.github.com/mattmccray/3916195 https://gist.github.com/mattmccray/3916195 Specifically, Haxe's output is here: https://gist.github.com/mattmccray/3916195#file-haxe-js https://gist.github.com/mattmccray/3916195#file-haxe-js In my opinion it is super readable.

thomasfoster96 11y ago
Well, from that I gather that Dart transpiles to a huge lump of mostly useless code. It'd be nice to see a non-trivial script written in those languages run through uglify or the closure compiler to see how well they can be simplified.
- cwyers 11y ago
  Holy wow. Typescript: 15 lines Haxe: 18 lines Coffeescript: 26 lines JSX: 228 lines Dart: 791 lines
- munificent 11y ago
  > I gather that Dart transpiles to a huge lump of mostly useless code. It transpiles your code to a small lump of useful code. It also includes a runtime library which takes up a chunk of space. That ends up being a large fraction of the overall result when the application in question is "hello, world!", but in a real-world app, it's a relatively small piece of the pie. I'll also note that the Gist is from 2012. Dart is twice as old today as it was when that Gist was published. Here's what the output looks like today [1]. We have two compilers right now: dart2js is designed to produce output that runs as fast as possible and is as small as possible. You can think of it as "-O3". Optimize all the things at the expense of readability. The dart2js output on the simple example is 170 lines, or 5K of JS (before gzip). Still kind of big, but like I said, most of that is runtime library that amortizes better in large programs. dev_compiler, or "ddc" is for producing human-readable, debuggable output. It's like "gcc -g". No optimizations or minifications, fast compile times, maximum readability. Its output for this is 29 lines. This does not include the runtime library, since it compiles that to separate (also readable) files. The output uses ES6 and looks like: dart_library.library('simple', null, /* Imports */[ "dart_runtime/dart", 'dart/core' ], /* Lazy imports */[ ], function(exports, dart, core) { 'use strict'; let dartx = dart.dartx; class Simple extends core.Object { Simple(name) { this.name = name; } greet(who) { return `Greetings ${who}, I'm ${this.name}!`; } } dart.setSignature(Simple, { constructors: () => ({Simple: [Simple, [core.String]]}), methods: () => ({greet: [dart.dynamic, [dart.dynamic]]}) }); function main() { let s = new Simple('Flyn'); core.print(s.greet('Program')); } dart.fn(main); // Exports: exports.Simple = Simple; exports.main = main; }); //# sourceMappingURL=simple.js.map Pretty readable, I think, especially given how young ddc is. The team is still hard at work on it. [1]: https://gist.github.com/munificent/bde42b3d02c563fb4a9c https://gist.github.com/munificent/bde42b3d02c563fb4a9c

serve_yay 11y ago

Inner functions and function arguments have function scope anyway, so it's not just about `var`. From the acceptance of ES6 forward, JS devs (and devs of whatever languages consider themselves to be a superset of JS) need to accept that both function scope and block scope exist in the language.