Hacker News new | ask | show | jobs
by pcthrowaway 792 days ago
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.
1 comments
darklion 791 days ago
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.

link
pcthrowaway 791 days ago
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...

link