<div class="gmail_quote">On 16 January 2012 14:20, Andrea Giammarchi <span dir="ltr"><<a href="mailto:andrea.giammarchi@gmail.com">andrea.giammarchi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<font face="'courier new', monospace">var module = require("module");</font><div><br></div><div>is totally fine but </div><div><br></div><div><font face="'courier new', monospace">require("module", function (module) {</font></div>

<div><font face="'courier new', monospace">  // is totally fine too</font></div><div><font face="'courier new', monospace">});</font></div><div><br></div><div>
latter could be synchronous in node.js and asynchronous in the web, who cares, as long as it scales for all scenarios ... don't you agree?</div></blockquote><div><br>One fundamental difference between how AMD modules and CommonJS modules (presumably Node) load is that CommonJS modules have lazy initialization, whereas AMD modules have eager initialization.<br>
<br>This is probably where some of the Node<>AMD "impedance mismatch" is coming from -- in CommonJS with Modules/1.0 on the server side, developers expect to be able to perform certain types of initialization when the module is loaded, and they do not expect to need to pre-declare their modules.<br>
<br>It will be interesting to see how the addition of ES.Next modules plays out with the server-side JS communities.<br><br>Wes</div></div><br>-- <br>Wesley W. Garland<br>Director, Product Development<br>PageMail, Inc.<br>
+1 613 542 2787 x 102<br>