8 ms·

Anders Hejlsberg and Lars Bak: TypeScript, JavaScript, and Dart

59 points by michaelwww 14y ago

Lars Bak: To contrast these two languages, TypeScript is a safe bet... where Dart is trying to change some of the fundamental issues with JavaScript. I feel, from a computer science background, I still have problems that you can design applications with libraries where you can monkey patch the libraries when you get up running. I find that very, very disturbing when you are trying to write big applications. [with TypeScript] you end up in the same mess. Anders Hejlsberg: Everything you say and more I will agree with. The question is not whether JavaScript is broken. The question is whether it is broken enough to merit being replaced by something else.

deleted 14y ago
[deleted]
michaelwww 14y ago
Lars Bak: To contrast these two languages, TypeScript is a safe bet... where Dart is trying to change some of the fundamental issues with JavaScript. I feel, from a computer science background, I still have problems that you can design applications with libraries where you can monkey patch the libraries when you get up running. I find that very, very disturbing when you are trying to write big applications. [with TypeScript] you end up in the same mess. Anders Hejlsberg: Everything you say and more I will agree with. The question is not whether JavaScript is broken. The question is whether it is broken enough to merit being replaced by something else.
pnt 14y ago
I feel like Dart's emphasis on a fast but chrome-only vm has hindered it's adoption. I understand their goal, unlike most compile-to-js languages, was a language more amenable to fast implementation. However, I think the initial community reaction would have been more positive if Dart was positioned first as a language that compiled to js, with the added benefit that it runs significantly faster on Chrome.
- michaelwww 14y ago
  I agree. They stumbled initially because the "hello world" JavaScript output was something huge (17,000 LOC if I remember correctly.) But I think they are recovering nicely and people will notice.
  - tyleregeto 14y ago
    That was unfortunate, mostly because a single compiler flag brought the code base way down, smaller the JQuery. If I recall correctly, that mistake was from a blogger, not Google, but it caught the bad publicity winds. Somebody was more eager to tear it apart than learn the tools.
- dragonwriter 14y ago
  > I feel like Dart's emphasis on a fast but chrome-only vm has hindered it's adoption. Dart's VM isn't Chrome-only, its open source, and available both standalone and bundled into Chromium. > However, I think the initial community reaction would have been more positive if Dart was positioned first as a language that compiled to js, with the added benefit that it runs significantly faster on Chrome. Reaction might have been more positive in the short run if it was sold as a on-top-of-JS language rather than part of a long-term plan to build something to replace (or complement) JS as a language for which browsers would have a a built-in, language-specific VM. However, I think that even if initial reaction might have been better with such a response, Google clearly did the right thing by being up front about their vision.
  - pnt 14y ago
    > Dart's VM isn't Chrome-only I meant that dart is chrome-only in practice. I don't know of any other browser vendor that bundles the dart vm, including the few browsers based on chromium like rockmelt or 360. > However, I think that even if initial reaction might have been better with such a response, Google clearly did the right thing by being up front about their vision. I can appreciate Google's directness regarding Dart's intention. However, from a web developer's perspective, Dart's multiple backends is very unappealing. I hesitate to adopt even a language like clojurescript or coffeescript because of debugging barriers and potential bugs in the language's crevices (though these problems are diminishing with things like source map support).
ttrreeww 14y ago
Transcript?
- michaelwww 14y ago
  Doesn't appear to be one. The quotes I lifted start at 11:23
seanalltogether 14y ago
Can anyone explain what the difference between TypeScript and ECMAScript 4 are? I know ECMAScript 4 was abandoned for some reason, but from the few examples I've seen of Typescript it looks very similar. Did the js community just need a few more years to come around to the ideas?
- phase_9 14y ago
  ECMAScript 4 was implemented in ActionScript 3[1]; a very nice language to work with IMHO. The members of the ECMAScript steering group launched into a public fracas on their respective blogs[2] which eventually ended in the draft being canned, despite the fact both ActionScript and Silverlight were already based on the standard... shame. [1] http://en.wikipedia.org/wiki/ActionScript#ActionScript_3.0 http://en.wikipedia.org/wiki/ActionScript#ActionScript_3.0 [2] http://blogs.msdn.com/b/ie/archive/2007/10/30/ecmascript-3-and-beyond.aspx#5788577 http://blogs.msdn.com/b/ie/archive/2007/10/30/ecmascript-3-a...
  - camus 14y ago
    > The second system syndrome is that evil effect that often happens when redesign a small, working system so that it becomes a huge leviathan built by piling new features over new features. > Today I was reading the overview of ECMASCript 4 from ecmascript.org, and I got this very bad feeling that maybe the fourth version of ES, is suffering of an extremely strong case of this problem. I dont know who is that guy , but what a load of cr*p ... it's people like him that got us stuck with what is javascript today. People often complain that Flash prevented Javascript from being widely adopted , the truth is that Macromedia/Adobe tried to push a better Javascript that would have helped the language then and today. Imagine we had ES4 and HTML5 today. Nobody would be complaining about how much javascript sucks , and there would be no need for typescript, coffeescript ,etc ...
    - riffraff 14y ago
      actually, it's my words[0] :) I wrote it many years ago, but if you think it's wrong I'd be happy to understand why. I have never been against Flash nor ActionScript(which I don't know enough to criticize) but my understanding was that ES4 was vastly more complex than even AS ever was, rather than being an incremental change as ES6 is. And please note I wrote """ ECMAScript 4 seems cool, I want to use a lot of those things (yay for multi method dispatch!), but maybe it is changing the language a little bit too much . """ And I wish I could influence what the dev world does, but I believe it is unlikely. [0] http://www.riffraff.info/2007/10/25/ecmascript-4-the-fourth-system-syndrome http://www.riffraff.info/2007/10/25/ecmascript-4-the-fourth-...
andyl 14y ago
To me this interview underlines the accomplishment of CoffeeScript. No committees. No marketing team. No developer evangelists. No PR team. No corporate interests. No budget. Just code.
- rayiner 14y ago
  Also nobody with the sense of history to design proper lexical scoping of variables.
  - baudehlo 14y ago
    To achieve that CS would have had to put everything with a new variable inside a new function scope, having a major impact on performance and readability of the generated code.
    - kevingadd 14y ago
      It's possible to detect name collisions in a compiler and only generate scopes when needed...
    - gruseom 14y ago
      Parenscript gets lexical scoping by renaming variables (but only where necessary). It works fine. The original variable name is used as a prefix, so the generated code remains readable.
  - snprbob86 14y ago
    This has been covered over, and over, and over again. CoffeeScript has some explicit goals with respect to the generated JavaScript output, and that includes not mucking with your identifiers. In order to implement correct lexical scoping, you'd need to rewrite identifiers to avoid shadowing and collision. CoffeeScript's design is a very reasonable trade off given the inadequacies of JavaScript.
- rwaldron 14y ago
  ...No formal semantic or syntactic specification...
sultezdukes 14y ago
It's a pretty smart move that Microsoft did with TypeScript, making it a proper superset of JavaScript. Google seems to be stuck in the past, bringing out its own VM that is a complete non-starter, and making another class-based, Java-like language. I guess Google is going down the road that Microsoft did years ago with flinging feces on the wall and see what sticks. I have nothing against Dart. I played with it a year and a half ago when the Eclipse beta came out. It's nice tooling, but brings absolutely nothing interesting to the table.
- weareconvo 14y ago
  Yesterday, I rewrote one of my JS modules into Dart, and it ended up being about 10 lines of code with only two modules imported. Then I compiled it to JS, and it was over 120k. I tried for about an hour to get that down to a reasonable size with Closure Compiler/Uglify, but the names were too wonky. I'm sure that, given enough time, they'll solve these problems, but as for right now... it isn't ready for primetime. Not by a longshot.
  - afsina 14y ago
    Related: http://blog.sethladd.com/2013/03/i-shrunk-my-dart-to-js-code-by-11x-and.html http://blog.sethladd.com/2013/03/i-shrunk-my-dart-to-js-code...
  - michaelwww 14y ago
    You don't say if you used the 'dart2js --minify' setting, but Closure Compiler should do well. The --minify flag leaves alot more room for additional minification. You say you used two modules. The result really depends on the modules. For example, the Dart/JS interop module adds about 140K un-minified. Tree shaking is always on, so the 140K is after stripping unused code. I initially jumped into Dart because I was interested in doing packaged apps that run locally, so the size over the wire didn't concern me as much. I recently converted an ActionScript app to Dart and the post-minify Dart was around the same size as the compiled .swf file (for comparison, same functionality) Seth Ladd has a couple of posts about Tree Shaking and Minification if you're interested http://blog.sethladd.com/2013/01/minification-is-not-enough-you-need.html http://blog.sethladd.com/2013/01/minification-is-not-enough-... http://blog.sethladd.com/2013/03/i-shrunk-my-dart-to-js-code-by-11x-and.html http://blog.sethladd.com/2013/03/i-shrunk-my-dart-to-js-code...
camus 14y ago
Haxe anyone ? full HTML5 api support , dead-code elimination, loads of libraries and frameworks , easy integration with third party libraries ,multi-target (C++,Flash,JS,...) and open source...
- coolsunglasses 14y ago
  Stop trying to make Haxe happen, it's not going to happen.
  - bsaul 14y ago
    I've been wondering whether I should start using this language for a project, and almost every time there's a good reason not too, but I'm still thinking one day there won't and i will. I'm curious to know what makes you think it will never happen, though.
    - coolsunglasses 14y ago
      It tries to be too many things to too many people, can't do a good enough job on any of it. Not really worth the investment.
      - camus 14y ago
        haxe has flaws , but haxe is not backed by windows nor google. The team is 3/4 developers and they did a great work. Haxe will grow in the future. All it needs is a better "PR" and a bit of hype. A lot of successfull projects have been made with haxe.
- jdonaldson 14y ago
  Haxe 3 is just around the corner, the RC is out right now. http://haxe.org/manual/haxe3/features http://haxe.org/manual/haxe3/features Not sure why it doesn't get more love here, it's awesome for developing complex js libraries, in addition to what you can do server side, and/or on a mobile platform.
- somokon 14y ago
yonran 14y ago
TypeScript is what Google Closure Compiler should have been; Closure’s static typing is similar but is much more tedious (you need to type 16 characters just to declare an int! https://developers.google.com/closure/compiler/docs/js-for-compiler https://developers.google.com/closure/compiler/docs/js-for-c...). I’m disappointed that nobody from Google Closure has stepped up to unify TypeScript and Closure’s syntax and to provide better tooling.
edtechdev 14y ago
Dart is great and I like how they are focusing on making it fast and creating a special VM for it (dartium, although it compiles to javascript, too). It's tempting to target a compiler to generate dart code, too, instead of javascript. But there is one deal breaker for me - dart can't compile locally in the browser (even a dartium one). It requires a server or else compiling off-line (same issue with Closure Compiler, too). You can't code a dart app on a chromebook, for example (unless you use remote desktop or install ubuntu on it). The future to me is doing all development work in the browser, and only connecting to the server for the server components or version control, like with c9.io and other browser-based IDEs. Even Eclipse has a browser-based version now - Orion. It's not a huge deal - there are over a hundred alternative languages that compile to javascript out there now, many of which do support compiling in the browser: https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS https://github.com/jashkenas/coffee-script/wiki/List-of-lang...
- michaelwww 14y ago
  Dart source is run by the Dart engine similarly to how JavaScript is run by the JavaScript engine, so you should be able to edit Dart source in a browser and run it if that browser includes the Dart VM (Dartium).
- munificent 14y ago
  > dart can't compile locally in the browser dart2js is written in Dart. There's some small amount of work needed to self-host it and run the result in a browser, mainly swapping out the file IO API with something that works on the web. I think multiple people on the team have slapped together working examples of this, so it's not a lot of work. It isn't a high priority for the dart2js team right now, though, and they are very careful to avoid taking on responsibility for features or use cases that don't have solid tests. I think before too long, we will have a reliably self-hosted Dart->JS compiler that runs in a browser, we're just focused on other stuff for the moment.

59 points by michaelwww 14y ago

deleted 14y ago

[deleted]

michaelwww 14y ago

pnt 14y ago

I feel like Dart's emphasis on a fast but chrome-only vm has hindered it's adoption. I understand their goal, unlike most compile-to-js languages, was a language more amenable to fast implementation. However, I think the initial community reaction would have been more positive if Dart was positioned first as a language that compiled to js, with the added benefit that it runs significantly faster on Chrome.

michaelwww 14y ago
I agree. They stumbled initially because the "hello world" JavaScript output was something huge (17,000 LOC if I remember correctly.) But I think they are recovering nicely and people will notice.
- tyleregeto 14y ago
  That was unfortunate, mostly because a single compiler flag brought the code base way down, smaller the JQuery. If I recall correctly, that mistake was from a blogger, not Google, but it caught the bad publicity winds. Somebody was more eager to tear it apart than learn the tools.
dragonwriter 14y ago
> I feel like Dart's emphasis on a fast but chrome-only vm has hindered it's adoption. Dart's VM isn't Chrome-only, its open source, and available both standalone and bundled into Chromium. > However, I think the initial community reaction would have been more positive if Dart was positioned first as a language that compiled to js, with the added benefit that it runs significantly faster on Chrome. Reaction might have been more positive in the short run if it was sold as a on-top-of-JS language rather than part of a long-term plan to build something to replace (or complement) JS as a language for which browsers would have a a built-in, language-specific VM. However, I think that even if initial reaction might have been better with such a response, Google clearly did the right thing by being up front about their vision.
- pnt 14y ago
  > Dart's VM isn't Chrome-only I meant that dart is chrome-only in practice. I don't know of any other browser vendor that bundles the dart vm, including the few browsers based on chromium like rockmelt or 360. > However, I think that even if initial reaction might have been better with such a response, Google clearly did the right thing by being up front about their vision. I can appreciate Google's directness regarding Dart's intention. However, from a web developer's perspective, Dart's multiple backends is very unappealing. I hesitate to adopt even a language like clojurescript or coffeescript because of debugging barriers and potential bugs in the language's crevices (though these problems are diminishing with things like source map support).

ttrreeww 14y ago

Transcript?

michaelwww 14y ago
Doesn't appear to be one. The quotes I lifted start at 11:23

seanalltogether 14y ago

Can anyone explain what the difference between TypeScript and ECMAScript 4 are? I know ECMAScript 4 was abandoned for some reason, but from the few examples I've seen of Typescript it looks very similar. Did the js community just need a few more years to come around to the ideas?

phase_9 14y ago
ECMAScript 4 was implemented in ActionScript 3[1]; a very nice language to work with IMHO. The members of the ECMAScript steering group launched into a public fracas on their respective blogs[2] which eventually ended in the draft being canned, despite the fact both ActionScript and Silverlight were already based on the standard... shame. [1] http://en.wikipedia.org/wiki/ActionScript#ActionScript_3.0 http://en.wikipedia.org/wiki/ActionScript#ActionScript_3.0 [2] http://blogs.msdn.com/b/ie/archive/2007/10/30/ecmascript-3-and-beyond.aspx#5788577 http://blogs.msdn.com/b/ie/archive/2007/10/30/ecmascript-3-a...
- camus 14y ago
  > The second system syndrome is that evil effect that often happens when redesign a small, working system so that it becomes a huge leviathan built by piling new features over new features. > Today I was reading the overview of ECMASCript 4 from ecmascript.org, and I got this very bad feeling that maybe the fourth version of ES, is suffering of an extremely strong case of this problem. I dont know who is that guy , but what a load of cr*p ... it's people like him that got us stuck with what is javascript today. People often complain that Flash prevented Javascript from being widely adopted , the truth is that Macromedia/Adobe tried to push a better Javascript that would have helped the language then and today. Imagine we had ES4 and HTML5 today. Nobody would be complaining about how much javascript sucks , and there would be no need for typescript, coffeescript ,etc ...
  - riffraff 14y ago
    actually, it's my words[0] :) I wrote it many years ago, but if you think it's wrong I'd be happy to understand why. I have never been against Flash nor ActionScript(which I don't know enough to criticize) but my understanding was that ES4 was vastly more complex than even AS ever was, rather than being an incremental change as ES6 is. And please note I wrote """ ECMAScript 4 seems cool, I want to use a lot of those things (yay for multi method dispatch!), but maybe it is changing the language a little bit too much . """ And I wish I could influence what the dev world does, but I believe it is unlikely. [0] http://www.riffraff.info/2007/10/25/ecmascript-4-the-fourth-system-syndrome http://www.riffraff.info/2007/10/25/ecmascript-4-the-fourth-...

andyl 14y ago

To me this interview underlines the accomplishment of CoffeeScript. No committees. No marketing team. No developer evangelists. No PR team. No corporate interests. No budget. Just code.

rayiner 14y ago
Also nobody with the sense of history to design proper lexical scoping of variables.
- baudehlo 14y ago
  To achieve that CS would have had to put everything with a new variable inside a new function scope, having a major impact on performance and readability of the generated code.
  - kevingadd 14y ago
    It's possible to detect name collisions in a compiler and only generate scopes when needed...
  - gruseom 14y ago
    Parenscript gets lexical scoping by renaming variables (but only where necessary). It works fine. The original variable name is used as a prefix, so the generated code remains readable.
- snprbob86 14y ago
  This has been covered over, and over, and over again. CoffeeScript has some explicit goals with respect to the generated JavaScript output, and that includes not mucking with your identifiers. In order to implement correct lexical scoping, you'd need to rewrite identifiers to avoid shadowing and collision. CoffeeScript's design is a very reasonable trade off given the inadequacies of JavaScript.
rwaldron 14y ago
...No formal semantic or syntactic specification...

sultezdukes 14y ago

It's a pretty smart move that Microsoft did with TypeScript, making it a proper superset of JavaScript. Google seems to be stuck in the past, bringing out its own VM that is a complete non-starter, and making another class-based, Java-like language. I guess Google is going down the road that Microsoft did years ago with flinging feces on the wall and see what sticks. I have nothing against Dart. I played with it a year and a half ago when the Eclipse beta came out. It's nice tooling, but brings absolutely nothing interesting to the table.

weareconvo 14y ago
Yesterday, I rewrote one of my JS modules into Dart, and it ended up being about 10 lines of code with only two modules imported. Then I compiled it to JS, and it was over 120k. I tried for about an hour to get that down to a reasonable size with Closure Compiler/Uglify, but the names were too wonky. I'm sure that, given enough time, they'll solve these problems, but as for right now... it isn't ready for primetime. Not by a longshot.
- afsina 14y ago
  Related: http://blog.sethladd.com/2013/03/i-shrunk-my-dart-to-js-code-by-11x-and.html http://blog.sethladd.com/2013/03/i-shrunk-my-dart-to-js-code...
- michaelwww 14y ago
  You don't say if you used the 'dart2js --minify' setting, but Closure Compiler should do well. The --minify flag leaves alot more room for additional minification. You say you used two modules. The result really depends on the modules. For example, the Dart/JS interop module adds about 140K un-minified. Tree shaking is always on, so the 140K is after stripping unused code. I initially jumped into Dart because I was interested in doing packaged apps that run locally, so the size over the wire didn't concern me as much. I recently converted an ActionScript app to Dart and the post-minify Dart was around the same size as the compiled .swf file (for comparison, same functionality) Seth Ladd has a couple of posts about Tree Shaking and Minification if you're interested http://blog.sethladd.com/2013/01/minification-is-not-enough-you-need.html http://blog.sethladd.com/2013/01/minification-is-not-enough-... http://blog.sethladd.com/2013/03/i-shrunk-my-dart-to-js-code-by-11x-and.html http://blog.sethladd.com/2013/03/i-shrunk-my-dart-to-js-code...

camus 14y ago

Haxe anyone ? full HTML5 api support , dead-code elimination, loads of libraries and frameworks , easy integration with third party libraries ,multi-target (C++,Flash,JS,...) and open source...

coolsunglasses 14y ago
Stop trying to make Haxe happen, it's not going to happen.
- bsaul 14y ago
  I've been wondering whether I should start using this language for a project, and almost every time there's a good reason not too, but I'm still thinking one day there won't and i will. I'm curious to know what makes you think it will never happen, though.
  - coolsunglasses 14y ago
    It tries to be too many things to too many people, can't do a good enough job on any of it. Not really worth the investment.
    - camus 14y ago
      haxe has flaws , but haxe is not backed by windows nor google. The team is 3/4 developers and they did a great work. Haxe will grow in the future. All it needs is a better "PR" and a bit of hype. A lot of successfull projects have been made with haxe.
jdonaldson 14y ago
Haxe 3 is just around the corner, the RC is out right now. http://haxe.org/manual/haxe3/features http://haxe.org/manual/haxe3/features Not sure why it doesn't get more love here, it's awesome for developing complex js libraries, in addition to what you can do server side, and/or on a mobile platform.
somokon 14y ago

yonran 14y ago

TypeScript is what Google Closure Compiler should have been; Closure’s static typing is similar but is much more tedious (you need to type 16 characters just to declare an int! https://developers.google.com/closure/compiler/docs/js-for-compiler https://developers.google.com/closure/compiler/docs/js-for-c...). I’m disappointed that nobody from Google Closure has stepped up to unify TypeScript and Closure’s syntax and to provide better tooling.

edtechdev 14y ago

Dart is great and I like how they are focusing on making it fast and creating a special VM for it (dartium, although it compiles to javascript, too). It's tempting to target a compiler to generate dart code, too, instead of javascript. But there is one deal breaker for me - dart can't compile locally in the browser (even a dartium one). It requires a server or else compiling off-line (same issue with Closure Compiler, too). You can't code a dart app on a chromebook, for example (unless you use remote desktop or install ubuntu on it). The future to me is doing all development work in the browser, and only connecting to the server for the server components or version control, like with c9.io and other browser-based IDEs. Even Eclipse has a browser-based version now - Orion. It's not a huge deal - there are over a hundred alternative languages that compile to javascript out there now, many of which do support compiling in the browser: https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS https://github.com/jashkenas/coffee-script/wiki/List-of-lang...

michaelwww 14y ago
Dart source is run by the Dart engine similarly to how JavaScript is run by the JavaScript engine, so you should be able to edit Dart source in a browser and run it if that browser includes the Dart VM (Dartium).
munificent 14y ago
> dart can't compile locally in the browser dart2js is written in Dart. There's some small amount of work needed to self-host it and run the result in a browser, mainly swapping out the file IO API with something that works on the web. I think multiple people on the team have slapped together working examples of this, so it's not a lot of work. It isn't a high priority for the dart2js team right now, though, and they are very careful to avoid taking on responsibility for features or use cases that don't have solid tests. I think before too long, we will have a reliably self-hosted Dart->JS compiler that runs in a browser, we're just focused on other stuff for the moment.