ES6 modules[1] have a script loader API[2].
That API is pretty powerful to the point it can emulate other script
loaders, load files that are not ES6 modules, and even load text files
that aren't JS (intended for compilation of coffeescript-like languages,
but could be abused for anything):
https://gist.github.com/wycats/51c96e3adcdb3a68cbc3#using-existing-libraries-as-modules
There's a very high overlap between module dependencies and <script
dependencies> proposal. I think at very least it would be useful to define
<script dependencies> in terms of ES6 modules, or even abandon markup
solution to avoid duplicating features.
ES6 modules however do not solve the performance problem. In fact they
would benefit from UA having a list of all dependencies up front
(otherwise file's dependencies can only be discovered after that file is
loaded, which costs as many RTTs as the height of the dependency tree).
So I think that eventually ES6 modules + link[rel=subresource] could be
the answer. The <link> would expose URLs to (pre)load for performance, but
modules would handle actual loading/execution for flexibility and
reliability.
--
regards, Kornel
[1] http://wiki.ecmascript.org/doku.php?id=harmony:modules
[2] http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders
