Module naming and declarations

Jason Orendorff jason.orendorff at
Wed May 8 13:53:19 PDT 2013

On Tue, May 7, 2013 at 7:01 PM, Anne van Kesteren <annevk at> wrote:

> On Tue, May 7, 2013 at 4:39 PM, Jason Orendorff
> <jason.orendorff at> wrote:
> > Set aside absolute-url imports. Suppose we just dropped them. Would you
> > still think that module names are URLs? If so, do you think about other
> > languages in the same way?
> I think it's weird to try to equate JavaScript with those languages.

Not weirder than trying to equate it to HTML and CSS, surely!

They operate on multiple platforms that do not share a universal
> addressing system and therefore a layer of abstraction had to be
> invented to make it easier to work those languages across multiple
> platforms.

I don't think that's the reason those systems have abstract names for
packages/modules. All of these systems were designed for use on systems
with hierarchical filesystems supporting absolute and relative paths. Any
one of them could all have chosen to implement `import` by mapping the
package/module name directly to a filename in a dead-simple, one-to-one
way; but none did.

(Even C, a language designed 40+ years ago by people whose key technical
virtue was their willingness to eliminate unnecessary abstractions, lets
you configure #include paths at compile time.)

Are the different environments where people will deploy JS code really
*more* uniform than where people deploy Java? I don't know. But surely not
so much so that third-party packages should just go ahead and embed the
locations of their dependencies.

I guess that's another point I had not really thought of, the web
> platform will get a way to execute some script at "fetch", which is
> basically a low-level version of the module loader.

Yeah, these two efforts should meet and talk before long. Related ideas
going around, for sure.

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

More information about the es-discuss mailing list