Module naming and declarations

David Herman dherman at mozilla.com
Tue Apr 30 15:01:39 PDT 2013


On Apr 29, 2013, at 6:34 AM, Andreas Rossberg <rossberg at google.com> wrote:

> ...you are generally assuming the use of some package manager. This
> is a fairly significant assumption, that I wished I had heard being
> made explicit in any of the previous discussions. AFAICT, it is key,
> and without it, your proposal cannot fly. Not in a world with tens of
> thousands of module releases, anyway.

Not only is this wrong -- it'll be just fine to use ES6 without package managers -- but your proposal does not make any material difference in the relative dependence on package managers.

> In other words, package managers are great, and the module system
> should definitely support them. But it should not, de facto, _require_
> them -- especially not on the web.

I believe package managers will become a common part of the JS development experience. This is true for almost every modern programming environment, from Ruby to Scala to Node. I also think multiple package managers will exist, and that's fine too. There's nothing centralized about this that makes it inappropriate for the web. In fact, it's the nature of decentralization to leave the space open.

Finally, plenty of people will continue to use the system without centralization. For many packages, particularly popular ones, people will choose globally unique names like "backbone" and no reasonable software package will step on their toes.

As an analogy, consider the Unix file system. You can build software and deploy it without using a package manager at all, and everyone knows not to take the name "vi" (except actual vi implementations). But almost everyone uses a package manager in practice, there are multiple package managers, and they don't require any new semantics from the file system.

> More specifically, everything should still play nice with standard web
> mechanisms. For me, the web platform implies that I should be able to
> address modules as remote resources (it's a choice _not_ to use that
> mechanism). That requires that the system allows proper URLs as module
> identifiers.

Fully agreed, and if it wasn't clear, the current system does completely support this. You can use a URL as a module name. In the default browser loader, you can choose to import a module from an explicit URL:

    import { $ } from "http://my.cdn.com/jquery/1.9";

and it will use that URL both as the logical name and as the place to go and fetch the bits. If you don't use an absolute URL, it treats it as a path, which defaults to loading as a source file from a relative URL derived from the module name.

> And at that point, you absolutely want your logical names
> to integrate nicely into the URL name space semantics, which
> currently, they do not do at all. (The proposal calls module ids
> "URLs", and syntactically, they form a sublanguage. But semantically,
> this sublanguage is divorced and interpreted in a completely
> incompatible way.)

Maybe there's some confusion caused by misleading or out-of-date wording on the wiki here. I apologize if that's what's happened -- I'll have the wiki updated and clarified before the May meeting.

The sublanguages are fully compatible. In fact, note that they're only two sublanguages for the *browser loader*. In the browser loader, if you use an http:// URL, it will fetch the module from the web. But the core semantics simply treats module names as uninterpreted strings.

> That brings me to your repeated assertion that URLs are not
> appropriate for logical names, because they are, well, logical, not
> physical.

No, that's not the argument. The argument is that *URI's* are not appropriate (I wasn't using the right terminology either!), because they don't work well in practice.

> Of course, I should have said URI, and as usual, that's what
> I really meant. :)  URIs generally _are_ logical names for resources.
> Arguably, the inherent abstraction from logical to physical (or
> virtual) is one main reason for their existence. So, from my
> perspective, URIs are _exactly_ the appropriate tool.

This idea is attractive enough that it comes up a lot, but it just doesn't ever seem to work out in practice.

History is not on your side here. The W3C has moved away from using URI's as unique names or namespaces:

    http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#changes-drafts

URI-based DTD declarations and XML namespaces failed and have been replaced with simple identifiers. The modern DTD for HTML5 is <!doctype html>. The modern way to embed data in HTML tags is with data-<id> attributes where the <id> is any user-chosen identifier:

    http://www.w3.org/html/wg/drafts/html/master/dom.html#embedding-custom-non-visible-data-with-the-data-*-attributes

You've been arguing we should use time-tested, well-understood, and successful  mechanisms. The problem is, URI's as logical names, while time-tested and well-understood, are a failure.

> That does not mean that logical names have to become unreadable or
> awful to type. Just that they are slightly more explicit. A schema
> prefix -- say, jsp: for a random strawman -- is good enough and should
> not offend anybody in terms of verbosity. (If it did, then I'd have
> little hope for the evolution of the web platform. :) )

First, let's be clear: this is literally an argument over the surface syntax of public module names, nothing more. You're arguing for the universal  addition of a few characters of boilerplate to all registered module names. That's just bad ergonomics for no gain. Not only that, it hurts interoperability with existing JavaScript module systems.

There's a reason why the existing systems favor lightweight name systems. They're nicely designed to make the common case syntactically lighter-weight. And they absolutely can co-exist with naming modules directly with URL's.

Dave



More information about the es-discuss mailing list