6 ms·

I disagree with his premise. The Dart to JS compiler doesn't have to be "decent" compared to having the Dart VM in the browser to be useful in a world where ot

I disagree with his premise. The Dart to JS compiler doesn't have to be "decent" compared to having the Dart VM in the browser to be useful in a world where other browsers don't use the Dart VM, it merely has to be "decent" compared to handcrafted JavaScript performing the same task in another browser. If direct Dart code runs faster than JavaScript on Chrome, that's a nice bonus, but if it runs as well as similar code that was originally written in JavaScript on the other browsers (when the Dart code is compiled to JS) that's good enough. Dart on the other browsers isn't competing with Dart on Chrome, it is competing with JavaScript on the other browsers and that's how it should be measured. And if it turns out apps in Dart on Chrome really blow away apps in JavaScript on other browsers to the point where both devs and users start embracing Chrome even more for these gains then hopefully that will light a fire under everyone else to either adopt Dart or do something to fix what would then be an undeniable problem of JavaScript.

thristian 15y ago
I think you have missed the context of his remarks; perhaps I should have pasted more from the original post. You seem to be talking about "what is necessary for Dart to be a viable Web content language", while (I believe) Brendan is talking about "what are the consequences if Dart becomes a viable Web content language". If the Dart → JS compiler produces "good enough" results, and web authors wind up adopting it en masse, then suddenly a chunk of the web "works best in Google Chrome", and every other browser manufacturer is put into a very, very awkward position. They can do nothing, in which case their continued relevance depends on Google continuing to ship the Dart → JS compiler (and diminishes as users switch to Chrome). They can license the Dart VM from Google, in which case their continued relevance depends on Google continuing to license the VM and we have another large chunk of the Web based on a single binary monoculture (which worked so well for Flash!). Or, they can try to develop their own Dart VM, in which case they'll be eternally chasing the tail-lights of Google's VM, kept behind by Google's head-start and Google's engineering power. None of those options is very pleasant, in the long run, for anybody who doesn't own Google stock. As Brendan's original comment points out, this choice is not unique to Dart. Currently browser makers have picked option 3 ("write our own") to deal with V8, option 2 ("licence Google's implementation") to deal with WebM, and so far option 1 ("ignore it") to deal with SPDY. Under the carefully-managed tension of ECMA, the ECMAScript standard has become a much more practical language to develop in directly, and to target from higher-level languages — and with the agreement of all the major browser vendors including Google. It's not immediately obvious that a project like Dart is even needed; even if it is a major technical advance, it's a political regression.
- georgemcbay 15y ago
  I understand the context and still disagree. If Dart is so much better than JavaScript on Chrome and if its Dart->JS engine does a good enough job of creating usable JS on other browsers that developers are willing to commit to using it to write apps then, well, that's too bad for everyone else, isn't it? Why should Google put the brakes on improving client side development just because it puts other browsers in the uncomfortable position of having to license Dart (for free, since it is OSS and has a liberal patent grant)? The same would be true if Microsoft created some sort of .NET->JS compiler with their own VM for IE, or if Mozilla did the same with some new language. As long as they bridge to JavaScript, more power to them. Client side web development could certainly use some of the tools that these different language environments could offer and if it kicks off another performance race to get browser-side languages even faster (especially on mobile devices), so much the better for everyone. I really don't see how there is any downside (to anyone but maybe Brendan Eich) to widespread usage of Dart unless the Dart->JS code proves to be suboptimal, but in that case devs won't use it.
  - thristian 15y ago
    When I first got onto the Internet, nearly every page I came across had a little image at the bottom saying "Best Viewed in Netscape Navigator". Since I was using Netscape, everything worked fine and I didn't care. Some time later, I began to see images saying "Best viewed in Internet Explorer". Everything still worked fine, so I still didn't care... but as time went on, more of those images popped up, and the pages they appeared on began to look much, much scrappier in Netscape than they did in Explorer. While most of them still worked, more or less, Explorer made a noticeable improvement. So, three cheers to Explorer for defeating Netscape and improving client-side development for everybody, right? Find a web-developer who still has to work with IE6 and ask them what they think. Right now, Dart is freely-licensed and available to everybody, but who can contribute to it? Who will be allowed to veto compatibility-breaking changes? What happens if Apple announces some new hardware platform, and then Google coincidentally decides that supporting that platform in the Dart VM is no longer a priority, refuses to accept patches for it, and later refactorings happen to make it very difficult to maintain outside the official tree? What if the Dart VM becomes strategically important like Android, and current releases are only available to approved partners? Sure, it's very unlikely that all those things would happen, and fairly unlikely that even one of them would: up until now, Google has stuck pretty close to the "do no evil" thing. But if we stick with openly, collaboratively created technologies, those things are impossible, and "impossible" is better than "unlikely" in my book. If Dart were some kind of server-side thing Google wanted to use to increase the responsiveness of their sites, or something else internal to their systems, I wouldn't care — they're allowed to do whatever they want in the privacy of their own servers. It's only because the value proposition of Dart is "give Google an inherent advantage of control over the Web, and in exchange you will get shiny things" that I'm concerned. There'll always be more shiny things, but (so far) there's only one Web.

thristian 15y ago

I think you have missed the context of his remarks; perhaps I should have pasted more from the original post. You seem to be talking about "what is necessary for Dart to be a viable Web content language", while (I believe) Brendan is talking about "what are the consequences if Dart becomes a viable Web content language". If the Dart → JS compiler produces "good enough" results, and web authors wind up adopting it en masse, then suddenly a chunk of the web "works best in Google Chrome", and every other browser manufacturer is put into a very, very awkward position. They can do nothing, in which case their continued relevance depends on Google continuing to ship the Dart → JS compiler (and diminishes as users switch to Chrome). They can license the Dart VM from Google, in which case their continued relevance depends on Google continuing to license the VM and we have another large chunk of the Web based on a single binary monoculture (which worked so well for Flash!). Or, they can try to develop their own Dart VM, in which case they'll be eternally chasing the tail-lights of Google's VM, kept behind by Google's head-start and Google's engineering power. None of those options is very pleasant, in the long run, for anybody who doesn't own Google stock. As Brendan's original comment points out, this choice is not unique to Dart. Currently browser makers have picked option 3 ("write our own") to deal with V8, option 2 ("licence Google's implementation") to deal with WebM, and so far option 1 ("ignore it") to deal with SPDY. Under the carefully-managed tension of ECMA, the ECMAScript standard has become a much more practical language to develop in directly, and to target from higher-level languages — and with the agreement of all the major browser vendors including Google. It's not immediately obvious that a project like Dart is even needed; even if it is a major technical advance, it's a political regression.

georgemcbay 15y ago
I understand the context and still disagree. If Dart is so much better than JavaScript on Chrome and if its Dart->JS engine does a good enough job of creating usable JS on other browsers that developers are willing to commit to using it to write apps then, well, that's too bad for everyone else, isn't it? Why should Google put the brakes on improving client side development just because it puts other browsers in the uncomfortable position of having to license Dart (for free, since it is OSS and has a liberal patent grant)? The same would be true if Microsoft created some sort of .NET->JS compiler with their own VM for IE, or if Mozilla did the same with some new language. As long as they bridge to JavaScript, more power to them. Client side web development could certainly use some of the tools that these different language environments could offer and if it kicks off another performance race to get browser-side languages even faster (especially on mobile devices), so much the better for everyone. I really don't see how there is any downside (to anyone but maybe Brendan Eich) to widespread usage of Dart unless the Dart->JS code proves to be suboptimal, but in that case devs won't use it.
- thristian 15y ago
  When I first got onto the Internet, nearly every page I came across had a little image at the bottom saying "Best Viewed in Netscape Navigator". Since I was using Netscape, everything worked fine and I didn't care. Some time later, I began to see images saying "Best viewed in Internet Explorer". Everything still worked fine, so I still didn't care... but as time went on, more of those images popped up, and the pages they appeared on began to look much, much scrappier in Netscape than they did in Explorer. While most of them still worked, more or less, Explorer made a noticeable improvement. So, three cheers to Explorer for defeating Netscape and improving client-side development for everybody, right? Find a web-developer who still has to work with IE6 and ask them what they think. Right now, Dart is freely-licensed and available to everybody, but who can contribute to it? Who will be allowed to veto compatibility-breaking changes? What happens if Apple announces some new hardware platform, and then Google coincidentally decides that supporting that platform in the Dart VM is no longer a priority, refuses to accept patches for it, and later refactorings happen to make it very difficult to maintain outside the official tree? What if the Dart VM becomes strategically important like Android, and current releases are only available to approved partners? Sure, it's very unlikely that all those things would happen, and fairly unlikely that even one of them would: up until now, Google has stuck pretty close to the "do no evil" thing. But if we stick with openly, collaboratively created technologies, those things are impossible, and "impossible" is better than "unlikely" in my book. If Dart were some kind of server-side thing Google wanted to use to increase the responsiveness of their sites, or something else internal to their systems, I wouldn't care — they're allowed to do whatever they want in the privacy of their own servers. It's only because the value proposition of Dart is "give Google an inherent advantage of control over the Web, and in exchange you will get shiny things" that I'm concerned. There'll always be more shiny things, but (so far) there's only one Web.