Live data from Hacker News

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

channel9.msdn.com

61–69 of 69 posts

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

#61
post #19
post #15

Earlier quoted context omitted.

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…

> 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 , b…

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

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

#62
post #59

Earlier quoted context omitted.

Okay, so you are talking about exposing integer vs. double distinction (because CPUs are better at int math) and the SIMD support in the Dart VM. All of those are using explicit typing to do better at mapping from what the developer does to what the native hardware supports than is possible without explicit types in JS, sure. I don't see why this is a bad thing -- its not sacrificing performance in Dart-to-JS impleme…

The Dart VM being faster than JavaScript can be a problem in itself. But with SIMD you'll get a lot of "Only usable in Dart VM" for a lot of apps (mainly games) written in Dart, because then the necessary speed for many game operations gets possible. I don't want back to the "Best viewed in IE 5.5 and 1024x768 Pixels" times.

You're complaining about more speed? Why don't we see the same complaints with asm.js?

If SIMD on Dart works out well, you can bet JS will get SIMD support too, and then dart2js will use that. It's this type of competition that pushes things forward.

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

#63
post #59

Earlier quoted context omitted.

Okay, so you are talking about exposing integer vs. double distinction (because CPUs are better at int math) and the SIMD support in the Dart VM. All of those are using explicit typing to do better at mapping from what the developer does to what the native hardware supports than is possible without explicit types in JS, sure. I don't see why this is a bad thing -- its not sacrificing performance in Dart-to-JS impleme…

The Dart VM being faster than JavaScript can be a problem in itself. But with SIMD you'll get a lot of "Only usable in Dart VM" for a lot of apps (mainly games) written in Dart, because then the necessary speed for many game operations gets possible. I don't want back to the "Best viewed in IE 5.5 and 1024x768 Pixels" times.

Games often require special platforms. They're not web pages in the strict sense.

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

#64
post #55

Earlier quoted context omitted.

--minify is still being improved and is not complete yet. As well, you need to say what libs you included. If you import "HTML" it is basically like including jquery.

Right, but the great thing about a compiled language like Dart is that it can detect at compile-time which modules aren't being used and then exclude those from the js output. Except, it doesn't seem to ever do that. EDIT: Well, technically, Dart is actually designed to be interpreted (or JIT compiled, or what have you) by the Dart VM, so calling it a "compiled language" was incorrect on my part. However, dart2js is…

Tree-shaking is the term for removal of uncalled functions. The minifier is still early on so expect it to get better with time.

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

#65
post #59

Earlier quoted context omitted.

Okay, so you are talking about exposing integer vs. double distinction (because CPUs are better at int math) and the SIMD support in the Dart VM. All of those are using explicit typing to do better at mapping from what the developer does to what the native hardware supports than is possible without explicit types in JS, sure. I don't see why this is a bad thing -- its not sacrificing performance in Dart-to-JS impleme…

The Dart VM being faster than JavaScript can be a problem in itself. But with SIMD you'll get a lot of "Only usable in Dart VM" for a lot of apps (mainly games) written in Dart, because then the necessary speed for many game operations gets possible. I don't want back to the "Best viewed in IE 5.5 and 1024x768 Pixels" times.

> The Dart VM being faster than JavaScript can be a problem in itself. But with SIMD you'll get a lot of "Only usable in Dart VM" for a lot of apps (mainly games) written in Dart, because then the necessary speed for many game operations gets possible.

Yes, building performance improvements into the Dart VM that go beyond something that is found in most JS engines means that there is the possibility that (given equivalent hardware) some things that peform acceptably on the Dart VM won't perform acceptably when relying on Dart-2-JS.

Which would be a problem if there was a barrier to other browser vendors incorporating the Dart VM, or adapting it to platforms that Google doesn't support. But there's not, and the whole point of Dart -- and why there is a Dart VM -- is because Dart is an effort to provide an alternative to JavaScript, with dart2js as a mechanism to make development in Dart useful even before Dart VM adoption takes off.

But dart2js isn't the long-term goal, its a tool to get passed the problem that without runtime deployment, no one will develop, and without development, no one will deploy the runtime.

> I don't want back to the "Best viewed in IE 5.5 and 1024x768 Pixels" times.

And I don't want the web to stagnate because we can't do anything that might work better than what exist now.

Good thing about new efforts being open is that they avoid both problems.

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

#66
post #9

Earlier quoted context omitted.

Dart is Google's Silverlight.

ActionScript/Flash and .NET/SilverLight require a plugin, with Dart the "plugin" is optional.

It's called the Dart Runtime which is not included in non Google browsers.

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

#67

Earlier quoted context omitted.

ActionScript/Flash and .NET/SilverLight require a plugin, with Dart the "plugin" is optional.

It's called the Dart Runtime which is not included in non Google browsers.

Except: 1. The Dart VM isn't included in Google's generally-released browsers, either (it's included in Dartium, the special version of Chromium bundled with the Dart SDK). 2. The Dart VM isn't a plug-in. 3. As Dart compiles to JS, you don't need the Dart VM to run code developed with Dart, you just need a browser that supports JS.

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

#68

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…

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

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

#69
post #9
post #7

Earlier quoted context omitted.

> 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 regard…

Dart is Google's Silverlight.

A couple of clarifications:

* Dart compiles to JavaScript, Silverlight did not. * Dart is actively being developed, Silverlight is not. * Dart does not require any plugins, Silverlight did. * Dart natively supports the DOM, Silverlight did not.

[disclaimer: I work on the Dart team]

Post reply on HN