[mixonic]

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.

[vivab0rg]

This. I recently moved to localForage[1] and have been mostly satisfied so far. Thanks Mozilla!

[1]: http://mozilla.github.io/localForage/

[cobalt2760]

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)

[nawitus]

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..

[ef4]

I came here to say the exact same thing.

Even if you're using synchronous storage, wrap it in an asynchronous API and save yourself a world of hurt later.