[imports]: improve description of async to clarify execution order (bugzilla: 25470) #218
Labels
Comments
|
Let me close this issue as we do not spend time on HTML Imports moving forward. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Title: [imports]: improve description of async to clarify execution order (bugzilla: 25470)
Migrated from: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25470
comment: 0
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25470#c0
Steve Orvell wrote on 2014-04-25 23:14:04 +0000.
The spec should make it more clear that imports marked with async will not delay execution (of scripts, stylesheets, or custom element upgrades) due to any other async imports.
The only guarantee in the above setup is that 'b.html' is executed before 'c.html'. The async imports 'a.html' and 'd.html' may execute in any order with respect to each other and other non-async imports.
comment: 1
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25470#c1
Glenn Maynard wrote on 2014-04-26 00:56:49 +0000.
Is there really a need to support async? It's much better to limit it to <script defer>-like behavior (which is what you described for b.html and c.html), where loading doesn't block but things always happen in the same order. Web APIs shouldn't be nondeterministic.
comment: 2
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25470#c2
Morrita Hajime wrote on 2014-04-28 21:52:08 +0000.
Unlike <script>, imports machinery has many reasons to be used by non-async [1].
@async-(this-is-inserted-to-avoid-notification-in-migration) is for things that are self contained and don't care about the order.
It is as to no blocking other things.
If the order is a concern, sync is better option.
[1] https://gist.github.com/omo/9986103
comment: 3
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25470#c3
Glenn Maynard wrote on 2014-04-28 22:10:01 +0000.
I'm not saying it shouldn't support asynchronous loading, I'm asking whether it should really support the <script async> model instead of the <script defer> model.
<script async> means "load the resource asynchronously, and run the script as soon as it's ready". <script defer> means "load the resource asynchronously, and run the script in the order it was added (at the end of parsing)". If you have multiple <script defer>s, they all load asynchronously, but later ones don't execute until earlier ones, even if the network load happens to finish first. With the defer model, b.html, c.html, a.html and d.html would always be executed in that exact order (sync before defer, then defer in the order added), which is much easier to test--you don't have to test every possible load order to be certain your page always works, since the load order is always predictable. It seems like <script async> was a bad idea which <script defer> fixed, and now this is making the same mistake. --- comment: 4 comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25470#c4 _Morrita Hajime_ wrote on 2014-04-28 22:51:42 +0000. (In reply to Glenn Maynard from comment #3) > <script async> means "load the resource asynchronously, and run the script > as soon as it's ready". <script defer> means "load the resource > asynchronously, and run the script in the order it was added (at the end of > parsing)". If you have multiple <script defer>s, they all load > asynchronously, but later ones don't execute until earlier ones, even if the > network load happens to finish first. > > With the defer model, b.html, c.html, a.html and d.html would always be > executed in that exact order (sync before defer, then defer in the order > added), which is much easier to test--you don't have to test every possible > load order to be certain your page always works, since the load order is > always predictable. > > It seems like <script async> was a bad idea which <script defer> fixed, and > now this is making the same mistake. <script async> is bad idea because there is no way to declare the dependency to the loaded script. For imports, the import itself can contain a set of imports to require its dependency. So it's much easier for imports to be self contained. This is big difference between and imports. Imports support textual ordering mainly for consistency of other platform bits. Imports shouldn't have to rely on that ordering and so do not well defined imports. Dependency is no longer have to be a list. Now it can be a tree. One good thing not to enforce ordering for @async-(this-is-inserted-to-avoid-notification-in-migration) is that imports that is loaded faster can rendered earlier, without waiting other imports. This is important for mashup-like scenario. Tweet buttons don't to Like buttons and vice versa. --- comment: 5 comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25470#c5 _Morrita Hajime_ wrote on 2014-04-28 22:54:25 +0000. By the way, I understand the unpredictability concern. That's why we're polishing sync scenario so that it blocks as little as possible.The text was updated successfully, but these errors were encountered: