Module naming and declarations

Anne van Kesteren annevk at annevk.nl
Tue May 7 10:53:02 PDT 2013


On Tue, May 7, 2013 at 10:18 AM, Jason Orendorff
<jason.orendorff at gmail.com> wrote:
> OK, check my work here: For resolve hooks, there's no entry script. The
> loader calls the resolve hook asynchronously, from an empty stack. Or, empty
> except for the loader implementation. Since we're talking about the
> browser's default resolve hook, that's not a script either. No user code is
> executing.
>
> Tentatively I still think what XHR does is right for loaders. Each Loader,
> like a Worker or DOM node, should have its own base URL and use it
> consistently. It seems unhelpful for a cross-document call elsewhere on the
> stack to affect System.load(), causing modules to be loaded from the wrong
> place. Note that loaded modules are cached, so the oddness would persist.

My point was that you'd want neither the entry script's URL or the
document's base URL, but rather the URL of the script resource itself.
Since these are static links similar to <img src> in an HTML document
or url() in a CSS resource, I thought you'd want them to work the same
way.

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.


> I dunno, Anne. I'm sure I'm not the first n00b to say this, but caring about
> what code is at the bottom of the stack is creepy already. The "entry
> script's base URL" convention seems bad, even if we could follow it.

I don't have insight as to why browsers have this model. I'm pretty
sure we cannot change it though. (As you probably know, the script
execution model defined by HTML was in existence for a long time
before that. Browsers simply reverse engineered it from each other.
Now it's defined, but as with the same-origin policy, it doesn't mean
it was a great idea to begin with.)


--
http://annevankesteren.nl/


More information about the es-discuss mailing list