>
> The requirement I'm talking about -- which is absolutely critical for the
> practicality and adoption of ES6 modules -- is that the system has to work
> well out of the box without tools. And the current system does. The only
> thing you have to change if you decide to repackage modules into scripts is
> a *single* piece of code staged before application loading that configures
> the locations of the modules. Note that this is how require.js works.
>
Does it really work so well out-of-the-box, though? Let's say that I want
to develop an app which depends on some module M. Let's say that in the
module dependency graph reachable from M, there are 15 other modules. So
in order to get things working at all, I'll have to go out and find the
source code for all 16 modules in this graph and place them (with the
correct names) into my module base URL.
It seems to me that when the module graph scales to a certain size, a
package manager (and name registry) is going to be essential to this design.
On the other hand, I think it is possible with URLs to create a system
which truly does work out-of-the-box.
Let's imagine a world where publicly available modules are located at sites
specifically designed for naming and serving JS modules. Call it a web
registry. Intra-package dependencies are bundled together using lexical
modules - the package is the smallest unit that can be referenced in such a
registry. The registry operates using SPDY, with a fallback on HTTPS, so
for modern browsers multiplexing is not a critical issue. In such a world,
I can create a page:
<!doctype html>
<html>
<head>
<script async>
import Foo from "https://webregistry.org/foo";;
</script>
<body></body>
</html>
And no matter how large "foo"'s dependency graph is, it just works without
any configuration or copying of files.
Of course, long URLs aren't any fun to type and authors may want to
localize external dependencies to avoid such typing:
// foo.js, in the current project
export * from "https://webregistry.org/foo";;
// Referencing the localized dependency
import Foo from "foo.js";
By making the module specifier an absolute URL in this manner, we can
statically analyze or load entire module graphs by looking at the source
code alone. That's pretty neat.
(I've thought about, but did not include any versioning considerations in
the above.)
{ Kevin }
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
