I would recommend Mozilla's localforage https://github.com/mozilla/localForage. Basil.js takes care of abstracting cookie, session, memory, and localstorage storage options, but localforage provides an abstraction for localStorage, WebSQL, or IndexedDB. With modern applications I find that I often want more storage available. Cookie storage is limited at 4Kb, localStorage (5Mb), sessionStorage (same as localStorage), IndexedDB (50Mb), and WebSQL (50Mb). Localforage will automatically select the best available storage system for the browser. While WebSQL and IndexedDB allow for advanced queries, localforage must cater to the lowest common denominator, localStorage key value pairs. While being restricted to key value pair storage, this is often not a big concern considering how different the WebSQL and IndexedDB APIs are.
Synchronous persistence APIs should be considered dangerous. Often they solve the immediate problem, but when you eventually need to move to an async storage solution (and in JavaScript any significantly complex task eventually becomes async) you are left with code that presumes sync behavior. This makes it difficult to refactor.
Providing an API with callbacks or better yet promises forces you to write future-safe code.
It might be a little bit "overkill" when you just want to perform storage only on client device no? (Basil aim is not to override backend storage like REST APIs)
That's a good point. The same issue seems to exist with almost every JavaScript function interface. Whether or not a function is synchronous or asynchronous seems to be an implementation detail (at least in theory), but that fact must be exposed in the function interface.
I think the main issue is actually with language design. Callbacks and promises are not decent ways to handle asynchronity in my opinion. Perhaps it could be abstracted away in the language itself in a way that the function interface would be identical for both "sync" and async functions..
Lol, I made a library a while back that does the same thing (https://github.com/rectangletangle/jSave). Maybe it's a sign that a larger project needs to be started?
It also ensure you that your usage of localstorage won't ever throw exceptions and break all your thread in the case of cookie-less anonymized sessions
There's a project with the same name out there: http://basiljs.ch/ This made me wonder: how to deal with similar named open source projects? Although the goals of both projects aren't related in any sense it could cause for some confusion...
Instead of getting an array from storage, pushing a new item inside and then storing it again, it could be nice to have directly this small mechaniam built in to avoid this logic in the application.
Hmm, that's true. The library could monkey patch .push (etc.), but it wouldn't support setting the property directly with [index] (until Object.observe is mainstream enough).
Love the name. (For those that don't get the joke, basil is an extremely persistent, almost weedlike plant.) That said, I think an async solution would be better, like localforage.
Great idea. The next progression would be cross browser benchmarks, and perhaps something suitable for browser extensions (unless this already works for that use case).
