<div dir="ltr"><br><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 class="im"><br>
> It seems to me that when the module graph scales to a certain size, a<br>
> package manager (and name registry) is going to be essential to this design.<br>
<br>
</div>Here, you're saying the design needs a package manager to work well at<br>
scale, and calling it a flaw.<br>
<div class="im"><br></div></blockquote><div><br></div><div style>I wouldn't call it a flaw.  But a requirement that has repeatedly surfaced in this discussion is that the system must work out-of-the-box, and therefore I think it's fair game to analyze just how well the "logical names" design works out-of-the-box.</div>
<div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> Let's imagine a world where publicly available modules are located at sites<br>
> specifically designed for naming and serving JS modules.  Call it a web<br>
> registry.  Intra-package dependencies are bundled together using lexical<br>
> modules - the package is the smallest unit that can be referenced in such a<br>
> registry.<br>
<br>
</div>Here, you're _assuming_ a "web registry" and claiming that it makes<br>
your suggestion "work out-of-the-box".<br></blockquote><div><br></div><div style>Sure - and why not?  The internet *is* the included battery.  Obviously, I understand that there exists no such registry today, but everything is in flux.</div>
<div style><br></div><div style>{ Kevin }</div></div></div></div>