[whatwg] Async scripts
jonas at sicking.cc
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
>>> ? 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>
>>> <script src="make-tables-sortable.js"></script>
>>> <script src="analytics.js" async></script>
>>> 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
>> scripts forced to run in the order they appear in the markup?"
>> I agree that normal scripts should not be deferred behind async scripts
>> happen to be listed before the normal scripts. I don't think that is the
>> of the async script spec.
> D'oh, ignore me. I overlooked the "async" attribute on the second <script>
> Anyways, I agree with you. Forcing the scripts to run in the order they are
> 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
> 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.
More information about the whatwg