Module naming and declarations

Sam Tobin-Hochstadt samth at ccs.neu.edu
Mon Apr 29 09:09:58 PDT 2013


[Responding to these two emails together]

On Mon, Apr 29, 2013 at 6:40 AM, Kevin Smith <zenparsing at gmail.com> wrote:
>
>>
>> The URLs you're proposing here just *are* logical names, and they
>> aren't in most cases being dereferenced to produce resources, which is
>> the core point of URLs on the web. They're just inconvenient logical
>> names.
>
> No.  In my hypothetical scenario they are simply URLs which when
> dereferenced produce the required source code.  They are "canonical", in a
> sense, and can be remapped to other URLs, but they are URLs, nonetheless.

To make this concrete, what you suggest is that any code that depends
on jQuery will need to write:

    import $ from "http://code.jquery.com/jquery-1.9.1.js";

Because that's the canonical URL for the current version of jQuery.
Then, anyone who wants a version of jQuery that is not that version
will have to set up a URL rewriting scheme, probably as part of a
loader. Of course, absolutely everyone will want to use a different
version of the code than this; it's not even minified, let alone
served on a CDN, or over HTTPS, or on a local site, or any of the
other concerns people will have in production.  Even worse, this bakes
in a particular version.  If I want to upgrade to 1.9.2 when it comes
out, what do I do?

Further, you can't load a module that defines jQuery with a script tag
-- how would that define the same module that the URL above specifies?

> You have not demonstrated that a URL-based semantics would not work.  Only
> that "Sam doesn't like it".

I've spent a lot of time in the discussion spelling out precisely the
technical problems with the URL-only approach.  I assume you can tell
the difference between that and "Sam doesn't like it".

> But I thought that was one of the original
> design goals of the module loaders API:  to allow users to apply whatever
> arbitrary URL resolution semantics they like.

It is a goal of the module loaders API to allow users to configure,
restrict, redirect, etc the URL retrieval behavior.  This is important
for caching, bulk loading, security restrictions, etc.  It is _not_ a
goal to force every user to use the module loaders API just to host
some libraries locally.

On Mon, Apr 29, 2013 at 6:44 AM, Kevin Smith <zenparsing at gmail.com> wrote:
> I understand this design now.

This does not appear to be the case.

> At scale, it depends upon an implicit,
> centralized naming authority to manage naming conflicts.  The namespacing
> scheme of this authority will necessarily be flat because it will be seeded
> with names like "jquery" and "ember".

This is false. We do not assume any naming authority, and have never
said that we did. Similarly, neither the AMD module namespace nor the
JS global object have a "naming authority" to manage conflicts.

How did you get the impression that this was required?

In another domain, there's no "global authority" to manage the file
system on, say, linux systems, although there are multiple package
managers.

I assume that package managers for the browser will appear; in fact,
some already exist. That doesn't mean there will be a central
authority.

> Who's authority will this be?  Google's?  Mozilla's?  Apple's?  Twitter's?
> Node's?  Who will be responsible for maintaining it?  What will the
> conflict-resolution strategy be?  Will names be immortal?  Will there be any
> standard conventions?  Will it support versioning?

Again, no one will be required to use any package manager.  Google
*already* ships a tool that manages a namespace (the Closure
compiler), but no one has to use it to use the global object.

> All of these questions will be left unspecified (because ES6 will surely not
> specify them), and as with all unspecified needs, a path-dependent and quite
> possibly sub-optimal solution will emerge.  Javascript, to some degree, will
> be bound to this autonomous naming authority, like it or not.

If JS develops package systems, then I'm assuming that they'll
competitive, and that people will work hard to develop good ones.
Certainly systems like NPM are excellent, and we should not assume
that the JS community will do worse on the web.  But JS will not be
bound by it.

> I think some accounting would be helpful here.
>
> As far as I can tell, the proposed resolution semantics would take about 10
> lines of code to write using a module loader API.  Let's be generous and say
> that it really comes out to 20 lines.

What "resolution" semantics are you talking about? I can't think of
anything in the semantics that answers to this description.

> - We are drawn inescapably toward an unspecified central naming authority
> whose policies we cannot foresee or control.

An actual argument for this, rather than repeated assertion, would be useful.

> - We break a central tenet of the web (1):  that external resources are
> represented by URLs.
> - We break a central tenet of the web (2):  that naming authority is
> decentralized using DNS.

This is no more true of the module system than that the HTML `id`
attribute violates this principle.

> On the bright side, we have an excellent design that we can return to:  Sam
> and Dave's pre-November lexical modules.

As I explained in some detail in my response to Andreas, this design
has a significant flaw, which we fixed, leading to the current design.

Sam


More information about the es-discuss mailing list