
Ask HN: How should browser API be dropped? - prohor
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:&#x2F;&#x2F;code.google.com&#x2F;p&#x2F;chromium&#x2F;issues&#x2F;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&#x27;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:<p>How should the browser API depreciation look like?<p>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.<p>What are your thoughts?
======
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.

------
prohor
Just to add sugar to it - check the list of usage statistics and scroll down,
to see how many APIs is endangered by distinction:

[https://www.chromestatus.com/metrics/feature/popularity](https://www.chromestatus.com/metrics/feature/popularity)

