Fwd: "delay" keyword

Wes Garland wes at page.ca
Thu Jul 5 08:42:43 PDT 2012

On 5 July 2012 11:19, Patrik Stutz <patrik.stutz at gmail.com> wrote:

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

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

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:/www.page.ca//~wes/CommonJS/modules-2.0-draft8. To summarize:
 - Works fine on browser
 - Works fine on server
 - Does not alter *any* semantics of valid /1.1.1 modules
 - Requires a trivial two-line change for each module (and one of those
lines is closing brace, close paren, semicolon).

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.

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?

import is no more synchronous than var.  What you are missing is that ES
modules do not do demand-based (lazy) loading, like CommonJS *can* 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.

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.

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?


Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120705/a7041f58/attachment.html>

More information about the es-discuss mailing list