modules proposal

Brendan Eich brendan at
Mon May 17 11:07:00 PDT 2010

On May 17, 2010, at 10:30 AM, Kam Kasravi wrote:

> Thanks Mike, David.
> I agree with the conclusion that regex probably isn't the best way  
> to tackle these problems.
> I'll summarize the use cases since it may apply in later  
> discussions...
> 1. Is it possible to import parts of a module to avoid potentially  
> large network payloads?

It's modules all the way down. You only import what you specify from  
the module, but that doesn't affect downloading or indeed express the  
module dependency -- the dependency comes from module declarations  
creating bindings first, before any import from the module via its  
bound name.

Network payloads are induced by URL requests that miss the HTTP-rules- 
based cache. MRLs are not URLs, however, so there's an opportunity  
here to coalesce load requests. See below.

> 2. Is there syntax that would allow the server to group or  
> concatenate delivery of multiple modules within one request?

This is a good question. The grouping of modules for download should  
be decoupled from how one declares modules, to avoid mixing concerns  
and requiring refactoring or rewriting just on account of repackaging.  
Module declarations allow ahead of runtime loading, but they don't  
help coalesce requests.

Coalescing requests (for some value of request) could be pushed down a  
layer, not specified as part of the ECMA-262 language. This serves the  
decoupling requirement. Is it enough? A while ago Allen wrote about  
separating "configuration management":

Part of this was about version selection, but part of it was about  
"assembly" structuring. It seems worth working through this, both with  
a real implementation of simple modules, and with some thought  


> thanks
> Kam
> From: David Herman <dherman at>
> To: Mike Shaver <mike.shaver at>
> Cc: Kam Kasravi <kamkasravi at>; Brendan Eich <brendan at 
> >; P T Withington <ptw at>; es-discuss Steen <es-discuss at 
> >
> Sent: Mon, May 17, 2010 8:22:52 AM
> Subject: Re: modules proposal
> > For this, I would rather let the exporter define named export lists,
> > so that there's better future proofing.  I would hate to be the  
> person
> > adding something to the SVG module knowing that there were a bunch  
> of
> > regexps floating around the web that might cause me to clobber
> > something unexpected.
> This gets to my main issue with regexps (aside from the YAGNI  
> aspect) -- it puts too much significance into variable names, and  
> becomes a refactoring hazard.
> > ("*Filter*" isn't even a legal regexp, so they'd get a compilation
> > error, but when you have to write SVG..*Filter.*, I think it gets to
> > be pretty unwieldy.)
> FWIW, you could distinguish this with the regexp syntax, for example:
>     import SVG./.*Filter.*/;
>     import /.*Filter.*/ from SVG;
> But ... um, well, yeah.
> Dave

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list