Comment by telemachos | Hacker News Reader

Comment by telemachos | Hacker News Reader

Parent Full thread

Yes, it's in this interview:

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.

There's this huge misconception that because "require" synchronously returns the module object it must use synchronous IO to load the modules as well, which is not true. The root module and it's transitive dependencies can be loaded asynchronously before any execution of the code (and thus require calls) takes place.

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.

> 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.

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.

This may go some ways to solving the issue (mostly with asynchronous module loading) - https://github.com/joyent/node/commit/9967c369c9272335bb0343...

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.

Ah that makes sense. (As I say, I remember that he said elsewhere he wasn't thrilled about requires being synchronous.)

Reply on news.ycombinator.com