3 ms·

Hi Ray I respect your work a lot, but are you sure your view is not biased a bit by working for Google? It's sometimes hard to disconnect from that kind of wor

by RyanZAG 13y ago

Hi Ray I respect your work a lot, but are you sure your view is not biased a bit by working for Google? It's sometimes hard to disconnect from that kind of working environment to see the kind of issues into the future certain practices can have. Dart turning into something bad for the web is really not all that unfounded or unjustified. You don't have to agree, but you shouldn't dismiss that argument so quickly. Dismissing this kind of thing is what leads to 'impossible' scenarios happening. The point needs to be raised, repeatedly, and hopefully within Google as well. As long as a possibility exists for Google to misuse Dart, there needs to be voices speaking out against that possible misuses before it occurs, not after.

cromwellian 13y ago
Dart is no more an attempt to replace the web with a walled garden than GWT is (which is what I work on). It is a tool, like Typescript, like CoffeeScript, like ClojureScript, like Emscripten. There's no "plan" to create a lock-in walled garden based around programming language. Google is interested in making the experience of developing web apps better, and making web apps more performant. They have many different strategies for this: Chrome DevTools, AngularJs, Web Components and other spec improvements, Dart, Closure Compiler, GWT, etc. The company does not make money from selling the Chrome browser, and unlike Microsoft, it doesn't make money from selling an OS. The incentives are not aligned like the way they were with IE and Windows. At the end of the day, Google makes money from people using the web. The real threat is from the Web falling too far behind Native. Also, the Web is far far bigger than the programming language Javascript. For the first 10+ years of the Web, people hardly even used JS except for form validation, and in general, on mobile, excessive amounts of JS lead to poor performance. There's still a ways to go on just HTML and CSS, and I'd frankly be more concerned about fragmentation in that area rather than fixation on Javascript. The way I see the potential of a DartVM is the same as OdinMonkey+asm.js. Dart compiles to JS, but DartVM will run it slightly faster, but it will always work on all browsers. Likewise, asm.js will work on all browsers, but will always run faster on OdinMonkey. Both Mozilla and Google have VMs that potentially bifurcate performance across browsers, but still produce outputs that can run (albeit slower) The concerns you should have about Google misusing Dart I think should really be about Google misusing market share. It's not really Dart per se that's the issue, it's the fact that if Chrome is the dominant browser, Google can drop anything they want into it, not just Dart, but any APIs they want.
- pcwalton 13y ago
  The asm.js comparison is a false equivalence. It is not possible (without explicit effort, e.g. checking the UA string) for Web authors to ship asm.js that does not work in Chrome, because asm.js is just JavaScript. With Dart, Web authors may end up not shipping the JS fallback, or not testing it, thus locking the Web into Chrome. That is why turning on the Dart VM for Web content would be a problem.
  - cromwellian 13y ago
    It's a false equivalence in theory, but in practice, I don't think so. Realistically, how many developers are not going to ship something that doesn't work on Firefox and Safari, especially, Mobile Safari? Especially when the tools to do this are trivial and automatic. It's much harder to write cross-browser CSS, with full GPU compositing, and responsive layout than it is to compile Dart to JS. What is the incentive for the developer not to do is and leave a huge chunk of marketshare on the table with little effort? Stuff like prefixed-CSS is a far far worse threat to the Web than a DartVM.
    - pcwalton 13y ago
      Of course people won't ship something that doesn't work cross-browser today. But by that logic, no proprietary feature is worth worrying about. Consider a hypothetical future in which Chrome had 90% market share: as a Web dev, would you bother shipping or testing the JS fallback? History tells us what will happen.
      - cromwellian 13y ago
        If Chrome gets 90% marketshare, there'll be other problems besides Dart. History also tells us that even if all vendors adhere to standard specs, there will be implementation differences and bugs that still require developers to write browser specific code and fixups. Again, I'm not disagreeing that there is a danger of fragmentation, but this won't happen because of Dart, but because of other forces. The criticism over the DartVM is being blown way out of proportion. The best defense against any of this happening is not to protest Dart, but to make sure the browser market is competitive.

by RyanZAG 13y ago

cromwellian 13y ago

Dart is no more an attempt to replace the web with a walled garden than GWT is (which is what I work on). It is a tool, like Typescript, like CoffeeScript, like ClojureScript, like Emscripten. There's no "plan" to create a lock-in walled garden based around programming language. Google is interested in making the experience of developing web apps better, and making web apps more performant. They have many different strategies for this: Chrome DevTools, AngularJs, Web Components and other spec improvements, Dart, Closure Compiler, GWT, etc. The company does not make money from selling the Chrome browser, and unlike Microsoft, it doesn't make money from selling an OS. The incentives are not aligned like the way they were with IE and Windows. At the end of the day, Google makes money from people using the web. The real threat is from the Web falling too far behind Native. Also, the Web is far far bigger than the programming language Javascript. For the first 10+ years of the Web, people hardly even used JS except for form validation, and in general, on mobile, excessive amounts of JS lead to poor performance. There's still a ways to go on just HTML and CSS, and I'd frankly be more concerned about fragmentation in that area rather than fixation on Javascript. The way I see the potential of a DartVM is the same as OdinMonkey+asm.js. Dart compiles to JS, but DartVM will run it slightly faster, but it will always work on all browsers. Likewise, asm.js will work on all browsers, but will always run faster on OdinMonkey. Both Mozilla and Google have VMs that potentially bifurcate performance across browsers, but still produce outputs that can run (albeit slower) The concerns you should have about Google misusing Dart I think should really be about Google misusing market share. It's not really Dart per se that's the issue, it's the fact that if Chrome is the dominant browser, Google can drop anything they want into it, not just Dart, but any APIs they want.

pcwalton 13y ago
The asm.js comparison is a false equivalence. It is not possible (without explicit effort, e.g. checking the UA string) for Web authors to ship asm.js that does not work in Chrome, because asm.js is just JavaScript. With Dart, Web authors may end up not shipping the JS fallback, or not testing it, thus locking the Web into Chrome. That is why turning on the Dart VM for Web content would be a problem.
- cromwellian 13y ago
  It's a false equivalence in theory, but in practice, I don't think so. Realistically, how many developers are not going to ship something that doesn't work on Firefox and Safari, especially, Mobile Safari? Especially when the tools to do this are trivial and automatic. It's much harder to write cross-browser CSS, with full GPU compositing, and responsive layout than it is to compile Dart to JS. What is the incentive for the developer not to do is and leave a huge chunk of marketshare on the table with little effort? Stuff like prefixed-CSS is a far far worse threat to the Web than a DartVM.
  - pcwalton 13y ago
    Of course people won't ship something that doesn't work cross-browser today. But by that logic, no proprietary feature is worth worrying about. Consider a hypothetical future in which Chrome had 90% market share: as a Web dev, would you bother shipping or testing the JS fallback? History tells us what will happen.
    - cromwellian 13y ago
      If Chrome gets 90% marketshare, there'll be other problems besides Dart. History also tells us that even if all vendors adhere to standard specs, there will be implementation differences and bugs that still require developers to write browser specific code and fixups. Again, I'm not disagreeing that there is a danger of fragmentation, but this won't happen because of Dart, but because of other forces. The criticism over the DartVM is being blown way out of proportion. The best defense against any of this happening is not to protest Dart, but to make sure the browser market is competitive.