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 <[email protected]> wrote:
>
>>
>>
>> On Sat, Dec 20, 2014 at 10:54 AM, Matthew Robb <[email protected]>
>> wrote:
>>
>> On Sat, Dec 20, 2014 at 1:50 PM, Caridy Patino <[email protected]> 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
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
