W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2009

[whatwg] Async scripts

From: Darin Fisher <darin@chromium.org>
Date: Wed, 30 Sep 2009 22:14:59 -0700
Message-ID: <bd8f24d20909302214i5e35099btbef128ce6ad99d94@mail.gmail.com>
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.

-Darin



>
>
>>
>> I thought the purpose of the async attribute was to avoid people
>> having to do nasty DOM hacks in order to increase pageload
>> performance, but this makes it seem like such hacks are still needed.
>>
>> What is the use case for the current behavior?
>>
>> [1]
>> http://www.whatwg.org/specs/web-apps/current-work/?slow-browser#when-a-script-completes-loading
>>
>> / Jonas
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090930/3232fe39/attachment-0001.htm>
Received on Wednesday, 30 September 2009 22:14:59 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:52 UTC