[marcuswestin]

On the other hand, synchronous interfaces tend to be less error prone and simpler to work with (and more enjoyable...? :)

There is an active issue to add the async indexdb/websql storages to Store.js (https://github.com/marcuswestin/store.js/issues/181) so that they can be used when needed (e.g when you need to store many tends of MGs of data), but for 90% of your use cases the simplicity of the synchronous store.js API may likely save you a meaningful amount of code and callback/Promise/stack trace debuggery :)

[couchand]

If you're writing buggy async code I'd say the storage library is far from your biggest concern. I'm all about human factors and making devs lives easier and all that, but async is a core skill for a web dev.

[marcuswestin]

Store.js is here to make life easier for all web devs, beginners and pros :) I've concluded that adding an async API in addition to the sync one for access to the more powerful storages makes total sense though! Off the top of my head I'm leaning towards new methods for the async versions, and then probably adding localForage as a new storage.

Thanks for taking the time to make the case!