On Wed, May 8, 2013 at 8:22 AM, Kevin Smith <zenparsing at gmail.com> wrote:

> - Other languages are generally free to define their own semantics for
> referencing external "things", whereas JavaScript (as embedded in the
> browser) already has such semantics in-place.  Adopting different semantics
> will introduce cognitive dissonance.
>

You're saying we have no choice but to make users hard-code locations into
every import site, because HTML. I disagree. We do have a choice.
Require.js had a choice, and it went for abstract names.

Because in practice you need them. The real use cases and problems that
motivate module names in all these other systems don't just vanish when you
move to an environment with URLs.

What you've proposed is to have package loaders:
* invent new URL schemes for URLs that aren't actually locators; and/or
* treat URLs as names, XML-namespaces-style; and/or
* take module names that are URLs and process them contrary to URL
semantics.

I don't think any of those options is a better fit for the Web than module
names.

- Many other languages (compile-to-js aside) can assume access to a file
> system.  They can assume a PATH variable and they can search for an
> external "things" in a multitude of places.  There is a higher level of
> indirection between the logical path and the physical path.
>

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.

-j
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130508/baf98c83/attachment.html>

On Wed, May 8, 2013 at 8:22 AM, Kevin Smith <zenparsing at gmail.com> wrote:

> Other languages are generally free to define their own semantics for
> referencing external "things", whereas JavaScript (as embedded in the
> browser) already has such semantics in-place.  Adopting different semantics
> will introduce cognitive dissonance.
>

You're saying we have no choice but to make users hard-code locations into
every import site, because HTML. I disagree. We do have a choice.
Require.js had a choice, and it went for abstract names.

Because in practice you need them. The real use cases and problems that
motivate module names in all these other systems don't just vanish when you
move to an environment with URLs.

What you've proposed is to have package loaders:

* invent new URL schemes for URLs that aren't actually locators; and/or
* treat URLs as names, XML-namespaces-style; and/or
* take module names that are URLs and process them contrary to URL semantics.

I don't think any of those options is a better fit for the Web than module
names.

> Many other languages (compile-to-js aside) can assume access to a file
> system.  They can assume a PATH variable and they can search for an
> external "things" in a multitude of places.  There is a higher level of
> indirection between the logical path and the physical path.

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.