Node.js support

[willbamford]

I've started using https://github.com/stackgl/headless-gl so it would be great if I could use this with Node.js too. There are two hurdles as far as I can tell:

1. No XMLHttpRequest support.
2. text and binary loaders will work fine, but currently loading image / video / audio data requires DOM support.

Can fairly easily tackle 1. by using a XMLHttpRequest polyfill for Node.js. Alternatively could move to using something like Superagent which works across environments (although understand that this might be undesirable as it would add ~5kb to gzipped code weight). Did look at using fetch API with ponyfill / polyfill for Node.js (e.g. https://github.com/qubyte/fetch-ponyfill / https://github.com/matthew-andrews/isomorphic-fetch) but currently this doesn't support progress events so seemed undesirable.

Support for image loader could be achieved by (conditionally for Node.js) using native Node.js image decoders for png, jpeg and gif etc. Not sure about video and audio but I guess in theory the same applies.

I made a fork to look into this (and also add some unit tests) but wanted to float the idea before I went ahead and tried this out. If done properly adding Node.js support wouldn't change the behaviour of, or add any weight to, the browser code. What are your thoughts on this @mikolalysenko?

[mikolalysenko]

I'd love to see this and be more than happy to accept a PR. Before getting too far along though, the one thing I would like to see is the implementation keep the number of dependencies minimized. Ideally we could have separate browser/node interfaces and specify them using the browser field in the package.json.

[willbamford]

have separate browser/node interfaces and specify them using the browser field in the package.json

Yes, was thinking along the same lines. My fallback for if you didn't like the idea of universal resl was creating different repos alongside resl such as node-resl and then universal-resl which simply pointed to correct module based on browser field (although things could get out of sync / end up copy pasting bits of code that would otherwise be more easily shared when in same repo).

[willbamford]

Hey @mikolalysenko, I forked resl a few weeks ago with the intention of doing the above, but found it to be not as straightforward as I would have liked - I felt like I was retrofitting functionality for which resl was not initially designed. I also wanted tests and there were a few other features I wanted so decided to implement a very similar library which doesn't share code but is heavily inspired by resl in terms of the API interface (for which I owe you a lot of credit). The additional features are Node.js support (using superagent for HTTP and lwip for image decoding for JPG/PNG/GIF); optional support for promises; the ability to set a src as and arrayor object as well as string (useful for things like cube maps where resources are related); and the ability to nest the resource tree. It's called getres and can be found here.

resl also has features not supported in getres i.e. support for video / audio, more sophisticated progress events. I was wondering if there was the opportunity to sync the two going forward?