Item — HN Reader

There's this facility called slots, at least this is, how it used to be. A resource to be loaded is assigned a slot as available (generally 8 or so) and the browser advances over resource tags. If a resource in the head section is going to be interpreted and is ready, the resource is processed, the slot is freed and available for further jobs. (This is partly, why only hard coded resources are of relevance for the document.DOMContentLoaded event.) There's no connection between single threaded execution and parallel slots.

(Edit: So this may be true for scripts that are requiring further resources, but there's no need for this with scripts that are completely self-contained, like dragula claims to be. Here, this might rather slow down the completion of the page.)

1 comments

> There's no connection between single threaded execution and parallel slots

It has more to do w/ the DOM rendering. The rendering engine is required to wait for a javascript resource to download because it can't know in advance that the js file won't call `document.write`

`document.write` has a nasty property that it calls `document.open()` if the document is not open for writing (which clears the document). Before the DOMContentReady event, the document is open for writing (this is why, among other things, console.log(document.body) yields null and `document.write("<title>foo</title>") sets document.title` when called from <head>)

If parsing of the document was allowed to skip a js file until it downloaded, and if the script has a `document.write` call, then running the script upon download completion (which would typically happen much later than DOMContentReady fired) would trigger the implicit document.open() call, thus yielding different (and catastrophic) semantics.

What you're describing is the now ancient document stream model (document.open – document.write – document.close; calling document.open() after document.close implies document.open() and a loss of the content by an implied call to document.clear()). But I honestly hope, document.write() isn't used today (quite like "eval"), and everyone uses document.createElement(), etc.

As for the rendering engine having to wait for the resource as it hits it, this is exactly why you want it to be ready then, as opposed to just starting to download it and wait. (Even, if it is the very last tag, it will defer completion. And if every library were claiming to be the last one ...)

> If parsing of the document was allowed to skip a js file until it downloaded (…) – This is, what the "defer" and the "async" attributes are for. (And, again, you don't want to call document.open(), be it explicitly or implied, because you would lose any content there is, since it implies "document.clear()". This is Netscape Navigator 2.0 stuff, 1996, really.)

P.S.: What you're heading for, were mere work-arounds in times, when the document-object would have been created only as the parser hit the <body>–tag (up to and including Netscape 3) and when enumerated properties became available only after the body was opened (Netscape 4, etc). But even then, you would apologize in a comment, if such means were required. (E.g., while addressing Netscape 4's document.layers object in 1997.) Now, that there are so many means to do this appropriately, I see no reason at all of banning common resources from the head section and spreading them over the document.body.

If browsers decided to remove document.write and friends, then they would obtain a guarantee that running a script after the recursive DOM assembly routine yields the same result as running the script synchronously within it (regardless of what the script might potentially do), and they would be able to optimize the pipeline to allow you to put scripts in head without triggering a performance problem.

As far as usage in the wild goes, I've seen document-stream-related functions in rich text editors and comet (old school "websocket polyfills") codebases, but that was many years ago. I can't say for certain why browsers still support those functions.