3 ms·

> The Dart leads prioritized (1) over (2). The idea was that the VM would be so great users would flock to it giving us (2). This is actually why I, as a devel

by davedx 8y ago

> The Dart leads prioritized (1) over (2). The idea was that the VM would be so great users would flock to it giving us (2). This is actually why I, as a developer, decided not to use Dart: because it would give Chrome a competitive advantage and more control over the other browsers. Chrome has enough advantages as it is, and I like having competition in the browser market.

munificent 8y ago
The hope was that other browsers would eventually have Dart VMs too and there would still be fair competition. In many ways, this is similar the path that asm.js/WASM took. First it's polyfilled to JS in all browsers. Then some browsers get faster native support while still polyfilling the others. Then eventually all browsers support it natively. The initial asm.js design was a little different because as a subset of JS, the polyfill was a no-op. But the binary form of WASM, I think, required a JS polyfill on browsers that didn't support it natively. Dart could have taken a similar path, but we didn't get the level of user excitement required to motivate browsers to follow along.
- BrendanEich 8y ago
  Hi Bob - quick comment in this. The comparable to DartVM is not WebAssembly but PNaCl, which was Chrome-only. Wasm was much easier because asm.js proved the concept source-compatibly and in multiple browsers. I spoke to Anders Hejlsberg, Steve Lucco, and others at MS in fall 2013 and they got on board, even using OdinMonkey code licensed under ASL2 by Mozilla to overcome MS objections to the MPL. Meanwhile Dartium could not land in WebKit pre-Blink, because two GCs impose a cycle collector “super-GC” with inevitable extra cost. See https://lists.webkit.org/pipermail/webkit-dev/2011-December/018811.html https://lists.webkit.org/pipermail/webkit-dev/2011-December/... (I found this link from my HN post at https://news.ycombinator.com/item?id=12773857 https://news.ycombinator.com/item?id=12773857). DartVM like PNaCl was trying for too much in Chrome, exceeding what other browsers could afford to embrace at high direct and opportunity costs in a competitive post-Chrome browser market. A spec would take many years and multiple competing implementations to forge. Code is spec with such big single-company-grown projects.

by davedx 8y ago

munificent 8y ago

The hope was that other browsers would eventually have Dart VMs too and there would still be fair competition. In many ways, this is similar the path that asm.js/WASM took. First it's polyfilled to JS in all browsers. Then some browsers get faster native support while still polyfilling the others. Then eventually all browsers support it natively. The initial asm.js design was a little different because as a subset of JS, the polyfill was a no-op. But the binary form of WASM, I think, required a JS polyfill on browsers that didn't support it natively. Dart could have taken a similar path, but we didn't get the level of user excitement required to motivate browsers to follow along.

BrendanEich 8y ago
Hi Bob - quick comment in this. The comparable to DartVM is not WebAssembly but PNaCl, which was Chrome-only. Wasm was much easier because asm.js proved the concept source-compatibly and in multiple browsers. I spoke to Anders Hejlsberg, Steve Lucco, and others at MS in fall 2013 and they got on board, even using OdinMonkey code licensed under ASL2 by Mozilla to overcome MS objections to the MPL. Meanwhile Dartium could not land in WebKit pre-Blink, because two GCs impose a cycle collector “super-GC” with inevitable extra cost. See https://lists.webkit.org/pipermail/webkit-dev/2011-December/018811.html https://lists.webkit.org/pipermail/webkit-dev/2011-December/... (I found this link from my HN post at https://news.ycombinator.com/item?id=12773857 https://news.ycombinator.com/item?id=12773857). DartVM like PNaCl was trying for too much in Chrome, exceeding what other browsers could afford to embrace at high direct and opportunity costs in a competitive post-Chrome browser market. A spec would take many years and multiple competing implementations to forge. Code is spec with such big single-company-grown projects.