3 ms·

Yes, it's in this interview: http://bostinnovation.com/2011/01/31/node-js-interview-4-questions-with-creator-ryan-dahl/ http://bostinnovation.com/2011/01/31/no

Yes, it's in this interview: http://bostinnovation.com/2011/01/31/node-js-interview-4-questions-with-creator-ryan-dahl/ 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.

maccman 15y ago
This may go some ways to solving the issue (mostly with asynchronous module loading) - https://github.com/joyent/node/commit/9967c369c9272335bb0343558673b689725c6d7c 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.
- telemachos 15y ago
  Ah that makes sense. (As I say, I remember that he said elsewhere he wasn't thrilled about requires being synchronous.)
tlrobinson 15y ago
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.
- substack 15y ago
  > 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.
- deleted 15y ago
  [deleted]

maccman 15y ago

This may go some ways to solving the issue (mostly with asynchronous module loading) - https://github.com/joyent/node/commit/9967c369c9272335bb0343558673b689725c6d7c 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.

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

tlrobinson 15y ago

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.

substack 15y ago
> 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.
deleted 15y ago
[deleted]