Login/Register
When is the Javascript event loop triggered in a HTML page?
Asked Answered
Solved javascripthtmldom-eventsunobtrusive-javascript
S

1

1

I'm aware that the JS function (i.e. setTimeout(function(){...}, TIME)) places the function it received as a parameter in the Browser's event loop, and that this event loop will be processed after all inline/synchronous JS call are processed.

But what actually happens when he have the following HTML page structure:

<html>
 <head>
  <script> MANY INLINED SCRIPTS </script>
  <script src="file.js"></script>
  <script> setTimeout(function(){...}, TIME)</script>
   .
   .
   .

and the page goes, with probably this structure repeating itself until the </html> is reached.

When will the Event queue be processed in such situation?

edit: I want to create some sort of Lazy Loader for the scripts in my page. I rely in content coming from other sources that should appear only after the DOM is parsed and, hopefully, responsive.

Seals answered 4/10, 2012 at 14:23 Comment(6)
Once the document is done being parsed, the event loop is open to handle asynchronous events/actions. Does this example help? – Sisyphus
@Sisyphus I think it's possible for a timeout callback to happen before the DOM is fully ready, but I'm not 100% certain. – Halophyte
@Seals if you've got some particular issue you're trying to figure out, you might want to add that to the question. – Halophyte
Guys! thank you SO much. That answered my question. I wanted to make sure that all the inlined stuff was complete before the Event Loop triggered itself. – Seals
@Sisyphus - One case I've never been clear on. If loading a large HTML document over a poor connection, the download can I believe stall long enough for the browser to paint the DOM that it has got so far to the window. If at the end of the paint, if the browser is still waiting for more characters, will it spin the event loop? – Hiett
@Alohci, that's a really good question. Time to test it. – Sisyphus
H
4

Each inline script is processed as soon as the closing </script> tag is found. Similarly, the <script> tags that import scripts from the server as separate files are processed when the files are received, and that process is synchronous - the browser waits for the script contents before processing (except see the relatively new "async" attribute for <script> tags edit and the old "defer" attribute on IE, which may or may not have ever worked predictably (thanks @RobG)).

Thus your inline code with a call to setTimeout() will run when the browser sees the complete <script> block, and then the function passed will be invoked after the given number of milliseconds (roughly) has elapsed. You can't rely too heavily on accuracy of timeout handling.

There are other events besides the timeout mechanism: user interactions, ajax, etc. Those all get funneled through the same gateway, conceptually; that is, if your timeout is scheduled to run, but a user clicks a button a few milliseconds beforehand, your timer code will wait for the button processing to finish.

Halophyte answered 4/10, 2012 at 14:25 Comment(1)
And the (much older, IE invented) defer attribute where supported and not ignored. – Classis

© 2022 - 2024 — McMap. All rights reserved.