<div dir="ltr">On Tue, May 7, 2013 at 7:21 PM, Domenic Denicola <span dir="ltr"><<a href="mailto:domenic@domenicdenicola.com" target="_blank">domenic@domenicdenicola.com</a>></span> wrote:<br><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I think one point that's being hinted at, but not explicitly called out, is the confusing nature of `import "foo"` in the proposed scheme. Notably, it shares this confusion with AMD, but not with Node.js.<br>

<br>
The problem is that `import "foo"` can mean *either* "import the main module for package with name `foo`" *or* "import `foo.js` resolved relative to the base URL".<br>
<br>
In AMD, this problem has been a constant headache on projects that I've worked on at my jobs. In Node.js, however, `import "foo"` always means the former, and never the latter—Node.js has no concept of "base URL." Instead it has the option of doing `import "./foo"`, which has different semantics: "import `foo.js` relative to the module in which this code is found."<br>
</blockquote><div><br>Here's what you would do under the proposal:<br><div><br></div><div>    // import a module in the same package/project<br></div><div>    import "./controllers" as controllers;<br><br></div>
<div>    // import some other package<br></div><div>    import "backbone" as backbone;<br></div><br>The surface syntax deliberately follows Node. The first import is relative and the second is absolute, within the tree of module names (not URLs; neither of those module names is a URL).<br>
<br></div><div>-j<br></div></div></div></div>