[whatwg] Async scripts

Thu Oct 1 01:07:27 PDT 2009

On Wed, Sep 30, 2009 at 10:14 PM, Darin Fisher <darin at chromium.org> wrote:
> On Wed, Sep 30, 2009 at 9:59 PM, Darin Fisher <darin at chromium.org> wrote:
>>
>> On Wed, Sep 30, 2009 at 1:36 AM, Jonas Sicking <jonas at sicking.cc> wrote:
>>>
>>> There's two things that I don't understand about the 'async' attribute
>>> on <script> elements:
>>>
>>> First of all, why is the parser responsible for executing scripts on
>>> the "list of scripts that will execute asynchronously", as defined by
>>> [1]? It would seem simpler to always perform the steps defined further
>>> down, no matter if the document is still being parsed or not. This is
>>> mostly an editorial issue, but actually seems to make a slight
>>> behavioral difference. Right now if a document contains two async
>>> scripts, the tokenizer must always run one step between the execution
>>> of the two. I.e. This doesn't seem like a particularly desirable, nor
>>> testable, behavior. It's also really painful to implement if the
>>> tokenizer is running on a separate thread. Same thing applies to the
>>> "list of scripts that will execute as soon as possible".
>>>
>>> Second, why are async scripts forced to run in the order they appear
>>> in the markup? I thought the whole idea of the async attribute was to
>>> run the scripts as soon as possible, while still not blocking parsing.
>>> This leads to weird situations like if a document contains the
>>> following markup:
>>>
>>> <!DOCTYPE html>
>>> <html>
>>>  <head>
>>>    <title>...</title>
>>>    <script src="make-tables-sortable.js"></script>
>>>    <script src="analytics.js" async></script>
>>>  </head>
>>>  <body>...</body>
>>> </html>
>>>
>>> In this example, if the first script is changed from being a "normal"
>>> script (as above), to being a async script, that could lead to the
>>> analytics script actually executing later.
>>
>> Did you perhaps mean to say "if both scripts are changed to being async"?
>> If not, then I'm confused because you prefaced this example with "why are
>> async
>> scripts forced to run in the order they appear in the markup?"
>> I agree that normal scripts should not be deferred behind async scripts
>> that
>> happen to be listed before the normal scripts.  I don't think that is the
>> intent
>> of the async script spec.
>> -Darin
>
> D'oh, ignore me.  I overlooked the "async" attribute on the second <script>
> tag.
> Anyways, I agree with you.  Forcing the scripts to run in the order they are
> listed
> seems to defeat the purpose of the async attribute.
> I'm guessing it was spec'd this way to minimize problems that could occur if
> there
> were any dependencies between the scripts.

That was my guess too. However async scripts already "race" with
non-async scripts, so it seems like you're already having to be
careful with what you put in your async scripts.

Additionally the spec has created another mechanism which *does* allow
scripts to run in arbitrary order as soon as they load. You basically
create one <script> that then create other script elements using the
DOM. It's just a pain to use that method. I'll be writing a separate
post about that one later.

/ Jonas