On Sat, Dec 20, 2014 at 10:54 AM, Matthew Robb <matthewwrobb at gmail.com>
wrote:

>
> On Sat, Dec 20, 2014 at 1:50 PM, Caridy Patino <caridy at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141220/a704e645/attachment.html>

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.