Module naming and declarations

Jason Orendorff jason.orendorff at gmail.com
Mon May 6 16:39:04 PDT 2013


On Sat, May 4, 2013 at 3:12 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
> On Sat, May 4, 2013 at 12:46 AM, Jason Orendorff
> <jason.orendorff at gmail.com> wrote:
>> 0. No effort: modules are loaded relative to the document base url,
>> with ".js" appended. So `import "jquery"` maps to the relative URL
>> "jquery.js".
>
> Isn't that weird? If I have a script at /resources/test which does a
> bunch of imports and I use /resources/test from resources /a/b and
> /c/d the document base URL will be different for both.

It's a little weird, but it would also be weird to treat module names
as URLs relative to the containing script by default, and then when
the user goes to Option 1, suddenly treat them as relative to one
central URL. I'm sensitive to that because Option 1 is the sweet spot
for small-to-medium-sized sites that don't have so much JS that they
feel the need for a package manager. (I believe that package managers
shouldn't be obligatory for everyone in practice.)

In practice, when a user realizes Option 0 relative URLs are biting
them, they can go to Option 1, which is one line of code

    <script>System.baseURL = "https://mysite.example.com/static/js/";</script>

...and now they can live comfortably for weeks or years as their
project grows, before deciding they need System.ondemand(), or a
package manager, or whatever.

And this "weird" behavior is hardly without precedent: aren't *all*
other URLs a script deals with, including the existing APIs for
loading other scripts (adding a <script> tag or loading the code with
an XHR), resolved relative to the document base URL?

> (Document base URL does not work for workers either.)

Good point. It can do what XHR does in workers: use the script's base
url. (If the site happens to have a single directory for serving
static js, and the worker script happens to be in it, that's
especially convenient.)

> I thought the import statements had to be first. Does this effectively
> require two script elements?

Yes.

-j


More information about the es-discuss mailing list