Summary: Discussion Dart Jabber? Shared Worker DOM Interactions problematic in large projects HTML5 HTML Library in Dart Chrome Automatic Updating Dart's Type System Multithreading - Icelets Dart executes the same code on the client or server side Dart editor Closures in Dart "Stupid questions" Basic standardized async support in Dart's core library Callbacks last ARM port, soon Read the license agreement How is Dart source stored/transferred No per-module overhead in translated versions Dart objects aren't necessarily simple JavaScript objects Dart snapshots Developers are listening to feedback Transcript JOACHIM: All right. Maybe it’s going to be “Dart Jabber” next? CHUCK: [Laughs] You have no idea how many people come to me and go, “I would really love a podcast like this on…“ and then they name a technology or a language. And so, I think the most popular one at this point that I get that I'm not doing is iOS programming. JOACHIM: Well it’s an amazing thing, right? I mean Apple has really… I mean yeah, saying the obvious, they’ve turned a lot around, right? CHUCK: Yeah. JOACHIM: Shoot AJ, shoot! AJ: [Chuckles] So I've been messing around just for the first time with the shared worker, and first of all, do you guys had any dealings with that, either in the standardization of it or implementing it in the browser? LARS: No, not really. So of course V8, or at least in Chrome, you get around these shared workers but I haven’t personally been involved in and the design of that part. AJ: All right. JOACHIM: So the thing that kind of struck me is that the problem with many applications that I've made that are of a larger scale hasn’t actually been JavaScript performants, it’s been DOM interactions and reflows and CSS and redrawing in the browser. And that’s still the case. So are you really trying to fix the right thing? Does Dart improve the DOM interactive situation? LARS: Well, now I have a system; we have a number of [unintelligible], right? When we started V8, JavaScript was certainly a in terms of execution, it will slow down the browser if you have too much logic. That’s not the case anymore. But I think that you have to be aware of that if you don’t have the speed, nobody will use JavaScript. And I think by now, there's room for putting more logic in the client. It is of course true that many web applications are constrained by the performance of the DOM, but a lot of that is also by addressed by other teams -- many of them here at Google. So I think it’s sort of a never ending game in speeding up the old browser. And I think that will continue for a while. We are however adding new APIs to the browser as part of the HTML5 standardization process. And I think all in all, what that would help is doing more advanced applications in the browser -- and it’s good for users. AJ: So does Dart provide its own DOM-type thing or do you still have to use the old school DOM with Dart? LARS: Well, the DOM interface is not very pretty. So we have put a little bit nicer interface on top and we call it the HTML Library in Dart and that has a cleaner interface to the DOM. It’s not much smaller in the DOM, but it’s a little bit cleaner. What we are also doing is we are putting a sort of a widget system on top of it, so you can program at a higher level if you want to; but that’s all up to you, right? It’s a matter of what kind of library you want to use when you build Dart applications. AJ: So transpiling Dart to JavaScript, one gain I might get is just being able to use the Dart DOM library and have it work on all browsers? Or will I still have to work around that? LARS: No, it’s the same API, but we are not… the current release of Dart will not work on old browsers, so we are focusing on modern browsers. AJ: Okay. So what is “modern“ enough? LARS: Internet Explorer 9, the newest version of Opera and FireFox and Safari and Chrome.
