Didn't Ryan Dahl say he wish he used something else for packaging Node modules?
(I don't know what he had in mind other than CommonJS and I don't remember where I heard it so this is pretty hazy...)
(I don't know what he had in mind other than CommonJS and I don't remember where I heard it so this is pretty hazy...)
http://bostinnovation.com/2011/01/31/node-js-interview-4-que...
BostInno: Is there anything you wish you had done differently with node?
Dahl: Yes – many things. For example, I wish I had not used the CommonJS module system. It’s far too complex and wildly different from how the browser works.
In another interview (which I can't find), I recall him worrying a bit that CommonJS is not async, though admitting that a few lapses in async purity might be fine. In any case, I'm not aware that Node actually has any plans to move away from CommonJS. At this point, a whole hell of a lot of code relies on that style of require. Perhaps it could be swapped out in some backward compatible way, but it seems like a lot of work. (Also from the point of view of someone who just uses CommonJS style rather than implements it in something like Node, I have to say, it's dead easy and intuitive. Why fix what isn't broken?)
Wow, wtf? I got voted down for finding someone a reference? I'm not making an anti- (or pro-) CommonJS argument here. I just found the reference.
Like you say, I don't see any issues with the current system (and don't like wrapping everything manually in define function). You'll always need to get a server involved at some point for concatenation and performance reasons - and I think the current system works fine.
To do that the dependency module IDs must be extracted from the module text via static analysis, but that's fairly easy since module IDs are specified to be string literals. A simple regex is usually good enough, but using one of the many JavaScript parsers is safer. For cases where the module ID needs to be computed or loaded based on a runtime decision, an asynchronous form of require should be used.
The expectation is ECMAScripts modules will map pretty cleanly to CommonJS modules, but with real syntax rather than function calls. In the meantime CommonJS modules are a pretty good compromise I think. Simple implementations can do the loading using synchronous IO as "require" is called, while more advanced loaders (especially for browsers) can implement a slightly more complicated system to do the loading up front before excution.
I did exactly this for browserify, yet another node-based browser-side require() bundling system. Another benefit of this approach is that you can use modules made for node just by require()ing them in your browser-side javascript, so long as your static analysis bundling is recursive and the modules can be `require.resolve()`'d by node.