Not everything is standardized, sadly. Even the things that are ... well, https://bugs.chromium.org/p/chromium/issues/detail?id=690195 is an example from just earlier today where Chrome went to implement a spec, decided what the spec said was not convenient, and just implemented something else without bothering to raise a spec issue or anything. See https://github.com/whatwg/html/issues/2568 for the resulting lack of interop that the standards now have to sort out. This doesn't always happen, of course, but it happens often enough.

Anyway, the Chrome team itself is, by and large, pretty good to work with (some exceptions like their "let's force-install this on unwitting users' computers" marketing deals notwithstanding). Other parts of Google are very much less great. Getting Gmail to work with your browser unless you spoof the UA string of some other existing browser is an exercise in futility.

That's not really Chrome's fault - it's the fault of the respective (Hangouts, Earth, Inbox) product teams. We didn't blame Microsoft for "lock-in" back in the IE-only website days, I think it would be fair to give Google that latitude unless you are ascribing nefarious motives above and beyond what lazy/resource-constrained web devs used to do with IE6-only web sites/apps.

Yes, we did. Very loudly and very frequently. So loudly and frequently that the company was charged with violating the Sherman Antitrust Act.

The expression "embrace, extend, extinguish"[1] was first used to describe Microsoft's attempt to "lock-in" the WWW. Introducing incompatibilities into IE and proprietary extensions (ActiveX, which Google is copying with NaCL) allowed make a show of embracing open standards as bait for the lock-in. This isn't theoretical - in Bill Gates's own words[2]:

>> "One thing we have got to change in our strategy--allowing Office documents to be rendered very well by other peoples [sic] browsers is one of the most destructive things we could do to the company. We have to stop putting any effort into this and make sure that Office documents very well depends on PROPRIETARY IE capabilities. Anything else is suicide for our platform."

[1] https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish

[2] (pdf) http://antitrust.slated.org/www.iowaconsumercase.org/011607/...

>Yes, we did.

My phrasing wasn't as clear as I thought - what I meant to say "We didn't blame Microsoft for 'lock-in' due to 3rd parties creating IE-only websites, we blamed the 3rd parties." Implementing non-standard extensions was par for the course during the browser wars (Netscape did the same), and I doubt there was a real expectation of achieving lock-in via the browser by either party: Windows achieved lock-in via Windows, Office and legal threats. Not IE.

And yes, there was very much expectation of achieving lock-in via ActiveX. And it worked in some cases.

It's Chrome's fault that it's shipping non-standard things. Not like any browser is blameless here, but let's not pretend they're innocent either.

It's _Google's_ fault that it's shipping non-standard things in its browser and then using them in its other products to lock out other browsers.

> We didn't blame Microsoft for "lock-in" back in the IE-only website days

We sure did. And it wasn't even Microsoft creating the IE-only websites!

I challenge you to name one non-niche browser that didn't ship "non-standard things"

In the case of NaCl, Google got around their own pledge by declaring NaCl "not part of Blink" and therefore not subject to the Blink rules, which was a cop-out if I've ever seen one.

Chrome has done a lot more promotion of its non-standard things and of course Google as a whole has been using Chrome's non-standard things quite a bit, which is a large part of the problem.

NaCL - Completely open, patent grants, open source, etc. Not a standard, but they did everything possible to move there, and abandoned it when it didn't get interest from others.

Anything else?

Few Web developers wanted Dart, and this was clear at the time Google went to ECMA. They pushed ahead with a standard anyway despite no other browser vendor signing on board. You can call anything a standard, but without a multi-vendor process, and with only a single implementation, the idea of a standard is pretty meaningless.

And, regarding Dart, on the WebKit side, many WebKit contributors were (quite reasonably) opposed to adding support for pluggable languages to the DOM, because of the unavoidable overheads introduced by this. As far as I recall, no solution to the problem of cross-language GC, which is one of the biggest issues here, had been even really proposed at the time. Google continued on ahead, forking WebKit into Blink, introducing Dartium, and then ending the project. Now, with Dartium dead, it has become clear in retrospect that the WebKit community was right all along: you don't want multiple incompatible languages hooked up to the DOM.

NaCl may have been "open" in that Chromium was open source, but the dependency on Pepper meant that Google's implementation was Chrome-only. Google solicited feedback on Pepper back in 2010, but Apple and Mozilla engineers provided compelling arguments as to why Pepper was unnecessary. They ignored the feedback and did it anyway. Now, after seven years, NaCl is obsolete in favor of the multi-vendor Web Assembly, which uses the Web APIs instead of Pepper—exactly the approach that everyone else on the plugin-futures mailing list had advocated in the first place.

A lot of unnecessary work would have been avoided if NaCl and Dart had been more receptive to feedback.

Do you just mean they didn't want the dart vm in browsers? Or the language? If the latter as well, I respectfully disagree.

> Dart actively ignored outside feedback

Again, on the language or just having the vm in browsers?

There were plenty of issues in the Dart language, too. The way generics variance was deliberately unsound was bizarre, in particular, and they resisted attempts to fix it.