<div dir="ltr">this would also be useful in some other cases, for instance the following code that works (though is not advisable) in (node flavored) CommonJS and AMD is impossible to recreate (as far as I can tell) using the current hooks<div>
<br></div><div>```js</div><div>// file shim.js</div><div>Array.prototype.stupid = function () {</div><div>   // don't do this</div><div>}</div><div><br></div><div>// file app.js</div><div>var a = [];</div><div>typeof a.stupid === 'undefined';</div>
<div>require('./shim');</div><div>typeof a.stupid === 'function';<br></div><div>```</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 19, 2014 at 12:52 PM, Ian Hickson <span dir="ltr"><<a href="mailto:ian@hixie.ch" target="_blank">ian@hixie.ch</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
(For some reason, e-mails containing the following text have failed to<br>
make it to the es-discuss list. Not sure what's going on with that.<br>
Anyway, this is a new e-mail that contains more or less the same contents<br>
but changed a bit in case there's some filter or bug that the last e-mails<br>
were hitting.)<br>
It would be helpful if there was a way that the module _execution_ (after<br>
it's been parsed and dependencies have been extracted) could be delayed by<br>
the loader.<br>
Suppose a page is loading and has reached a quiescent state, and so the<br>
browser thinks "ok, time to preload some scripts". It might start with one<br>
script, and then find that it imports another, and would then fetch that<br>
one. But it doesn't want to actually execute anything, because the scripts<br>
haven't been invoked yet.<br>
Since ES6 does all the heavy lifting of finding the imports in the source<br>
code and setting up all the linking, it would be good if the browser could<br>
rely on that but just put a stop to the final execution step until such<br>
time as the resource is actually needed. Doing this in the fetch or<br>
translate hooks wouldn't work because we need the instantiate hook to do<br>
its dependency tracking bit first.<br>
It's possible, based on this and earlier e-mails about how to change<br>
dependencies, that really what we need is a new hook that splits<br>
"instantiate" in half -- half for handling dependencies, and half for<br>
handling execution. That might also enable the "instantiate" hook to<br>
change to not return a weird object or undefined. It would similarly<br>
address the "how do I add out-of-band dependencies" issue I mentioned<br>
earlier. Combined with changing where dependencies are first initialised,<br>
this would address most of the dependency issues I've raised, I think.<br>
This would also allow for ES6 import syntax to be used inline to declare<br>
some dependencies, as in the case of an inline script marked as being<br>
on-demand containing something like:<br>
     import "jquery";<br>
     import "jquery/animations";<br>
     import "myapp/logic";<br>
If the browser could notice that this was an inline script and have the<br>
ES6 module system pre-parse it to discover the imports, it could preload<br>
them and then when the script element's execute() or load() method<br>
(whatever we end up calling it) is invoked it could just unblock the<br>
execution and immediately have the scripts run.<br>
Assuming we use the ES6 module loader to handle all the loads in an HTML<br>
document, in the Web context, there are also some interesting questions to<br>
resolve around the issue of de-duping.<br>
Suppose you had an inline style element markup containing:<br>
    @import "<a href="http://example.com/foo.x" target="_blank">http://example.com/foo.x</a>";<br>
...followed by an external script element src="" pointing to:<br>
    <a href="http://example.com/foo.x" target="_blank">http://example.com/foo.x</a><br>
This causes foo.x to be evaluated once as a style sheet, and once as a<br>
script. In the new world, though, if every load goes through the ES6<br>
module system, how do we distinguish them in the module registry?<br>
Similarly, consider the reverse case of an inline script module saying:<br>
    import "<a href="http://example.com/foo.x" target="_blank">http://example.com/foo.x</a>";<br>
...followed by an inline style block saying:<br>
    @import "<a href="http://example.com/foo.x" target="_blank">http://example.com/foo.x</a>";<br>
After the module's import, foo.x is in the registry as an ES6 module. But<br>
the semantics of the @import rule are that it must be interpreted as CSS,<br>
so that doesn't work.<br>
It would be great if it was possible to attach metadata to the key that is<br>
used in the registry that would be part of the registry key but not<br>
exposed in the module API. For example, @import could tag all its modules<br>
as "CSS", so that the above would be keyed as {"<a href="http://example.com/foo.x" target="_blank">http://example.com/foo.x</a>",<br>
CSS}. Regular imports wouldn't key anything, so that in the case of an<br>
inline CSS block followed by an inline ES6 module both importing the same<br>
file, the second import would find the pre-existing CSS import rather than<br>
try to introduce a new one.<br>
<span class="HOEnZb"><font color="#888888"><br>
Ian Hickson               U+1047E                )\._.,--....,'``.    fL<br>
<a href="http://ln.hixie.ch/" target="_blank">http://ln.hixie.ch/</a>       U+263A                /,   _.. \   _\  ;`._ ,.<br>
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>-Calvin W. Metcalf