I’m between contracts at the moment so taking the opportunity to play with some bleeding edge technology. With it seeming like everyone’s jumping on the HTML5 bandwagon, even microsoft with windows 8, seemed like a good opportunity to restart my side project playing with the latest web tech.
So there’s a few things to note if you pick up indexedDB.. It’s bleeding edge and to be expected but here’s my experiences over the last week.
IndexedDB is in webkit (chrome) and firefox but not yet in safari. The database visualisation in the webkit developer tools isn’t linked in yet so you can’t mange the database that way yet. You can’t delete a database programmatically yet in either chrome or firefox. If you’re writing unit tests this is going to be a bit of a pain ;). Also you can’t yet access the indexedDB from webworkers. At this stage it’s attached to the window. One of the things I’m playing with is a stemming and text sorting index which was all running via webworkers. It’s an easy workaround, you just take the results from the webworkers and at a convenient time, merge and store instead of doing it directly. Still, will be cool when this works.
The other thing I’ve noticed is that it feels very different than other data stores, even other kvp such as cassandra etc. It really is a javascript data store. The feeling I get is the asynchronous model is the preferred interaction method which again feels different that other API’s. I’m still getting the feel, but it feels right for client side javascript. In my opinion if I had to choose between the sqllite model and this, I’d choose this as a better technology direction for browser based client structured storage. Sqllite would have just recreated the sql feeling of datastores and I don’t think it would have felt quite right for javascript in the long term.
I’m sure these will be addressed pretty shortly, I’m running chrome alpha and dev channels, ffox 5 and will post back when I notice a change.
Daniel Harrison's Personal Blog 