We need to kill off the localStorage API
paul.kinlan.me
paul.kinlan.me
One example of this is CSS. CSS is leaps and bounds better than, for example, GTK's layout and styling system. It is a huge improvement over spacer images and tables. However, it is far (far, very far) from perfect. Having umpteen different ways to position elements, inconsistent layout/display models, inconsistent implementations, no nesting and even lack of arguable features like constants (why can't I define color main_color = #cc0000; and use that everywhere, so I don't violate DRY principle?). It is important to recognize both the benefits and flaws of all technology we use.
Now, it sounds like a lot of the OT's gripe has to do with inconsistent implementations, which are always a huge pain when it comes to web development. However, as some comments suggest, it's at least possible that the spec itself is not broken. Issues like "it's slow" or "it's too small" seem like implementation details. That's like saying "JavaScript is slow" before/after Chrome came around. Right tool for the right job, etc.
The actual inconsistency of the API's is not the issue, it is that the usage of the API and what it is being pushed as.
localStorage is A solution for offline and client-side storage, its fitness depends on the application's needs.
localStorage wasnt build as a replacement for your dataStore, its just a convenient place to put some of your data, things like preferences, keep ui state across pages etc, its a perfect replacement for cookies without the HTTP overhead, turning it into a more sane localJSON api is like 10 lines of code.
I do agree that we should be making sure we move to more robust solutions that were designed for large amounts of data and queries etc when there is a requirement for them, but that doesnt mean localstorage is bad or evil
Or for a big global object (to reload on each arrival/page)
Exactly. localStorage is not a database, hence not having "database" in its name as opposed to "Indexed Database" or "Web SQL Database". It's a persistent key/value store, aka a big hashmap/dictionary which survives restarts.
If you need a database, it's not the right tool for the job, and if you want to store tens of megabytes of shit in the browser it's not the right tool for the job either.
If you need to store a bunch of site-wide configuration items or to cache some basic information, it's quite good enough, and at the same time safer, easier to use and providing far more storage space than cookies (which are the actual alternative).
The big issue is that we do not have a stable cross-browser client-side database interface (some browsers implement IndexedDB, others implement WebSQL), so people try to jump the gun and coerce localStorage into a DB role... which unsurprisingly breaks.
The complaints about WebSQL being tied to a a specific library remind me of the "Linux shall really be GNU OS with a kernel and user-installed non-OSS stuff, and we're happy that non-techies will have to compile their own multimedia tools" or "Thunderbird will always put -- as a sig separator, b/c that's the way it has always been" arguments.
Perhaps if we make the standard we want, and let implementation rest in the hands of implementors, then we can get the KV store AND a SQL store, since they solve different problems in different ways.
This does remind me of the recently posted Marco Arment post, http://www.marco.org/2012/02/25/right-vs-pragmatic, of doing what your users want instead of what you want in some cases. Some devs really liked what WebSQL offered, or could use a good KV store... but due to purist principles, we are stuck with where we are.
err, say what?
Google uses it for all offline apps (Gmail, Docs, Calendar).
Amazon uses it for the Kindle HTML5 app.
The best thing to do is to use WebSQL. That way, Mozilla will be forced to implement it or become less useful than other browsers.
It's the only way. IndexedDB is a clusterf*ck. Poor performance, hand-rolled joins, etc, etc.
That said, we also need a client-side storage mechanism that supports queries, so I'm all for pushing toward IndexDB (or bringing back WebSQL).
The synchronousness means the whole DOM will block; blocking anything else would be an implementation bug, however that is not what Taras's post describes.
Blocking the DOM is bad. JS is designed as an evented language (the insight that led to node.js), which means it can't accept primitives that stall its main loop; breaking that assumption would add a lot of complexity to code that never uses localStorage.
It was? How do you explain alert and confirm, two of the first uses of JS? I don't think we need to add religion to JS. Node.js is evented because that works best for it. In my JavaScript thread if I want to wait for the localstorage get, so be it. This is isolated to my thread, breaking nothing.
However my point was that the claim of the scope of the problem are overblown. If a given implementation loads one massive store for localStorage, that's a problem with the implementation, not localStorage. The linked article worst cases on the back of a bad, lazy implementation decision.
It all depends on the app, but we seem to be using localStorage for all our storage and bolting complex querying on to it etc and this is a huge recipe for disaster.
It's pretty primitive, you have to go into the DOM tab for `window` and scroll down to `localStorage`.
Same for `globalStorage`.
for( var i = localStorage.length - 1; i >= 0; --i ){
var key = localStorage.key(i);
console.log( key + ": " + localStorage.getItem(key) );
} localStorage.key(Math.random()*localStorage.length)Which in Javascript always means a hefty rewrite, since there's no way to abstract out async vs sync.
It makes me long for call-with-current-continuation.
1. Embedding of LevelDB or Kyoto. BitCask is terrific but has too slow a startup time for large data sets.
2. No range support.
3. No IndexedDB-style gargantuan-spec and setVersion versioning complexity. No versioning at all.
4. Just humble powerful KV.
5. Node-style callbacks.
6. Get/set/unset.
7. UTF8 keys.
8. ArrayBuffer byte-array values only - developers can layer any slow serialization/deserialization abstraction else on top.
9. Unlimited storage quota when requested by the app.
10. An option for the user to see how much storage the app is using so they can uninstall if it uses too much for their liking.
11. Fast.
12. True MVCC auto-completing read/write transactions (readers block writers in most IDB implementations, not MVCC) or cross-tab in-memory lock api.
After that we need an async BTree api.
Similarly for the WebSQL apologists, there's no reason <50kb of JavaScript couldn't provide a fully featured SQL engine on top of IndexedDB - IndexedDB implements most of the hard work (indexes, transactions, the container itself) already.
Could you point me to such a simple JavaScript library? When IndexedDB was anointed that was the argument -- that the benefits of WebSQL could simply be layered atop. So where is it?
No. To use your terminolgy, IndexedDB is like jQuery on top of LevelDB. We need just LevelDB without the IndexedDB overhead. Surprisingly, there are things you can do with LevelDB that you can't do with IndexedDB. It's too high a level of abstraction.
IDB in Chrome may have LevelDB somewhere underneath but it lacks points 9,10,11,12. As far as I know it does not yet have true MVCC, no real concurrency for multiple readers and writers. Single-transaction-at-a-time. Readers block readers.
Why can't we have simple API AND second, async API with bells and whistles for people who need that?
It would have been nicer to have an async mode for localStorage, but even then I don't think it covers it. I really worry that developers are starting to try and build serious apps on it and it just won't work..
Question: what happens if your gamestate gets over 5Mb?
I hope it won't, because I only save stuff that changes. I can compress biggest data, if it becomes a problem, to get more space, but I don't think I'll have to.
Anyway - it's not a problem of API, but of constraints of browser implementations. There's nothing preventing browsers from implementing configuration option that allows users to assign available space in localStorage to domains.