On Apr 29, 2013, at 6:34 AM, Andreas Rossberg <[email protected]> wrote:
> ...you are generally assuming the use of some package manager. This
> is a fairly significant assumption, that I wished I had heard being
> made explicit in any of the previous discussions. AFAICT, it is key,
> and without it, your proposal cannot fly. Not in a world with tens of
> thousands of module releases, anyway.
Not only is this wrong -- it'll be just fine to use ES6 without package
managers -- but your proposal does not make any material difference in the
relative dependence on package managers.
> In other words, package managers are great, and the module system
> should definitely support them. But it should not, de facto, _require_
> them -- especially not on the web.
I believe package managers will become a common part of the JS development
experience. This is true for almost every modern programming environment, from
Ruby to Scala to Node. I also think multiple package managers will exist, and
that's fine too. There's nothing centralized about this that makes it
inappropriate for the web. In fact, it's the nature of decentralization to
leave the space open.
Finally, plenty of people will continue to use the system without
centralization. For many packages, particularly popular ones, people will
choose globally unique names like "backbone" and no reasonable software package
will step on their toes.
As an analogy, consider the Unix file system. You can build software and deploy
it without using a package manager at all, and everyone knows not to take the
name "vi" (except actual vi implementations). But almost everyone uses a
package manager in practice, there are multiple package managers, and they
don't require any new semantics from the file system.
> More specifically, everything should still play nice with standard web
> mechanisms. For me, the web platform implies that I should be able to
> address modules as remote resources (it's a choice _not_ to use that
> mechanism). That requires that the system allows proper URLs as module
> identifiers.
Fully agreed, and if it wasn't clear, the current system does completely
support this. You can use a URL as a module name. In the default browser
loader, you can choose to import a module from an explicit URL:
import { $ } from "http://my.cdn.com/jquery/1.9";;
and it will use that URL both as the logical name and as the place to go and
fetch the bits. If you don't use an absolute URL, it treats it as a path, which
defaults to loading as a source file from a relative URL derived from the
module name.
> And at that point, you absolutely want your logical names
> to integrate nicely into the URL name space semantics, which
> currently, they do not do at all. (The proposal calls module ids
> "URLs", and syntactically, they form a sublanguage. But semantically,
> this sublanguage is divorced and interpreted in a completely
> incompatible way.)
Maybe there's some confusion caused by misleading or out-of-date wording on the
wiki here. I apologize if that's what's happened -- I'll have the wiki updated
and clarified before the May meeting.
The sublanguages are fully compatible. In fact, note that they're only two
sublanguages for the *browser loader*. In the browser loader, if you use an
http:// URL, it will fetch the module from the web. But the core semantics
simply treats module names as uninterpreted strings.
> That brings me to your repeated assertion that URLs are not
> appropriate for logical names, because they are, well, logical, not
> physical.
No, that's not the argument. The argument is that *URI's* are not appropriate
(I wasn't using the right terminology either!), because they don't work well in
practice.
> Of course, I should have said URI, and as usual, that's what
> I really meant. :) URIs generally _are_ logical names for resources.
> Arguably, the inherent abstraction from logical to physical (or
> virtual) is one main reason for their existence. So, from my
> perspective, URIs are _exactly_ the appropriate tool.
This idea is attractive enough that it comes up a lot, but it just doesn't ever
seem to work out in practice.
History is not on your side here. The W3C has moved away from using URI's as
unique names or namespaces:
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#changes-drafts
URI-based DTD declarations and XML namespaces failed and have been replaced
with simple identifiers. The modern DTD for HTML5 is <!doctype html>. The
modern way to embed data in HTML tags is with data-<id> attributes where the
<id> is any user-chosen identifier:
http://www.w3.org/html/wg/drafts/html/master/dom.html#embedding-custom-non-visible-data-with-the-data-*-attributes
You've been arguing we should use time-tested, well-understood, and successful
mechanisms. The problem is, URI's as logical names, while time-tested and
well-understood, are a failure.
> That does not mean that logical names have to become unreadable or
> awful to type. Just that they are slightly more explicit. A schema
> prefix -- say, jsp: for a random strawman -- is good enough and should
> not offend anybody in terms of verbosity. (If it did, then I'd have
> little hope for the evolution of the web platform. :) )
First, let's be clear: this is literally an argument over the surface syntax of
public module names, nothing more. You're arguing for the universal addition
of a few characters of boilerplate to all registered module names. That's just
bad ergonomics for no gain. Not only that, it hurts interoperability with
existing JavaScript module systems.
There's a reason why the existing systems favor lightweight name systems.
They're nicely designed to make the common case syntactically lighter-weight.
And they absolutely can co-exist with naming modules directly with URL's.
Dave
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
