> "proprietary" is unfair, and becomes more unfair all the time now that Dart is on its way to ECMA standardizationBy "proprietary", I mean only executable by one client.
I had not read about Dart's ECMA standardization process (TC52). I think that's great news, but to be fair, that announcement was made just two days ago:
http://news.dartlang.org/2013/12/ecma-forms-tc52-for-dart-st...
> If Dart is "proprietary," then so is asm.js, Mozilla Persona, Rust, and many other cool things that Mozilla is doing.
I don't think asm.js, Rust, dart2js, or Go are "proprietary" because their implementations are open and their output can be executed by multiple platforms or clients. Dart source files is only executable by Google's Dart VM.
> This is exactly the kind of bad faith presumption that troubles me. Google is trying to push the web forward but in your mind their end game is to break its web properties for every browser except Chrome?
I do not think Google is plotting to create a walled garden (unlike Microsoft of the 1990s). But I think many people at Mozilla worry about future timelines where proprietary systems could be created, even if they are the inadvertent, cumulative result of different product teams' decisions.
Consider Google Hangouts. When Hangouts was launched in May of this year, it included an NPAPI plugin to support other browsers like Firefox. But now, only seven months later, the Hangouts service is very popular but is only accessible from as a Chrome extension. The Firefox NPAPI plugin is no longer supported or available for download.
Or consider Chrome's announcement to drop NPAPI itself. NPAPI is the source of much woe and instability for Firefox, but NPAPI is a de facto standard for browser-independent content. Pepper, the proposed replacement, is only implemented by Chrome. The only version of the Adobe Flash Player that uses Pepper is the Chrome port maintained by Google engineers. (Disclosure: I work at Mozilla and I used to work on Adobe's Flash Player team.) A co-worker at Mozilla told me that he asked a friend on the Chrome team "How much of the Pepper API does Chrome's Flash Player use?" and the half-joking response was "150%" because Chrome's Flash Player relied on Chrome internals that were not exposed in the Pepper API.
Or consider Google's 2011 promise to drop support for H.264 from Chrome. Google had the leverage with YouTube to migrate content and clients from H.264 to WebM, but that never happened. Even today, many YouTube videos are not encoded as WebM and content creators have a strong incentive to publish H.264 videos because Google Ads only support YouTube's Flash player.