Recently, we have seen good discussion on the W3C Web Storage specification. There has been some recent push back on the use SQL, in particular “SQL as SQLite defines it”, in the specification. Counter proposals have been popping up using JavaScript-ish APIs, many using JSON. Some of the APIs store the data as a JSON document or blob, even using the HTML5 localStorage/globalStorage system to persist the data. BrowserCouch and TaffyDB are two nice examples. Both are very JavaScript-oriented, client-side and offer some very nice functionality.
I think the functionality of a good JavaScript storage API will always be the most productive approach to storage, in much the same way we see JavaScript DOM libraries used everywhere. At the same time, I don’t think we should standardize functionality that should be in a JavaScript library, just as jQuery, dojo, YUI or any other DOM library is not the HTML DOM standard. I like having the flexibility of using different libraries.
We already have document-style (blob) storage in a specification and we have JavaScript libraries to make using document storage easy and convenient. The question I see is whether we want relational (tables/records) style storage. Many new JavaScript libraries would blossom from such a storage system and developers would have more choice.
Document and relational storage each has it’s own pros & cons. I’d like to see more discussion about the pros & cons, about performance and about what parts of the storage mechanism browser vendors should be focusing on to make JavaScript storage libraries performant. I’d like to see less bikeshedding on JavaScript storage APIs. I’d really love to see less talk of putting features in a specification that should be in a JavaScript library.
Update: Chris Blizzard’s post discussing Google’s O3D & Mozilla’s Canvas3D is great comparison of high-level vs. low-level APIs. Just replace “3D Canvas” with “Web Storage”.