Live data from Hacker News

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

channel9.msdn.com

51–60 of 69 posts

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

#51

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

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

#52

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

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.

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

#53
post #48

Earlier quoted context omitted.

> Dart has special data types for the VM. It has optional types, like many compiled-to-JS languages (as lack of declared types is one of the motivations for such languages.) I don't know what you mean by "special data types for the VM". Can you provide some examples? > They clearly want to target the VM for fast applications that aren't very usable compiled to JavaScript. Obviously, they think that the VM will provid…

https://docs.google.com/presentation/d/1zfucLA3XNqRb7W56ldU_...

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 implementations that would be attainable, its just taking advantage of not being stuck with JavaScript's lack of types to further optimize the performance of Dart-on-its-own-VM.

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

#54
post #49

Earlier quoted context omitted.

I doubt they are expecting Apple and Microsoft to incorporate the Dart VM, so they are putting a lot of effort into the JavaScript output. The Dart VM really comes into play in the near future for Chrome Packaged Apps. They interesting thing is loading snap shots of the virtual machine state quickly. http://www.infoq.com/articles/google-dart

Date of the article: Oct 24, 2011

Thanks for catching that. Snapshots are still being worked on. Here's Feb 2013 info. http://www.dartlang.org/articles/snapshots/

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

#55

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

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

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

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

#56

Earlier quoted context omitted.

> You don't say if you used the 'dart2js --minify' setting I did. I'm no stranger to Closure Compiler, and even after fiddling around with ADVANCED_OPTIMIZATIONS for an hour, those ridiculous $variables persisted. What was even weirder was, just as a test, I imported a module I wasn't even using at all, and for some reason, Closure Compiler still refused to remove its code...

Just for grins, I compiled the Dart app I'm working on now with --minify. It went from 530K to 240K. Then I cleared the --minify flag and used the Closure Compiler but it failed with errors. Not sure what is going on yet, but I don't think this is necessary or advisable -- I've never read of anyone using the Closure Compiler with Dart. Here is a sample few lines from --minify. It's fairly minimal. function I(){} init…

Okay, but um, why did minify not get rid of the module i wasn't even using?

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

#57
post #55

Earlier quoted context omitted.

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

--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 a compiler, so, it should be doing compiler-y shit.

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

#58

Earlier quoted context omitted.

Just for grins, I compiled the Dart app I'm working on now with --minify. It went from 530K to 240K. Then I cleared the --minify flag and used the Closure Compiler but it failed with errors. Not sure what is going on yet, but I don't think this is necessary or advisable -- I've never read of anyone using the Closure Compiler with Dart. Here is a sample few lines from --minify. It's fairly minimal. function I(){} init…

Okay, but um, why did minify not get rid of the module i wasn't even using?

Just to be clear, here is what I did.

  Dart source -> dart2js -> JavaScript (530K) 
  Dart source -> dart2js -> JavaScript (530K) -> Closure Compiler -> *error*  
  Dart source -> dart2js --minify -> JavaScript (240K)
If I import a module and don't use it, such as 'dart:utf', the resulting JavaScript output size does not go up. If I call a function in dart:utf the JavaScript size goes up. If I stop calling the function, the size goes down. If I create a function but don't call it, the size stays the same. If I call it, the size goes up. Everything seems to be working. They just release a new version a few days ago and I'm on the latest.

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

#59
post #48

Earlier quoted context omitted.

https://docs.google.com/presentation/d/1zfucLA3XNqRb7W56ldU_...

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.

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

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

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