Yeah, also, SQL is not a particularly great way to manage remote client-side data because instead of having to deal with just one version of your data schema, you potentially have quite a few different versions out in the wild. That means you have to figure which version of the schema you’re dealing with and carefully migrate to the version of the schema your system actually expects. And you potentially need to run this check every time the page is loaded. Schema-less data stores make so much more sense for local storage in the browser.
If your data structures have changed significantly, you still need to migrate the persisted data, which is typically more tedious and error-prone in schema-less storage because the storage backend provides no tools for it.
Not to dispute that schema-less storage makes more sense for client-side storage – it does. But that’s because it embodies a different set of trade-offs than schema-based storage. It simplifies the most common scenarios (primarily the addition of columns). It does not, however, magically remove the need for migration or cure its painfulness.
Complexity in the problem space is like a waterbed, if you push it away in one place it pops up in another.
Being a Mozilla employee, I’m biased, but for what it’s worth: Those two particular things are a part of Mozilla’s effort to ensure the HTML5 spec and the implementation of it doesn’t screw up the web.