Real-world APIs

My friend Nicolas is defending localStorage in his blog, and I want to show my full support. In particular, this following sentence caught my eye and should make you curious:

[It] absolutely stinks of browser developers creating an API that’s easy to implement rather than creating an API that’s easy to consume. This is the opposite of how good APIs are made.

I simply couldn’t agree more. Browser vendors and the W3C tend do de-prioritize the most important feature of any API: Its usability.

In April 2011, I proposed a new CSS feature I called “hitmapping” in the form of extending the pointer-events property to support a new opacity threshold. Everybody I talked to – including browser vendors – agreed on its importance and usefulness. However, the thread soon turned into a discussion of how difficult implementation would be in WebKit, and the proposal was blocked. How can this possibly happen? As a web developer, I couldn’t care less whether something is going to be harder than something else to be implemented because of a browser’s architectural design decision!

What do we get instead? In my case, nothing. I have to perform black magic voodoo (image tracing and canvas manipulation) to achieve the same feature. In most cases though, we get alternative verbose APIs that are too complicated, too slow or too verbose. But hey! At least they’re easy to implement by browser vendors.

As a library developer, I’ve been going to hell so other web developers don’t have to. Vendors seem to have settled on the idea that web library developers will create abstractions around their new browser APIs, so developers can use them.

To the vendors and spec editors: This is not ok! It’s part of your main responsibility to create usable, real-world APIs. Library developers are doing your job because you don’t. I know many of you personally, and I know you are smart enough to fix this. Do it!

Thank you,

Reply with a tweet or leave a Webmention. Both will appear here.