Module naming and declarations

Kevin Smith zenparsing at
Wed May 8 13:41:59 PDT 2013

> You're saying we have no choice but to make users hard-code locations into
> every import site, because HTML. I disagree.

That is not my position.  My position has always been that if you want
"logical names", then a reasonable way to do that is via a scheme:

    import $ from "package:jquery";

There are others (e.g. a syntax-based solution like Brendan mentioned), but
the important thing is that we don't overload the semantics that are
already in place for URIs.

What you've proposed is to have package loaders:
> * invent new URL schemes for URLs that aren't actually locators; and/or
> * treat URLs as names, XML-namespaces-style; and/or
> * take module names that are URLs and process them contrary to URL
> semantics.
I don't think that your list adequately represents my position.  Let me try
to restate.

I've proposed that module loaders have the freedom to specify whatever
semantics they choose for *URIs* that appear in module specifiers, even if
those semantics are questionable.  For consistency, the *default loader*
should not choose semantics that conflict with standard URLs.

And please do not represent my position by using the term "XML".  Thanks  :

> The lack of a fast, reliable filesystem makes some things (like CLASSPATH)
> less attractive, and other things (preloading, on-demand server-side
> concatenation, client-side caching, CDNs, etc.) more attractive. Internet
> access makes new things possible. I think the options that package loaders
> will want to explore for JS, vs. other languages, are more diverse, not
> less.
I agree with you 100%, of course. That is why, personally, I would rather
us provide the ingredients for experimentation than try to bake something
in : )

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

More information about the es-discuss mailing list