Module naming and declarations

Sam Tobin-Hochstadt samth at
Mon May 20 12:42:40 PDT 2013

On Mon, May 20, 2013 at 12:07 PM, Kevin Smith <zenparsing at> wrote:
>> The requirement I'm talking about -- which is absolutely critical for the
>> practicality and adoption of ES6 modules -- is that the system has to work
>> well out of the box without tools. And the current system does. The only
>> thing you have to change if you decide to repackage modules into scripts is
>> a *single* piece of code staged before application loading that configures
>> the locations of the modules. Note that this is how require.js works.
> Does it really work so well out-of-the-box, though?  Let's say that I want
> to develop an app which depends on some module M.  Let's say that in the
> module dependency graph reachable from M, there are 15 other modules.  So in
> order to get things working at all, I'll have to go out and find the source
> code for all 16 modules in this graph and place them (with the correct
> names) into my module base URL.

Or add a few <script> tags.

> It seems to me that when the module graph scales to a certain size, a
> package manager (and name registry) is going to be essential to this design.

Here, you're saying the design needs a package manager to work well at
scale, and calling it a flaw.

> On the other hand, I think it is possible with URLs to create a system which
> truly does work out-of-the-box.
> Let's imagine a world where publicly available modules are located at sites
> specifically designed for naming and serving JS modules.  Call it a web
> registry.  Intra-package dependencies are bundled together using lexical
> modules - the package is the smallest unit that can be referenced in such a
> registry.

Here, you're _assuming_ a "web registry" and claiming that it makes
your suggestion "work out-of-the-box".

> The registry operates using SPDY, with a fallback on HTTPS, so
> for modern browsers multiplexing is not a critical issue.

Here, you're confusing SPDY with "a magic technique that makes HTTP
requests free".


More information about the es-discuss mailing list