AMD, refined CommonJS support

[natevw]

http://requirejs.org/docs/whyamd.html, some sample patterns here: https://github.com/umdjs/umd

[natevw]

Also stumbled across a reminder that WebWorkers is another potential platform with its own unique "environment": http://groups.google.com/group/kanso/msg/7bf0d5548254b333

[ghost]

I have been using fermata in a kanso App within a WebWorker context with a lot of success but I am new to deep JavaScript coding and so I have have hacked around some issues that I had integrating fermata into this environment.

I'll list the issues I had here and the hacks I have used, hopefully someone with more JS experience can take a more elegant approach.

1. module managers

I can't comment on the competing viewpoints regarding sync/async module loading, all I can say is that I have had good success with AMD (requireJS) and using it to load modules in WebWorkers. I selected RequireJS as it explicitly supports the WebWorker runtime context.

I wrapped fermata with a 'define(function(require, exports, module) {' and that almost worked, I had an issue with the _nodeTransport function, as it tests for 'if (require('url').parse("h' even though I am not running in Node, so I commented this function out, it might be that if a proper solution is found to the Node/WebWorker issue below that this would not be an issue ans the check would not be called.

2. WebWorker runtime context

Most JS libraries right now that support browser and node.js runtime contexts. There is a third context that is growing in popularity WebWorkers'. In most cases the libs can run in a WebWorker without too many changes but the biggest issue I had to overcome was to determine if the script is running in a WebWorker rather than Node.js

Every lib I have seen tests for 'if (typeof window === 'undefined') {' and if window is not defined then the assumption is that we are running in node.js, but the return value for window is also undefined if we are running in a WebWorker.

WebWorkers have XHR support but I don't think WebWorkers can support all the node.js modules out of the box so running them in Node.js configuration usually does not work without making changes. Looking around there does not seem to be a way to determine what the JS runtime context is, the best advice I could find was to check for every dependent feature that is required and adjust the library depending on the result. So checking for the window object definition is good practice, but if a lib wants to support WebWorkers as well then all Node.js dependencies will also have to be checked for and not assumed, or all required modules used in node.js will also need to run in a WebWorker.

I hope this feedback is useful

[natevw]

Awesome, thanks! Definitely need to get a little more sophisticated about detecting the right environment.

[natevw]

On AMD specifically, see http://tomdale.net/2012/01/amd-is-not-the-answer/ for some counterpoint.