<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div class="im"><div><br></div></div><div>You're saying we have no choice but to make users hard-code locations into every import site, because HTML. I disagree. <br></div></div></div></div></blockquote><div><br></div>
<div style>That is not my position.  My position has always been that if you want "logical names", then a reasonable way to do that is via a scheme:</div><div style><br></div><div style>    import $ from "package:jquery";</div>
<div style><br></div><div style>There are others (e.g. a syntax-based solution like Brendan mentioned), but the important thing is that we don't overload the semantics that are already in place for URIs.</div><div style>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div>What you've proposed is to have package loaders:<br>
<div>* invent new URL schemes for URLs that aren't actually locators; and/or<br></div><div>* treat URLs as names, XML-namespaces-style; and/or<br>
</div><div>* take module names that are URLs and process them contrary to URL semantics.<br><br></div></div></div></div></blockquote><div><br></div><div style>I don't think that your list adequately represents my position.  Let me try to restate.</div>
<div style><br></div><div style>I've proposed that module loaders have the freedom to specify whatever semantics they choose for *URIs* that appear in module specifiers, even if those semantics are questionable.  For consistency, the *default loader* should not choose semantics that conflict with standard URLs.</div>
<div style><br></div><div style>And please do not represent my position by using the term "XML".  Thanks  : )</div><div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im"><div><br></div></div><div>The lack of a fast, reliable filesystem makes some things (like CLASSPATH) less attractive, and other things (preloading, on-demand server-side concatenation, client-side caching, CDNs, etc.) more attractive. Internet access makes new things possible. I think the options that package loaders will want to explore for JS, vs. other languages, are more diverse, not less.<span class="HOEnZb"><font color="#888888"><br>

</font></span></div><span class="HOEnZb"><font color="#888888"><div><br></div></font></span></div></div></div></blockquote><div><br></div><div style>I agree with you 100%, of course. That is why, personally, I would rather us provide the ingredients for experimentation than try to bake something in : )</div>
<div style><br></div><div style>{ Kevin }</div></div><br></div></div>