[darklion]

While Chrome _does_ respect existing standards, sometimes to the point of pedantry, it also happily rolls out designed-for-our-needs web technologies and APIs into its majority-share browser immediately, only starting the standards process once it has the feature implemented. That means for months, or years, Chrome essentially has a proprietary set of extensions and APIs while its competitors are waiting for the standards process to work.

Does “having a proprietary, not-a-standard set of extensions and APIs that work only in that one browser” sound familiar? Chrome may not be dragging its feet on existing standards, but it’s so far out over the skis of where the standards are at.

THAT is what people mean when they say “Chrome is the new IE”.

[pcthrowaway]

In this case, it seems like it's something for which no standard yet exists that can also be polyfilled pretty easily, I see this as a good thing.

Chrome is free to release custom APIs that move the needle on eventual standardization. I only see this as a problem if they release something that can't be polyfilled.

[darklion]

So does that mean that if Firefox or Safari don’t implement something, but it exists in a polyfill, that Firefox or Safari should be treated as if it has been implemented natively?

Otherwise, what I’m reading is, “It’s OK for Chrome to put out whatever it wants because other browsers can rely on polyfills, but then we can turn around and ignore those same polyfills when it comes to evaluating what technologies Chrome supports vs. what technologies the other browsers support.”

In other words, Chrome gets promoted for going it alone, and the other browsers get dinged for waiting to implement something standard.

[pcthrowaway]

It means it's an experimental API introduced by Google. It may be deprecated (although standardized APIs can be deprecated as well).

If it can exist as a polyfill, that means you can use it in your app and polyfill it if needed, as well as continue to polyfill it in the event of deprecation. Your assessment of whether it's appropriate should be based on what the benefits are.

In the example of the WebSocketStream API, I suppose you compare it to the ergonomics of existing libraries doing the same thing, or the difficulty of implementing such a thing yourself. You might also consider the performance of the experimental API on Chrome, as well as the polyfill on other browsers, and if the worst-case performance is not too bad, or even better than the best-case performance of the competing ways to do something similar, you use it! In many situations, you can expect to find this on the path to standardization, but this only means you eventually may be able to remove the polyfill.

If you're developing for the web, I'd be very surprised if you, or at least your dependencies, haven't at any point used experimental APIs introduced in one or more browsers prior to standardization. In fact, if you use websockets much at all, it's very likely you've also used sub-protocols[1] developed by neither WHATWG, W3C or IETF (possibly abstracted from you by websocket server libraries, or else introduced by a websocket API you use)

[1]: https://www.iana.org/assignments/websocket/websocket.xml#ext...