Re: IndexedDB, what were the issues? How do we stop it from happening again?

On 07/02/2013 15:47 , Marcos Caceres wrote:
> Ever since IndexedDB was released in browsers, there has been a lot
> of criticism about the API from the developer community: mainly
> people saying "it sucks", but not clearly articulating *why* it
> sucks. For example:

I think that there are several things that are problematic here, and it 
might be worth teasing them apart to address them specifically.

First, a lot of us are (I think increasingly) operating under the more 
or less tacit assumption that when we try to produce high-level APIs, 
they tend to suck for various reasons, and therefore that we should 
produce lower-level primitives atop which people can build nicer things 
(which we might then standardise in subsequent iterations). IndexedDB 
certainly was created with that in mind, and we're seeing the exact same 
sort of feedback in WebCrypto which has chosen the same approach.

That doesn't lead to the conclusion that it's the wrong approach though. 
For instance, AppCache went the other way — producing a high-level 
interface to a complex space — and the result is appalling to use. It's 
the first piece of tech I've known to ever be called a "douchebag". I do 
therefore believe that the low-level-first approach does retain its 
value. But clearly people aren't happy so some aspects ought to change.

In the feedback that we're getting, we should separate genuine design 
problems from people being disappointed that they're given a low-level 
API when they just want something simple that gets the job done.

For the latter bit, I reckon it would be a good practice for groups 
working on low-level APIs to more or less systematically produce a 
library that operates at a higher level. This would not only help 
developers in that they could pick that up instead of the lower-level 
stuff, but more importantly (at least in terms of goals) it would serve 
to validate that the lower-level design is indeed appropriate for 
librarification.

To take an example, while we were tossing ideas around for a lower-level 
approach to the AppCache problem, one important consideration was that 
the current solution could be implemented (more or less) in terms of the 
new: https://gist.github.com/darobin/4739167.

For the bad design bit, well, we've been missing a manual on how to 
write good APIs for a long time. There's content that we can steal for 
that. Part of it needs to be about writing actually good APIs, and for 
that we can turn to Rodney's article for a starting point:

 
http://coding.smashingmagazine.com/2012/10/09/designing-javascript-apis-usability/

Part of it also needs to be about how to apply WebIDL correctly, which 
is something that editors regularly get wrong (leading to weird problems 
down the line). A while back Jungkee and I had started writing things 
down in this area. It's nowhere near complete and it needs some serious 
work, but it can be grabbed and used by whoever would like to work on this:

     http://darobin.github.com/api-design-cookbook/

It probably wouldn't hurt if we had a group that was tasked specifically 
with reviewing APIs. How to build that without it being bureaucratic, 
useless, excessively political, and how to find people with the 
bandwidth to make it work is a difficult question though. Which doesn't 
mean that we shouldn't try — it simply means that we shouldn't jump into 
it with unreasonably promises.

We're also missing a few basic blocks like futures (or whatever else 
people prefer) that could bring some consistency to the platform. These 
tend never to get worked on because people just want to produce the 
actual API, and no one gets to work on the "niceties". That's something 
we need to address as well.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Monday, 11 February 2013 11:34:18 UTC