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”.
I used to work for an object-oriented database company, and since then I’ve tried several object and XML databases on various projects. And yet we’ve always come back to a relational database as the underlying data store, with a more or less generic layer on top to handle the mapping of application objects. The formal underpinnings of relational databases are hard to beat from a performance perspective, so they are unlikely to be dethroned any time soon. Any JavaScript storage API for web applications (standard or “1000 flowers bloom”) should be layered on top of a standardized SQL interface.
Have you pondered about how that data will move between your server and your browser store? If not, I encourage you to read a complementary proposal about offline data access that does nothing to provide special JS APIs to slice and dice your data, but ensures that you have it when you need it.
http://o-micron.blogspot.com/2009_04_01_archive.html (It’s my blog)
Personally, I would wish we could standardize the primitives for data synchronization and leave it to library developers to figure out the best JS APIs for accessing the data for different kinds of applications. I also don’t like SQL as the model for accessing data, although some JS API may wish to internally use the SQLite API a particular browser provides.
Object-oriented or relational — this is a permanent question.
A question worth billions of dollars and zillions of sleepless hours 🙂
Can there be a middle way?
Perhaps, an “object-relational” way?