Module naming and declarations
jason.orendorff at gmail.com
Wed May 8 13:53:19 PDT 2013
On Tue, May 7, 2013 at 7:01 PM, Anne van Kesteren <annevk at annevk.nl> wrote:
> On Tue, May 7, 2013 at 4:39 PM, Jason Orendorff
> <jason.orendorff at gmail.com> wrote:
> > Set aside absolute-url imports. Suppose we just dropped them. Would you
> > still think that module names are URLs? If so, do you think about other
> > languages in the same way?
Not weirder than trying to equate it to HTML and CSS, surely!
They operate on multiple platforms that do not share a universal
> addressing system and therefore a layer of abstraction had to be
> invented to make it easier to work those languages across multiple
I don't think that's the reason those systems have abstract names for
packages/modules. All of these systems were designed for use on systems
with hierarchical filesystems supporting absolute and relative paths. Any
one of them could all have chosen to implement `import` by mapping the
package/module name directly to a filename in a dead-simple, one-to-one
way; but none did.
(Even C, a language designed 40+ years ago by people whose key technical
virtue was their willingness to eliminate unnecessary abstractions, lets
you configure #include paths at compile time.)
Are the different environments where people will deploy JS code really
*more* uniform than where people deploy Java? I don't know. But surely not
so much so that third-party packages should just go ahead and embed the
locations of their dependencies.
I guess that's another point I had not really thought of, the web
> platform will get a way to execute some script at "fetch", which is
> basically a low-level version of the module loader.
Yeah, these two efforts should meet and talk before long. Related ideas
going around, for sure.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss