HN Explorer

Ask HN: How should browser API be dropped?

3 points by prohor ↗ HN
Recently we have been hit by Chrome dropping API, which is part of SVG 1.1 specification. The reason: low usage and it is not part of the SVG 2.0 draft: https://code.google.com/p/chromium/issues/detail?id=553672 . Fortunately we test against Canary and as part of the quoted bug, a polyfill was provided, so we can live with that. But I'm really surprised firstly that part of current standard is just dropped, secondly that there was not a single warning in Chrome console saying we use some depreciated API. So this bring to the question:

How should the browser API depreciation look like?

I would expect there is at least some messaging around that. That there is some known upfront date, when it will stop working, at lest few months in advance, so that applications can adjust.

What are your thoughts?

4 comments

[ 3.3 ms ] story [ 16.6 ms ] thread
davewiner
You have to factor in whether or not you want developers to use your APIs in the future. If you do, and they have to guess whether or not other developers will build on it, they might decide not to go for it.

So maybe you don't really want to do APIs at all??

Deprecate them before you start! :-)

I was just writing about this re Dropbox. People always say about the idea I want to see them do "That's a third party opportunity." Well, I would never bet on a mission-critical feature that depended on the continuing support of an API by a platform vendor. What happens to the users when the API breaks? I might not have a lot of users from their point of view, but from my point of view, my community will die if they break the API.

prohor
Well, I'm not sure if we talk about the same thing here. It is not my API, but API defined by W3C and implemented by Chrome browser. It was just dropped without any notice.
davewiner
Seems like the same question to me.

An API is an API. Google is part of the W3C, probably a very important part of it.

I used to be a W3C member, and remember how this worked. The big companies drove the process. They met privately and hashed things out between themselves. Then it was "debated" but somehow the decision that was arrived at was always the ones they wanted to make.

It's a way of making it look like an open process when it really isn't.

In any case, the problem for a developer is the same no matter who is doing the deprecating. You just built on something that's going away. You have some users. Not enough to matter to the big companies. You're burned. So now next time will you just go ahead and implement the API they want you to. Not unless you're an idiot! ;-)

Speaking as an idiot of this kind myself. I've been burned many times by this process.