SPDY is an example of a great idea, good enough that Mozilla is adopting it. Apparently, you're saying that, like SPDY, even if everyone agreed that Dart and NaCl were great ideas and great for the web, Mozilla still vote against them for political or aesthetic reasons. So part of "getting early feedback" as you alluded to above, is getting early politically motivated feedback. How is this a good thing? You should vote on technical proposals based on the intrinsic merit.
Almost all of the additions to the browser API that Google has made are desired to make it into spec proposals. There is no desire for Chrome to be the only implementor of Dart or NaCL.
I'm a little concerned what you're saying here. That if an idea is good, it won't be adopted anyway, just because someone else has greater resources to implement it. It sounds like Not-invented-here syndrome to me. No matter what technical specs are proposed, Google is always going to have greater resources to develop them.
Everything you say about Mozilla, I can say about my experience at Google. The first release of Dart was very incomplete, it didn't implement a lot of the type system, no missing method, some stuff like default method parameters didn't exist. It generally really slow and bloated code. It was in a barely working state. The DartC compiler which was implemented in Java was not a production compiler design to be used by people, it was a prototype for research. This idea that Google sprang a fully-formed already finished product on everyone is a gross exaggeration. The Dart VM isn't even in Chromium yet.
The self-hosted compiler (Frog, written in Dart) has been developed completely in the open.
Google is a large company with hundreds and hundreds of projects, so not all of them operate the same way, but many of them are open sourced very early in the process, and Googlers push to release source early for client side web technologies. Google has spent hundreds of millions of dollars on acquisitions which it immediately turned around and open sourced, like WebM, and the first Google Web Toolkit, and Instantiation's products (donated to Eclipse Foundation)
Really, I think the comments on NaCl and Dart are patently unfair. They were released practically as early as they could have been, NaCL took, what, 2-3 years in the open of development before it was finally pushed to production.
Ultimately, if standards committees get gridlocked over political and emotional stuff, instead over the merits of technology, you will see people start to ignore them. A similar thing happened in with OpenGL ARB where vendors who had less resources voted down and blocked companies like NVidia and ATI who were progressing chips at a faster pace. Ultimately, it took DirectX surpassing OpenGL to push it to finally start evolving faster again.
Yes, SPDY is a great idea, and of course I don't think that it -- or other ideas -- should be rejected just because of who proposes them or when. (As a concrete example, I am the lead editor of the W3C Touch Events spec and worked on implementing it in Gecko; it is an API that I absolutely believe should be standardized even though I strongly dislike how Apple originally designed and deployed it.)
I do think we agree on fundamentals though we may disagree on some cost-benefit analysis. All I meant about the "treadmill" is that some proposals have a much greater cost to implementers than others, and different organizations will weigh those costs differently. While some debaters may throw out "political or emotional" responses, I believe the decision-making process should be (and is, in the cases I've participated in) about allocation of resources, complexity of implementation, and the desired architecture of the web.
Technical issues and process issues are separate, but affect each other. When I say the process behind something like Touch Events was bad, I'm not giving that as a reason to reject the feature -- I think the feature should be accepted or rejected on its merits, like you said -- but it does mean that any technical objections that do appear will be much harder to resolve than they might have been. And as you say, Dart and NaCL have had better process behind them than Touch Events or various other extensions I could name. Dart and NaCL may succeed or they may fail (just as many of Mozilla's current experiments may suceed or fail), but at least their fates will be influenced by feedback from all stakeholders.
You are obviously better informed than I am about Dart and NaCL implementation. (Also, I accidentally conflated Go and Dart in my previous comment, which is embarrassing!) I apologize for any uninformed comments and defer to you on all the facts there.
I really don't want people to see this as a "Mozilla versus Google" thread. I hope everyone cares about standards issues because they help or hurt the web, not because they helps their favorite vendor or hurt a competing one. In the big picture, Google and Mozilla are close allies when it comes to web standards. As you say, the real risks to the open web are elsewhere.
Almost all of the additions to the browser API that Google has made are desired to make it into spec proposals. There is no desire for Chrome to be the only implementor of Dart or NaCL.
I'm a little concerned what you're saying here. That if an idea is good, it won't be adopted anyway, just because someone else has greater resources to implement it. It sounds like Not-invented-here syndrome to me. No matter what technical specs are proposed, Google is always going to have greater resources to develop them.
Everything you say about Mozilla, I can say about my experience at Google. The first release of Dart was very incomplete, it didn't implement a lot of the type system, no missing method, some stuff like default method parameters didn't exist. It generally really slow and bloated code. It was in a barely working state. The DartC compiler which was implemented in Java was not a production compiler design to be used by people, it was a prototype for research. This idea that Google sprang a fully-formed already finished product on everyone is a gross exaggeration. The Dart VM isn't even in Chromium yet.
The self-hosted compiler (Frog, written in Dart) has been developed completely in the open.
Google is a large company with hundreds and hundreds of projects, so not all of them operate the same way, but many of them are open sourced very early in the process, and Googlers push to release source early for client side web technologies. Google has spent hundreds of millions of dollars on acquisitions which it immediately turned around and open sourced, like WebM, and the first Google Web Toolkit, and Instantiation's products (donated to Eclipse Foundation)
Really, I think the comments on NaCl and Dart are patently unfair. They were released practically as early as they could have been, NaCL took, what, 2-3 years in the open of development before it was finally pushed to production.
Ultimately, if standards committees get gridlocked over political and emotional stuff, instead over the merits of technology, you will see people start to ignore them. A similar thing happened in with OpenGL ARB where vendors who had less resources voted down and blocked companies like NVidia and ATI who were progressing chips at a faster pace. Ultimately, it took DirectX surpassing OpenGL to push it to finally start evolving faster again.