Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Top-level await integration and multiple script graphs #4419

Closed
domenic opened this issue Mar 7, 2019 · 2 comments
Closed

Top-level await integration and multiple script graphs #4419

domenic opened this issue Mar 7, 2019 · 2 comments
Labels
integration Better coordination across standards needed topic: script

Comments

@domenic
Copy link
Member

domenic commented Mar 7, 2019

Consider this example, in the context of the upcoming TC39 top-level await proposal:

<!DOCTYPE html>
<script type=module src=a.mjs></script>
<script type=module src=b.mjs></script>
// a.mjs
console.log("a1");
await new Promise(r => setTimeout(r, 100));
console.log("a2");
// b.mjs
console.log("b");

Should the output be:

  • (Wait for start) a1, b, a2, or
  • (Wait for finish) a1, a2, b?

That is, should the HTML script-execution infrastructure wait for the evaluation of the a.mjs script graph to run to completion and yield to the event loop, then start evaluating the b.mjs script graph? Or should it delay evaluating the b.mjs script graph until the a.mjs script graph's promise has settled?

Note that, per the TC39 semantics chosen, if instead the HTML file was

<!DOCTYPE html>
<script type=module>
import './a.mjs';
import './b.mjs';
</script>

then the answer would be "wait for start". Should HTML depart from that?

My instinct is no; we should align <script>'s design with import's design and avoid earlier script graphs being able to indefinitely delay the evaluation of later ones. (Consider if a.mjs instead had await new Promise(() => {}).) The same reasoning given in the top-level await proposal seems to apply here; if b.mjs wants to wait on a.mjs, then b.mjs should take on an actual dependency (i.e., it should import './a.mjs'.) But, it is worth discussing, since we need to write the spec text and make a choice.

Since the issues are so similar between <script> and import, I encourage people to read the top-level await FAQ, which touches on import. Ideally we'd constrain this thread to discussing whether or not <script> should behave the same as import, and delegate the decision of how import behaves to that repository.

/cc @whatwg/modules
@domenic domenic added topic: script integration Better coordination across standards needed labels Mar 7, 2019
@littledan
Copy link
Contributor

I agree with @domenic's reasoning above, and have written this up as #4352 (though the FlushJobs text is likely to be removed given discussion in #4400).

@domenic
Copy link
Member Author

domenic commented Aug 22, 2019

Closing as we've settled on an answer, although I'll note that we should be sure to test this case.

@domenic domenic closed this as completed Aug 22, 2019
@domenic domenic mentioned this issue Aug 22, 2019
Merged
3 tasks
@domenic domenic mentioned this issue Sep 5, 2022
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
integration Better coordination across standards needed topic: script
Milestone
No milestone
Development

No branches or pull requests
2 participants
@littledan @domenic