The 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.
> 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.
JS 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.
