13 ms·
We need to kill off the localStorage API
- mmackh 15y agoI can't say that I agree. For certain use cases, the localStorage API is great. For example, I have built an online Text Editor (http://wrrrite.com http://wrrrite.com) and I don't see any real alternatives to storing the text locally.
- kinlan 15y agoNice app but I quickly got to a point where the UI became unresponsive and digging into the CPU profiler it was all in storeValue and setItem, granted some of it can also be the issue of reading the data from the DOM, but I the point stands, localStorage's synchronous API causes issues. 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.
- lukifer 15y agoThe spec isn't broken; the browser implementations are broken. Even then, it's incredibly useful as is (although I haven't run into the locking issues described). 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).
- obtu 15y agoThe problem with the localStorage API is that it blocks on IO: https://blog.mozilla.com/tglek/2012/02/22/psa-dom-local-storage-considered-harmful/ https://blog.mozilla.com/tglek/2012/02/22/psa-dom-local-stor...
- huggyface 15y agoThe problems listed in the linked page have little to nothing to do with localstorage, but rather are implementation problems. Localstorage is scoped, so if an implementation is blocked on irrelevant meebo data, the implementer needs to fault themselves.
- obtu 15y ago> Webpage completely freezes for a few seconds while the browser populates Local Storage key/value store. 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.
- huggyface 15y agoJS is designed as an evented language (the insight that led to node.js) 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.
- gregory80 15y agoDont forget document.write, or the blocking behavior of script tags themselves.
- tagawa 15y agoKill it off? I don't think so. Avoid using it if it's not the right tool for the job? Certainly. As a simple cross-browser key-value storage mechanism it beats cookies hands down in my experience, but obviously doesn't compare to database-style alternatives.
- masklinn 15y ago> Kill it off? I don't think so. Avoid using it if it's not the right tool for the job? Certainly. As a simple cross-browser key-value storage mechanism it beats cookies hands down in my experience 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.
- jorangreef 15y agoWe need an async KV store: 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.
- MatthewPhillips 15y agoIndexedDB doesn't have the setVersion stuff any more. New spec is much simpler just hasn't been fully implemented by any one yet.
- khuey 15y agoFirefox 11 has an essentially complete implementation of the IDB spec and it ships in two weeks. 10 definitely has the replacement for setVersion, but I don't remember what else missed 10.
- MatthewPhillips 15y agoFirefox has the most complete, there are certainly bugs though. For example I've had a lot of problems with multiEntry.
- khuey 15y agoCan you file bugs, or email me testcases at <my username>@mozilla.com? We definitely want to get this stuff right :-)
- forgotusername 15y ago
- ajuc 15y agoThis API is as simple, as it gets, and it's working OK for me (saving/loading game state), and I think for many other purposes also. Why can't we have simple API AND second, async API with bells and whistles for people who need that?
- kinlan 15y agoThe async api with bells and whistles is supposed to be indexedDB. 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?
- ajuc 15y ago> 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.
- newman314 15y agoI would like to see more tools to see what is stored inside localStorage. Right now, afaik, there is not easy way to inspect.
- kinlan 15y agoChrome DevTools and Safari (and I am sure FF) have had tools for a long time to see inside localStorage. It is inspection tools for IndexedDB we haven't got.
- kinlan 15y agoActually according to http://peter.sh/2012/02/scoped-styles-deflated-websockets-and-the-vibration-api/ http://peter.sh/2012/02/scoped-styles-deflated-websockets-an... we now have IndexedDB inspection in the latest Chromium (behind a flag).
- masklinn 15y ago> and I am sure FF It's pretty primitive, you have to go into the DOM tab for `window` and scroll down to `localStorage`. Same for `globalStorage`.
- wslh 15y agoIt is a sqlite database (in Google Chrome and Firefox), so with the sqlite console you can access the database.
- mike-cardwell 15y agofor( var i = localStorage.length - 1; i >= 0; --i ){ var key = localStorage.key(i); console.log( key + ": " + localStorage.getItem(key) ); }
- pixelcort 15y agoTip: To get a random localStorage key: localStorage.key(Math.random()*localStorage.length)
- IgorPartola 15y agoWhenever someone says "We need technology X to go forward. It is our only choice." I see it as a warning. Is there really no other way forward, even if localStorage is broken? Maybe IndexDB is awesome (I have no idea), but perhaps it's not the holy grail. 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.
- kinlan 15y agoIndexedDB is far from awesome unfortunately, but is our only viable solution at the moment. My point in the post is that we need someway to educate developers that localStorage is not the solution for offline and clientside storage (which it is being pushed as). 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.
- masklinn 15y ago> localStorage is not the solution for offline and clientside storage (which it is being pushed as). localStorage is A solution for offline and client-side storage, its fitness depends on the application's needs.
- daleharvey 15y agoExactly 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
- mwexler 15y agoI too miss WebSQL. Every time I have to spend time changing my code to simulate what would be a simple SQL join, I wonder if we didn't adhere a bit too much to dogma. 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 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.
- Groxx 15y agoI really never understood the WebSQL single-implementation problem. It doesn't have to be - SQLite is public domain. Fork it. Maybe even change it so it fits a bit more smoothly with JS. But instead we invent something new, with new optimization problems, new usage annoyances, new inconsistencies between browsers...?
- unwiredben 15y agoYeah, plus there's already a "single implementation" thing with HTML5, since most of the browsers have moved to use a common parser based off Java code (in some cases, translated automatically to C++).
- batista 15y agosince most of the browsers have moved to use a common parser based off Java code err, say what?
- foobarbazetc 15y agoNo one has abandoned WebSQL except Mozilla. 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.
- peregrine 15y agoIf anyone stopped and looked at his 'simple' IndexDB version of the backbone local storage you will see the issue right there. There is nothing simple about that...
- kinlan 15y agoGranted IndexedDB is not simple, and that pains me, but the migration was very simple with the library (that was the point).
- pavel_lishin 15y agoWhich library?
- csears 15y agohttps://github.com/superfeedr/indexeddb-backbonejs-adapter https://github.com/superfeedr/indexeddb-backbonejs-adapter
- ef4 15y agoOne unfortunate thing about localStorage is that if you start using it, and then decide to move instead to IndexDB (or WebSQL, or the Filesystem API), you need to jump the chasm from synchronous to asynchronous. 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.
- untog 15y agoIt's not Javascript proper, but take a look at tame.js. Would make switching between sync and async very easy. Also, IcedCoffeeScript for the CS-ers.
- dannyc 15y agoRegardless of whether localstorage is the right tool I think people felt/feel no choice but to advocate it based on one all-important issue (saving grace?) "Browser Support". It would be nice to educate people and explain to them, don't try to use localstorage for any serious stuff, no querying, slow performance, etc. But what would you answer when they ask what's an alternative that I can use today? Based on http://caniuse.com/indexeddb http://caniuse.com/indexeddb it's not looking too good. I would suggest we continue to advocate its use, and at the same time add in a "but.. in the really near future" you should be switching. Is it great, no; But good enough for many use cases- I think so.
- jdefr89 15y agolocalStorage ins't for heavy tasks? It is not meant to replace databases, it is more for a robust capable cookie system.. So your argument doesn't make much sense
- kinlan 15y agoyes it does, it is being pushed as the cross platform datastorage solution.
- gregory80 15y agoWho is pushing this cross platform datastorage solution you speak of?
- jorangreef 15y agoIn discussion at Public Web Apps, someone from Mozilla suggested LocalStorage as a suitable alternative to those who preferred WebSQL over IndexedDB.
- rsanchez1 15y agoFigures it had to be someone at Mozilla. If I prefer WebSQL, I'll use WebSQL.
- rsanchez1 15y agoI think the author is comparing apples and oranges. If you need large-scale data storage, then go with WebSQL or IndexedDB. If you just want to store data you normally used cookies to store, then use localStorage. This approach hasn't done me wrong yet.