Re: Executing script-inserted external scripts in insertion order

On 10/18/10 12:59 AM, Adam Barth wrote:
> There's a trade-off between performance and predictability.  Defer is
> predictable.  Async is performant.  You're asking for a middle ground,
> which might be useful.  However, you'll probably get better
> performance if you just concatenate all your dependent scripts into a
> single network request

The use case is that the page loading the scripts doesn't control them: 
they're coming from a CDN or whatnot.

>> Here's why I assert that the change in question will NOT slow down existing
>> sites for IE/Webkit: because I'm arguing that I think it makes sense
>> compat-wise for browsers (and spec) to implement `true` as the default value
>> for `async`, but *only* on script-inserted scripts. Of course, that makes
>> the default opposite of what how it defaults to `false` on parser-inserted
>> scripts, which might seem odd at first glance but I think is logically
>> defendable upon examination.
>
> That seems like an independent question from whether we fetch scripts
> with non-executable MIME types.  How does that solve Firefox's
> problem?

Because the library in question will be updated to set async=false on 
the scripts it inserts.

> Why would they be able to implement that but not implement
>  what the spec currently says?

Because if we implement what the spec currently says, the library in 
question has no way to ensure order of script execution.

>> Good for whom?
>
> For authors.

That's a pretty wide-ranging demographic.

Note that in this case we're talking about library authors, not web page 
authors, by the way; that allows some ease-of-use bars to be set higher 
if it gives more power, imo.

> It's much easier to author pages that use defer than
> pages that use async

Sure.

> because you don't have any race conditions to
> worry about.  Everything happens at a predictable time and you get
> better performance than if you didn't use defer.

That depends on how you define "performance".  You get better 
performance along some axes, but not others.

> If you want to go as fast as possible, then you should use async, but
> you're going to have to be careful to manage dependencies between your
> scripts and between your scripts and the DOM.

Right; the issue here is that this is too high an ease-of-use bar 
(ending up in "impossible" territory if you don't control the scripts).

>> And in which the timing at which the scripts run matters in a meaningful way
>> (in that, say, the scripts aren't just loading API), right?
>
> Sure.  Scripts that are meant to do something, such add add
> functionality to the page.  That functionality won't be available
> until the scripts execute

Yes, but that doesn't matter if the page doesn't use the functionality 
until onload.

That is, I agree that in theory running the script ASAP is faster if the 
scripts have no dependencies on each other, and I agree that it's simple 
to construct pages that would show the performance benefit of that. 
What I'm asking is whether there are such pages in real life.

>> There have been three proposals.  At least one doesn't add such a dependency
>> by default, but DOES allow the page to add it if desired.
>
> Isn't that the one that's been withdrawn?

No.

> Hum...  Steve's blog was up a moment ago when I posted that email.  Oh
> well.  He basically goes through all the ways of executing
> non-blocking scripts that were feasible in April 2009 and recommends
> using script-inserted script elements.

Sure, but is that just because they don't block the parser, or for some 
other reason?

> I'm happy to look at a proposal fresh if you'd like to explain it in
> an unambiguous way.  AFACT, async already works on script-inserted
> scripts, both in the spec and in the WebKit implementation.  However,
> it's possible I'm confused about which proposal you're currently
> advocated for.

The proposal I think makes the most sense at the moment is the 
following, as I understand it:

1)  The DOM async property no longer fully reflects the "async"
     attribute.  This allows the property to be true even if the
     attribute is not set.  Setting the property also sets or removes
     the attribute. Setting or removing the attribute sets the
     property (to true and false respectively).
2)  When a <script> element is created via createElement, its async
     property defaults to true, even though it has no "async" attribute.
3)  When a script-inserted <script> element's async property is false,
     it is ordered with respect to other script-inserted <script>
     elements with async == false.

#3 is what currently doesn't "work" in webkit and in the spec.  #2 is 
needed to allay your concerns about implementing #3 regressing 
performance.  #1 is needed to make #2 possible.

Is that unambiguous enough?  Any questions?  Concerns?  Suggestions? 
Ballot initiatives?  ;)

-Boris

Received on Monday, 18 October 2010 05:21:34 UTC