W3C home > Mailing lists > Public > www-tag@w3.org > February 2013

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

From: Graham Klyne <GK@ninebynine.org>
Date: Fri, 15 Feb 2013 12:16:42 +0000
Message-ID: <511E272A.3070108@ninebynine.org>
To: Jeni Tennison <jeni@jenitennison.com>
CC: "www-tag@w3.org List" <www-tag@w3.org>



On 15/02/2013 09:32, Jeni Tennison wrote:
>
> On 13 Feb 2013, at 12:06, Marcos Caceres <w3c@marcosc.com> wrote:
>> On Wednesday, 13 February 2013 at 11:39, Miko Nieminen wrote:
>>> I think IndexedDB is almost good enough for writing all kinds of abstractions and reusable libraries on top of it.
>>
>> Sure, but this still means having to download a whole bunch of stuff to be able to use IndexedDB. It means all users have to now pay a tax (and i mean literally pay money on phones plus waste time) because they need to download your library in addition to the code the developer needs to write to make their software work. It's the same problem as with JQuery: it should't need to exist and such a massive amount of the Web should not need to *rely on it*. That's a failing on the part of standardisation to create APIs that developers can actually use, IMO.
>>
>> What I'm saying is that it should be *a choice* to use a JS library - because it does something really cool or really does take the pain out of development. But, to me, it's a failing that an API be designed to be so unusable by the developer community that it must rely on others to build stuff to make it actually usable.
>>
>> IMO, it's *not ok* to force people to download a JS library to make a native browser APIs usable. It's great that you, and others have gone to the effort to make the IndexedDB API usable to average developers (and I'm truly thankful that you've gone to the trouble): hopefully these usable APIs can be taken back to the Web Apps Working Group and an API Web Developer friendly version of the API can be standardised.
>
> I think that it's this feedback loop which is key.
>
> We should aim for a pattern of evolving and improving standard APIs over time. I think it's understandable that the initial pass at an API for a new technology is likely to be less usable than one which is built based on experience of using that technology (and the pain points of the existing API).
>
> It would be great to have a brief description of best practices for designing these kinds of APIs from scratch, but I think it would also be good to incorporate some best practices around evolving the APIs, both through incremental changes and through introducing radically different approaches (as jQuery is to DOM).
>
> It's also perhaps worth looking at recommended practices for both browsers and web developers when using common JS libraries (eg use the CDN'd version from a common location, and cache it for a long time), because from experience we can see that the evolutionary cycle will involve a period of time when these libraries are necessary.
>
> Cheers,
>
> Jeni
>

I haven't followed this thread in detail, and first noticed it a few days ago.

I have my doubts that a standards organization, however good, is capable of 
creating a really good API ... it's the kind of activity that I think really 
benefits from the focused attention of a small team of really good developers. 
Old adages about horses, committees and camels come to mind.

Clearly there are areas where some common API really is needed to achieve 
interoperability between applications and platforms, it seems to me that as a 
standards organization, W3C might try:
(a)  to focus on those areas that really needed to underpin interoperability, and
(b) where an API is needed, to try and adopt an existing well-crafted, well-used 
implementation and focus on promoting that with minimal change.

Just my 2c.

#g
--
Received on Friday, 15 February 2013 13:08:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 15 February 2013 13:08:58 GMT