I suspect a lot comes down to how localStorage is capped. I now understand that the reason it's capped is because it's to prevent you from slugging around too much stuff in RAM. So, I'd welcome a nice cap that be easy to business-logic around. Would be nice if the browser vendor could help tell web developers what's too much and too dangerous for the greater benefit of the browser experience.
Yeah, my only real concern with localStorage these days is excess use of it because of that memory cost and the potential for the read costs to add up to a real problem. On non-SSD storage, if you had multiple megabytes of data in there, especially sharded over a high number of keys, given our SQLite page size (32k everywhere but b2g), you could get into a large number of disk seeks.
I do believe that localStorage hits a sweet spot for helping get a populated first render to the user. Anything above the fold, really. For the Firefox OS email app we use localStorage to cache the HTML of the page (more details at http://www.visophyte.org/blog/2015/04/30/talk-script-firefox-os-email-performance-strategies/), which is something that we can hopefully replace with the new cache API at some point. And in a desktop-related effort, I use it for persisting splitter positions too (https://clicky.visophyte.org/files/screenshots/20150830-222533.png).
But once you get to anything that you'd call a database where there's a growth factor expected, I think it's preferable to move to using something IndexedDB-backed. Although obviously, there are always engineering trade-offs to be made. For a tool used by a limited user-base used on desktop where they probably have oodles of RAM, it's not a big deal. The bigger risk when working on Mozilla affiliated projects is the hazard where people replicate your implementation choices without doing a trade-off analysis of their own. (If localStorage is good enough for Mozilla, etc. ;)
Comment
I suspect a lot comes down to how localStorage is capped. I now understand that the reason it's capped is because it's to prevent you from slugging around too much stuff in RAM. So, I'd welcome a nice cap that be easy to business-logic around. Would be nice if the browser vendor could help tell web developers what's too much and too dangerous for the greater benefit of the browser experience.
Parent comment
Yeah, my only real concern with localStorage these days is excess use of it because of that memory cost and the potential for the read costs to add up to a real problem. On non-SSD storage, if you had multiple megabytes of data in there, especially sharded over a high number of keys, given our SQLite page size (32k everywhere but b2g), you could get into a large number of disk seeks. I do believe that localStorage hits a sweet spot for helping get a populated first render to the user. Anything above the fold, really. For the Firefox OS email app we use localStorage to cache the HTML of the page (more details at http://www.visophyte.org/blog/2015/04/30/talk-script-firefox-os-email-performance-strategies/), which is something that we can hopefully replace with the new cache API at some point. And in a desktop-related effort, I use it for persisting splitter positions too (https://clicky.visophyte.org/files/screenshots/20150830-222533.png). But once you get to anything that you'd call a database where there's a growth factor expected, I think it's preferable to move to using something IndexedDB-backed. Although obviously, there are always engineering trade-offs to be made. For a tool used by a limited user-base used on desktop where they probably have oodles of RAM, it's not a big deal. The bigger risk when working on Mozilla affiliated projects is the hazard where people replicate your implementation choices without doing a trade-off analysis of their own. (If localStorage is good enough for Mozilla, etc. ;)