Module naming and declarations

James Burke jrburke at gmail.com
Mon May 20 13:24:37 PDT 2013


On Mon, May 20, 2013 at 12:07 PM, Kevin Smith <zenparsing at gmail.com> wrote:
> 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.  The registry operates using SPDY, with a fallback on HTTPS, so
> for modern browsers multiplexing is not a critical issue.  In such a world,

There are lots of problems with this kind of URL-based IDs with a web
registry, which I will not enumerate because they basically boil down
to the problems with using URLs: URLs, particularly when version
information gets involved, is too restrictive. The IDs need to have
some fuzziness to make library code *sharing* easier. I have given
some real world examples previously.

That fuzziness needs to be resolved, but it should be done once, at
dependency install time, not for every run of the module code.
"Dependency install time" can just mean, "create a file at this
location", does not mandate tools.

At this point, I would like to see "only URLs as default IDs" tabled
unless someone actually builds a system that used them and that system
got some level of adoption.

If it was a great idea and it solved problems better than other
solutions, I would expect it to get good adoption. However all the
data points so far, ones from other languages, and ones from systems
implemented in JS, indicate the URL choice is not desirable.

Note that this problem domain is different from something that needs
new language capabilities, like the design around mutable slots for
"import". This is just basic code referencing and code layout. It does
not require any new magic from the language, it is something that
could be built in code now.

Side note: existing HTML script tag use of URLs is not a demonstration
of the success of URLs for a module system since they are decoupled
from the references of code in JavaScript, and requires the developer
to manually code the dependency graph without much help from the
actual code.

Another side note: if someone wanted to use a web registry for library
dependencies, it could just set the baseURL to the web registry
location and have one config call to set the location for app-local
code. It would end up with less string and config overhead than "only
URLs as IDs". There has even been a prototype done to this extent:
http://jspm.io/ -- it is backed by the module ID approach used for AMD
modules/requirejs.

But again, these are all side notes. The weight of implementations,
and real world use cases, indicate "only URLs as default IDs" are not
the way to go.

James


More information about the es-discuss mailing list