top | item 5424680

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

59 points| michaelwww | 13 years ago |channel9.msdn.com | reply

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.

67 comments

order
[+] michaelwww|13 years ago|reply
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.

[+] yonran|13 years ago|reply
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-c...). I’m disappointed that nobody from Google Closure has stepped up to unify TypeScript and Closure’s syntax and to provide better tooling.
[+] seanalltogether|13 years ago|reply
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|13 years ago|reply
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

[2] http://blogs.msdn.com/b/ie/archive/2007/10/30/ecmascript-3-a...

[+] chr1|13 years ago|reply
Probably you've seen examples of ES6 which is actively developed now, and many features from it are already available in firefox nightlies. ES4 was abandoned 3-4 years ago. It was partially implemented in firefox, and ff addons used it. One of it's features that didn't made into ES6 was inline xml inside javascript. It was recently removed from firefox.
[+] dugmartin|13 years ago|reply
It looks very much like ECMAScript 4. I've done a lot (too much) Flex/AS3 coding and I plan on using TypeScript for my next big Javascript project. Static type checking makes a whole class of problems on large applications just go away.
[+] camus|13 years ago|reply
ES4 ~= Action Script (with packages , classes , interfaces ,etc...)

The problem with typescript is that there is no real built-in module support you either need AMD or CommonJS that's why i wont use it.

The language is great but i dont want to have to use requireJS to create reusable components.

Funny how Microsoft rejected ES4 and now is "praising" and "advocating" for better web scripting language. That's hypocrisy.

[+] pnt|13 years ago|reply
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.
[+] dragonwriter|13 years ago|reply
> 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.

[+] mtgx|13 years ago|reply
Anything really new would be like that. WebGL was also Firefox-only for a while, until Chrome decided to adopt it. To make them a standard across browsers you either need to make them very popular, and make the others have no choice but adopting it, or collaborating. But the last one seems to happen less and less lately, with all companies.
[+] michaelwww|13 years ago|reply
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.
[+] edtechdev|13 years ago|reply
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-lang...

[+] munificent|13 years ago|reply
> 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.

[+] michaelwww|13 years ago|reply
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).
[+] sultezdukes|13 years ago|reply
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|13 years ago|reply
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.

[+] michaelwww|13 years ago|reply
I think of the Dart VM as a dev tool. The goal is to use dart2js for production output. The Dart VM will eventually be very useful in Chrome Packaged Apps once Chrome has it built in. Google has a ton of experience with Google Web Toolkit to write JavaScript apps such as Gmail in Java. Dart is branch of that evolution. I am not even sure if they care all that much if the rest of use it. It seems to me an internal tool that they've open sourced. I see no plans to force it on the market.
[+] camus|13 years ago|reply
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...
[+] mhd|13 years ago|reply
Well, Haxe seems squarely aimed at the game sector, first with Flash, now with HTML5. There are quite a few possibilities, but I don't really see a big movement towards the "normal" web application area, even the nodejs/C++/Neko web wrappers seem a bit oriented towards providing backends for games. I'm not asking for Haxe's equivalent to Rails, but something like flask, sinatra, express or compojure would be nice. (Supported, with some mindshare behind it -- I'm aware that there are a few fledgling webapp frameworks on github)

Not that the game has been called, Typescript and Dart themselves have been out for a while and don't really took large slices of the pie. The biggest "transpiled" Javascript language is still Coffeescript, and that's basically Ratfor for the web.

There's also Opa and Fantom, if we're going even more esoteric...

( http://fantom.org/ and http://opalang.org/ )

[+] jdonaldson|13 years ago|reply
Haxe 3 is just around the corner, the RC is out right now. 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|13 years ago|reply
It's unfortunate that Haxe doesn't get the recognition it deserves. The type system and other features blow anything comparable out of the water.

The language and compiler are solid, what it needs is better documentation, getting started guides, and tooling for things other than games with NME.

[+] coolsunglasses|13 years ago|reply
Stop trying to make Haxe happen, it's not going to happen.
[+] andyl|13 years ago|reply
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|13 years ago|reply
Also nobody with the sense of history to design proper lexical scoping of variables.
[+] rwaldron|13 years ago|reply
...No formal semantic or syntactic specification...
[+] ttrreeww|13 years ago|reply
Transcript?
[+] michaelwww|13 years ago|reply
Doesn't appear to be one. The quotes I lifted start at 11:23