[vanderZwan]

Since I assume both have their pros and cons, when would I want to use Store.js, and when would I want to use localForage[0]? I'm asking as someone who has offline storage planned for an app, but has yet to get around to it. I'd like to know which one is probably best for my needs :)

[0] https://github.com/localForage/localForage

[marcuswestin]

Totally! I created an issue to pull this info together: https://github.com/marcuswestin/store.js/issues/189

Check back in coming days for more details.

Store.js will soon have pluggable support for localForage (either by implementing similar functionality in separate storages, or by simply adding a pluggable storage which uses localForage under the hood).

There are a few benefits to using store.js, such as full cross-browser support and useful plugins, but the biggest meaningful value-add over localForage is probably the availability of a synchronous API that allows you to read and write values without callbacks, promises, etc.

In my experience you only want to use asynchronous APIs when you have to, since they add a fair amount of complexity, are a common source of errors, and are harder to debug properly.

But yeah, check back later and you'll likely find that store.js supports the same storages as localForage, in addition to the its other functionality.

[vanderZwan]

Thanks, I'll keep an eye on that issue. I still have other more pressing milestones to reach anyway ;)

[couchand]

Sounds like (based on other comments) you should really just be using localForage. Store.js only currently supports a sychronous interface, which will be incompatible with modern web APIs.

[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!

[hackerboos]

Personally, I wouldn't use a library at all unless I had to support IE<8. Localstorage is supported enough across browsers:

http://caniuse.com/#feat=namevalue-storage

[marcuswestin]

I think something like store.js ends up being genuinely useful for anyone building functionality that depends on localStorage. More often than not you find yourself either having to deal with issues that store.js solves for you (E.g not breaking your site in Safari private mode) or requiring extra functionality that already exists as a small store.js plugin. (E.g expiring keys, default values, etc). All of these are things you can of course do without a library, but at that point you're reinventing the wheel a bit and not benefitting from all the automated testing that ensures cross-browser correctness. With that said, I agree there are times when just a quick read/write directly to localStorage can be the right call, but by default I think it comes back to bite you one way or another more often than not :)

[vanderZwan]

Well, I need more than 5 MB and would like to store other values than strings (mostly large TypedArrays). Something simplifying my life there would be appreciated.

[hackerboos]

JSON.stringify/JSON.parse before getting/setting from localstorage.

The other requirements localstorage alone can't address.

[couchand]

It's worth noting that vanderZwan was asking about localForage, the library by Mozilla, not localStorage, the browser feature.

[hackerboos]

I'm aware of that. I'm saying if that your use case is simply to write to localstorage then a wrapper library is unnecessary.