Module naming and declarations
samth at ccs.neu.edu
Tue May 7 11:48:38 PDT 2013
On Tue, May 7, 2013 at 2:35 PM, Anne van Kesteren <annevk at annevk.nl> wrote:
> On Tue, May 7, 2013 at 11:18 AM, Jason Orendorff
> <jason.orendorff at gmail.com> wrote:
>> If module names were URLs, that would definitely be the right thing.
>> Module names aren't URLs, though. These aren't static links to static
>> locations (for reasons discussed in this thread; e.g., it'd be
>> counterproductive for backbone.js to have a static URL for underscore
>> embedded in it).
> But you are treating them as URLs by default (with a small dose of magic).
No. This is not what's happening at all.
Modules are given logical names, such a "backbone" or "jquery/ui".
Module loaders map logical names to URLs and then map the URLs to
The default behavior of the initial module loader for the browser is
to convert a logical name to a URL in a certain way, and then to fetch
that URL with http in the usual way to get JS source.
The way we think that conversion should happen is to use the loader
baseURL, which defaults to the document base URL, as a prefix, and
".js" as a suffix. Certainly we could choose other prefixes instead,
but it doesn't sound like you think there's a clear better choice.
We could also choose a different suffix, or no suffix, but it would be
odd to force everyone to remove the extensions on their files.
>>> The associated document could work, but that means you'd always be
>>> required to use links such as /path/to/script as otherwise the link
>>> breaks if the script that does the importing is included from both
>>> /doc1 and /example/doc2.
>> You pointed out this issue earlier, and I replied (on Monday, May 6; search
>> for "sweet spot"). What do you think?
> I think that because of this you cannot really use the default loader
> semantics in most scenarios. Lots of sites reuse a script on several
> pages (i.e. documents) with disparate URLs, similar to how they reuse
In that case, such a script probably won't use relative module names
which are expected to be fetched by the default mapping I describe
above. That doesn't mean they need an new loader, though. It would
be just as easy to use another script tag, another module in the same
script tag, or a use of System.ondemand().
 In fact, "URL" is here just an arbitrary string, but usually it
will be a URL.
More information about the es-discuss