<div class="gmail_quote">On 5 July 2012 11:19, Patrik Stutz <span dir="ltr"><<a href="mailto:patrik.stutz@gmail.com" target="_blank">patrik.stutz@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 color="#000000"><font><font face="verdana,sans-serif">Oh I didn't know that Isaac is also unhappy with the whole javascript module thing. I tought that, since there already so much modules for node.js it is pointless to ask them to change their module system, so that node modules also could be used in the browser, so I asked you to give me a JavaScript feature than allows me to implement node's module system in the browser.</font></font></font><div>
<font face="verdana, sans-serif"></font></div></blockquote><div><br>I'll bet that there at least 1,000 times more web pages out there that depend on JavaScript's run-to-completion semantics than there are node.js modules.<br>
 <br>As for "using Node modules in the browser", provided Node uses CommonJS Modules/1.0 modules (I believe it does), then you might want to look at the draft of a non-standard specification called CommonJS Modules/2.0-draft8 at http:/<cite><a href="http://www.page.ca//~wes/CommonJS/modules-2.0-draft8">www.page.ca//~wes/CommonJS/modules-2.0-draft8</a></cite>. To summarize:<br>
 - Works fine on browser<br> - Works fine on server<br> - Does not alter <i>any</i> semantics of valid /1.1.1 modules<br> - Requires a trivial two-line change for each module (and one of those lines is closing brace, close paren, semicolon).<br>
<br>I have implemented most of this spec in BravoJS and it has also been implemented in at least one other project, NobleJS.  I have implemented it on the server on top of GPSEE's /1.1.1 module system, with a trivial patch to module.constructor.  And I have built two major systems on top of BravoJS + GPSEE using Modules/2.0 modules shared between the browser and the server.<br>
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>BUT: interestingly, the import keyword also seems to be synchronous. So, I think behind the scenes there still would have to be something like a "delay" function to make it non-blocking. Or am I missing something?</div>
</blockquote><div><br>import is no more synchronous than var.  What you are missing is that ES modules do not do demand-based (lazy) loading, like CommonJS <b>can</b> on the server (the spec does not require it, modulo maybe require.paths).  All the dependencies in ES modules are statically resolved before any code runs.<br>
<br>Where ES modules differ from current browser-platform module systems derived from CommonJS is that there seems to be no facility to lazy-load modules.  Modules/2.0-draft, AMD (require.js), etc, all have some kind of eager module loading, although Modules/2.0 delays initialization to preserve the Modules/1.1.1 execution semantics. <br>
<br>Everybody CommonJS-derived on the client seems to have lazy module loading, too -- but the interesting observation from my POV is that is that lazy module loading on the client seems rather unused. I know I have never used it, and neither has anybody on my team. Has anybody here?<br>
<br>Wes<br><br></div></div>-- <br>Wesley W. Garland<br>Director, Product Development<br>PageMail, Inc.<br>+1 613 542 2787 x 102<br>