IMO order should always be preserved.
________________________________
From: Caridy Patino<mailto:car...@gmail.com>
Sent: 2014-12-20 21:21
To: Allen Wirfs-Brock<mailto:al...@wirfs-brock.com>
Cc: es-discuss list<mailto:es-discuss@mozilla.org>
Subject: Re: Any news about the `<module>` element?
The problem is that those inline modules might import other modules, e.g.:
<script type="module">
import foo from "./foo.js";
window.sequence = 10;
console.log(window.sequence);
</script>
<script type="module">
console.log(" should be 11: " + ++window.sequence);
</script>
IMO they should be async (implicit and not configurable) and if the order
should be preserved then we can explore the `defer` attribute, saying:
<script type="module" defer>
import foo from "./foo.js";
window.sequence = 10;
console.log(window.sequence);
</script>
<script type="module" defer>
console.log(" should be 11: " + ++window.sequence);
</script>
Although, I consider this an edge case, and in the majority of cases we will
simply use modules that does not rely on any other online module in the page
that defines global values, and if they have to share functionality, they can
simply rely on a module, saying:
<script type="module">
import {sequence} from "./mod.js";
console.log(sequence);
</script>
<script type="module">
import {sequence, increment} from "./mod.js";
increment();
console.log(" should be 11: " + sequence);
</script>
According to the current algorism in the specs, this should work just fine with
the right sequence of execution.
/caridy
On Sat, Dec 20, 2014 at 6:59 PM, Allen Wirfs-Brock
<al...@wirfs-brock.com<mailto:al...@wirfs-brock.com>> wrote:
On Dec 20, 2014, at 2:02 PM, Caridy Patino wrote:
John, think of <script defer src="mod.js"></script>.
For <script type=module>, async is implicit.
What if you have a series of modules that need to be evaluated in sequential
order? (Remember, that a module with no imports is the module worlds
equivalent to a simple sequential script.). eg:
<script type="module">
window.sequence = 10;
console.log(window.sequence);
/script>
script type="module">
console.log(" should be 11: " + ++window.sequence);
</script>
<script type="module">
console.log(" shoud be 12: " + ++window.sequence);
</script>
Allen
Sent from my iPhone
On Dec 20, 2014, at 3:01 PM, John Barton
<johnjbar...@google.com<mailto:johnjbar...@google.com>> wrote:
On Sat, Dec 20, 2014 at 10:54 AM, Matthew Robb
<matthewwr...@gmail.com<mailto:matthewwr...@gmail.com>> wrote:
On Sat, Dec 20, 2014 at 1:50 PM, Caridy Patino
<car...@gmail.com<mailto:car...@gmail.com>> wrote:
what make you think this proposal implies blocking?
?I think he was reading your examples using "require()" and thinking you were
suggesting that the semantics would match.?
Indeed that is what I was thinking.
A non-blocking <module> tag is a poor match to HTML, a declarative language
where order of tags means order of parsing and rendering. Giving up this
fundamental characteristic of HTML, in the long-shot effort to improve the
apparent load time for some amateur Web sites, has become dogmatic so I suppose
there is no value in discussing it.
A non-blocking <module> tag would also prevent experienced developers from
controlling rendering through JS action. That means they will need to use
<script> tags which we'd like to deprecate or we'd have to have a blocking form
of <module>. We'll probably end up with the latter choice.
On the node side, require() is curiously synchronous given node's heavy
emphasis on asynchronous IO. As with the browser <script> tag, the synchronous
require() is the best choice for simplicity. But the synchronous semantics
prevents optimizations on both platforms. An asynchronous root-module loading
API in a next generation system opens new opportunities. I hope and expect
we'll end up with an async option on node.
On balance I think a non-blocking <module> tag with optional blocking is
reasonable.
However, the description of the browser loading as "require()" within a
asynchronous <module> tag is really a complete departure from all the previous
discussions. A system based on require() is not statically analyzable. I could
go on, but really a shift to this extreme seems so unlikely that there must be
some misunderstanding. Rather I assume that the content of the <module> tag
will be ES6 code as we know it now and that we will have an additional dynamic
loading API that will be asynchronous much like we had earlier this year.
Exactly the same solution would work in node.
In other words, <script> and require() would not be used in future code, an
async API would be available for root loading, and most developers most of the
time would write synchronous code manipulating modules contents. If we are not
heading in this direction I hope there will be more discussions in public.
jjb
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org<mailto:es-discuss@mozilla.org>
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
