Module naming and declarations

Kevin Smith zenparsing at gmail.com
Mon Apr 29 03:44:04 PDT 2013


I understand this design now.  At scale, it depends upon an implicit,
centralized naming authority to manage naming conflicts.  The namespacing
scheme of this authority will necessarily be flat because it will be seeded
with names like "jquery" and "ember".

Who's authority will this be?  Google's?  Mozilla's?  Apple's?  Twitter's?
 Node's?  Who will be responsible for maintaining it?  What will the
conflict-resolution strategy be?  Will names be immortal?  Will there be
any standard conventions?  Will it support versioning?

All of these questions will be left unspecified (because ES6 will surely
not specify them), and as with all unspecified needs, a path-dependent and
quite possibly sub-optimal solution will emerge.  Javascript, to some
degree, will be bound to this autonomous naming authority, like it or not.

I think some accounting would be helpful here.

As far as I can tell, the proposed resolution semantics would take about 10
lines of code to write using a module loader API.  Let's be generous and
say that it really comes out to 20 lines.

By baking in these semantics as the default, what do we get?

Assets
----------

- We save the user, at most, from having to include 20 lines of code.

Liabilities
-------------

- We are drawn inescapably toward an unspecified central naming authority
whose policies we cannot foresee or control.
- We break a central tenet of the web (1):  that external resources are
represented by URLs.
- We break a central tenet of the web (2):  that naming authority is
decentralized using DNS.
- As with all things on the web, we will be stuck with these semantics for
a *very long* time.

This is a terrible deal.  It is one-sided, risky, and (worst of all)
it flippantly disregards the conceptual integrity of the host platform.

On the bright side, we have an excellent design that we can return to:  Sam
and Dave's pre-November lexical modules.

{ Kevin }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130429/3bfcad59/attachment-0001.html>


More information about the es-discuss mailing list