866982 - A standards-track asynchronous localStorage

Status: NEW

(Core :: Storage: localStorage & sessionStorage, enhancement, P5)

Description

[Potch [:potch]]

Browser vendors hate localStorage because it's synchronous and love IndexedDB because it's asynchronous. Developers love localStorage because it's simple, and hate IndexedDB because it's complex. Let's mix chocolate and peanut butter together, and bake something like https://github.com/mozilla-b2g/gaia/blob/master/shared/js/async_storage.js into the DOM. Naturally, we'll bring this work to the standards bodies. Devs shouldn't have to put that JS into every page, but it works as a great polyfill.

Before:

var f = localStorage.getItem('foo');
...

After:
asyncStorage.getItem('foo', function(f, error) {

});

Comment 1

[tofumatt [:tofumatt]]

It should be noted that *my* favourite feature of localStorage is that it's cross-platform, so this would matter a lot to me. "Just use IndexedDB" isn't a solution for me when many of my users are on iOS.

This sort of API would get tonnes of developers to use performant storage without the mind-boggling experience of using IndexedDB (and would hopefully be cross-platform too).

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

The new API wouldn't be more cross-platform than IndexedDB. New APIs need to be implemented everywhere, and I expect that IDB will be implemented in iOS.

But anyhow, I agree IDB API is too complicated for simple cases.

Comment 3

[Jan Varga [:janv]]

This is something we plan to implement in relatively near future.
https://wiki.mozilla.org/WebAPI/Storage2013

Comment 4

[Mounir Lamouri (:mounir)]

I strongly disagree with the idea that we should have a new standardized API for this. We should instead pushing libraries on top of whatever is available. Pushing a new API will increase the number of API the UA has to support for no reason, thus increasing the security risks and will also require us to wait a few years before the API is standardized and implemented. If we can do some JS that makes that possible, I do not see why not just do it.

FWIW, I've been working on such a library on and off this a few weeks:
http://github.com/mounirlamouri/storage.js

Comment 5

[Potch [:potch]]

(In reply to Mounir Lamouri (:mounir) from comment #4)
> I strongly disagree with the idea that we should have a new standardized API
> for this. We should instead pushing libraries on top of whatever is
> available. Pushing a new API will increase the number of API the UA has to
> support for no reason, thus increasing the security risks and will also
> require us to wait a few years before the API is standardized and
> implemented. If we can do some JS that makes that possible, I do not see why
> not just do it.
> 
> FWIW, I've been working on such a library on and off this a few weeks:
> http://github.com/mounirlamouri/storage.js

I will gladly allow you to remove IDB in exchange ;)

The problem with "just use a library" is now you're asking every developer to put another script in their page instead of using localStorage (which is simple, exists, and works everywhere). The fact that it takes lead time ordering on years for such an API to become mature is why we should start on it today!

Additionally, your storage.js library either uses IDB or falls back to the localStorage that everyone's hating on in the first place, punishing existing platforms that don't support IDB (iOS mainly?). For mobile app developers, iOS is not an ignorable platform.

Comment 6

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

(In reply to Potch [:potch] from comment #5)
> Additionally, your storage.js library either uses IDB or falls back to the
> localStorage that everyone's hating on in the first place, punishing
> existing platforms that don't support IDB (iOS mainly?). For mobile app
> developers, iOS is not an ignorable platform.

What do you propose we do about iOS here?

Comment 7

[Potch [:potch]]

(In reply to Kyle Huey [:khuey] ([e-mail]) from comment #6)
> (In reply to Potch [:potch] from comment #5)
> > Additionally, your storage.js library either uses IDB or falls back to the
> > localStorage that everyone's hating on in the first place, punishing
> > existing platforms that don't support IDB (iOS mainly?). For mobile app
> > developers, iOS is not an ignorable platform.
> 
> What do you propose we do about iOS here?

A Web SQL-based solution would probably work- they offer asynchronous transactions.

Comment 8

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Ah, ok.  Can we put "build a JS based polyfill" in a separate bug from "design and natively implement an async key value store in Gecko"?

Comment 9

[Potch [:potch]]

(In reply to Kyle Huey [:khuey] ([e-mail]) from comment #8)
> Ah, ok.  Can we put "build a JS based polyfill" in a separate bug from
> "design and natively implement an async key value store in Gecko"?

Certainly- sorry for the derail!

Comment 10

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

FWIW, I think the way forward here is to create a JS-library that sits on top of localStorage and IDB, and ideally WebSQL.

Once we have such a library we should reach out to developers and get feedback on it. At some point in the future, once there's general consensus that the library is exposing the right API, we can implement it natively.

But I don't want to build "yet another storage API" that turns out to be targetting the wrong use cases.

Comment 11

[Mounir Lamouri (:mounir)]

(In reply to Jonas Sicking (:sicking) from comment #10)
> Once we have such a library we should reach out to developers and get
> feedback on it. At some point in the future, once there's general consensus
> that the library is exposing the right API, we can implement it natively.

What would be the benefit from a native API versus a JS library?

Comment 12

[Potch [:potch]]

(In reply to Mounir Lamouri (:mounir) from comment #11)
> (In reply to Jonas Sicking (:sicking) from comment #10)
> > Once we have such a library we should reach out to developers and get
> > feedback on it. At some point in the future, once there's general consensus
> > that the library is exposing the right API, we can implement it natively.
> 
> What would be the benefit from a native API versus a JS library?

Not requiring every developer who wants the feature to bundle the code into their assets requiring additional bytes on the wire and an acknowledgement that the API is first-class, instead of a de-facto standard.

Comment 13

[Mounir Lamouri (:mounir)]

(In reply to Potch [:potch] from comment #12)
> Not requiring every developer who wants the feature to bundle the code into
> their assets requiring additional bytes on the wire and an acknowledgement
> that the API is first-class, instead of a de-facto standard.

How old is IndexedDB? Around 4 years. How many users have this feature enabled on their browsers? around 50%. On Mobile? not even 1%. If we push a new API today, what are the chances that it will get a higher adoption?

IndexedDB has been designed with the idea that libraries will be created on top of it to create a simple API surface and keep a complex one for developers with complex use cases. The first thing we should do is to apply that plan and then see how things go.

Regarding the data on the wire, a library exposing simple get(), set() methods on top of IndexedDB would be very tiny. I wouldn't call this a harm for the wire. We should try to save bandwidth where it is wasted, not when it is needed for the sake of the ecosystem.

Which moves me to my last point: a lively ecosystem goes with libraries. Isn't one of the forces of NodeJS that you have libraries for a ton of stuff? This is something that works well for the Web too: people have been using Promises for a long time without asking the browser to implement them. We are finally adding this to the platform because we want APIs exposed by the browser to return Promises but otherwise, developers were using an implementation or another easily. I wouldn't call this "de-facto standard" versus "first-class API". Those libraries are no standard and they do not need to be an API of any sort. Any user can switch from one to the other easily.

I will skip all the issues related to throwing APIs like crazy in the Web Platform like security, ease for a new competitor to join, supporting them for ever, etc...

Comment 14

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.