Add support for Node.js

[piranna]

Allow to use localForage in Node.js environment.

[sole]

You mean running it in node.js, outside of the browser? Don't you have proper file access in node.js? Databases?

[piranna]

Yes, run it on Node.js. I know there are alternatives like file access and databases, but I'm interested that my library has the same ecosystem both on client and server side, that's why I'm looking for tools that work in both environments. LevelUP seems to be an alternative, but at the same time seems to be a little big for my needs, just a localStorage-like storage. Also, localForage seems more future-proof to me, since it would be possible to add its behaviour to the localStorage specification (I still doesn't understand by it doesn't support to store full objects...).

[tofumatt]

localForage is really a browser-aimed tool. It's about offline storage. I really don't node.js support fitting in, nor do I think its API is necessarily a great fit for actual file storage only. Are there not node.js APIs with lots of backend drivers already?

The problem here is we need to choose a backend, or backend drivers, like redis, MongoDB, etc. It's a big can of worms for a problem that doesn't really exist: you can use the same storage library on any node app with a redis server available. The problem localForage solves is that browsers don't all speak the same storage language, but now they can.

[piranna]

But Node.js and browsers still doesn't talk the same storage language, so I
still believe there's a problem here.

Send from my Samsung Galaxy Note II
El 14/02/2014 16:47, "Matthew Riley MacPherson" notifications@github.com
escribió:

Closed #57 #57.

Reply to this email directly or view it on GitHubhttps://github.com//issues/57
.

[lejenome]

as i know, webSQL and localStorage are availbale on nodejs but not really a good choose. even loading localforage will fail due the use of the undefined "window" object on localforage code and promise.js code

the problem with localforage is not so extensible. so adding more driver for platforms like chrome.storage #43 or nodejs or even browser-releated futures like session storage #2 will need to be directly integrated to localforage code base or to fork it

[tofumatt]

For the time being, I want this library to focus on the browser. When I feel like we have that problem solved with few issues and edge-cases I might look at node, but until then I don't see it as a priority at all.

Node.js and web browsers both use JavaScript, but that's where the similarities end. This is about client-side, offline storage. Not about storage in general.

[runvnc]

Well, you can actually run quite a bit of typical client-side libraries on Node these days. I think there are a number of types of projects that would benefit from a unified data layer and could then run with the same code on both the server and in browsers.

Its good that you are prioritizing the browser though, and I think that with so many different browsers to support and different engines, it is right to stay focused on that as the primary developer. However, I think it may be worthwhile for certain projects that have the rest of their code base set up to run both on the client and in Node, if they went ahead and forked the project and tried to see how difficult it is to build a Node back-end. Then maybe down the line somewhere, if that becomes popular and actually proves useful to a number of projects, without requiring significant changes to the core, it could be pulled in.

[tofumatt]

Yeah, obviously if someone wants to do all that exploration and heavy-lifting for us, then propose changes that don't affect the performance/size/etc. of the client-side library I would entertain it. But in terms of project scope: I'm ignoring node (which HAS good storage solutions) to focus on the browser (lacking in said solutions).