[whatwg] Proposal for separating script downloads and execution

[Will Alexander]

On Feb 11, 2011 5:00 PM, "Nicholas Zakas" <nzakas at yahoo-inc.com> wrote:
>
> Once again, the problem with changing how src works is that there's no way
to feature detect this change. It's completely opaque to developers and
therefore not helpful in solving the problem.
>
I completely agree with what you're saying as it relates to *this* feature.
My only point is, even absent feature testing, readystate,or an ondownload
event, this behavior is useful and benefits existing code.

Execution order mgmt  is one example.  Many of these loaders create and then
queue the script elements, using onload chaining to manage their
attachment.   Without the use of any prefetching hacks, scripts will load in
parallel in IE.  This is because IE implements the specs current performance
suggestion, *not* because it also provides a readystate.  The loader does
not need to know whether a script is in cache before attaching, it only
needs to know the prerequisite libs have been loaded.  There are a number of
add'l use-cases that do not require that prefetching or ondownload be either
available or implemented.   Browsers that prefetch simply perform better
than those that do not.  Many authors are willing to accept this tradeoff,
and more will be prone to do so if this achieves wider adoption.  We have it
for Image's, so why not scripts?

 > will throw an error.

I don't think its a stretch to see how an error might not always be
"appropriate".  For many of those, however, opaque pre fetching would be
perfectly acceptable.

  Consider the controljs example in which the menu code does not load until
it is clicked.  There's no requirement that it run synchronously so it is
acceptable for the script's execution to simply be scheduled in response to
the click event.   A non-prefetching browser would not be as "performant"
but would still work.

>
> As I said before, I'm not married to all bits of this proposal. If there's
some other way to achieve the same functionality, I'm all for it. The main
goals are listed in the doc, and I'm happy to support any proposal that
achieves all of them.
>

Just to reiterate, prefetching alone is clearly not the solution to your
problem statement.  I failed to make that clear before.  My point is only
that it is useful, does not require readystate to be so and it seems like an
easy change to the spec.

It also belongs in a separate discussion.  I should not have clouded this
thread with more slightly-related-but-mostly-off-topic fud.
> -N
>
>
> -----Original Message-----
> From: whatwg-bounces at lists.whatwg.org [mailto:
whatwg-bounces at lists.whatwg.org] On Behalf Of Will Alexander
> Sent: Friday, February 11, 2011 12:58 PM
> To: whatwg at lists.whatwg.org
> Subject: Re: [whatwg] Proposal for separating script downloads and
execution
>
> On Feb 11, 2011 10:41 AM, "Nicholas Zakas" <nzakas at yahoo-inc.com> wrote:
> >
> > We've gone back and forth around implementation specifics, and now I'd
like to get a general feeling on direction. It seems that enough people
understand why a solution like this is important, both on the desktop and
for mobile, so what are the next steps?
> >
> Early on it seemed there was general consensus that changing the
> existing MAY fetch-upon-src-assignment to MUST or SHOULD.  Since that
> is only tangential to this proposal, provides immediate benefit to
> existing code, and can satisfy use cases that do not require strictly
> synchronous execution.
>
> I'm hopeful the change would generate activity around these bug reports.
>
> https://bugs.webkit.org/show_bug.cgi?id=51650
> https://bugzilla.mozilla.org/show_bug.cgi?id=621553
>
> If I am wrong in my assessment of the consensus, does it make sense to
> consider that change outside of this proposal?
>
> > Are there changes I can make to my proposal that would make it easier to
implement and therefore more likely to have someone take a stab at
implementing?
>
> I may have missed it, but what would execute() do if the url has not
> been loaded?   Would it be similar to a synchronous XHR request, lead
> to ASAP execution, or throw error?
>
> > Is there a concrete alternate proposal that's worth building out
instead?
>
> If execute() must be synchronous, then readystate is not applicable.
> Otherwise, while it should be considered, it would probably take
> longer to describe and has no corresponding markup semantics.
>
> Glenn's point about noexecute  being a natural extension of defer and
> async is a good one, however neither of those required changing onload
> semantics or introducing a new event type.  Readystate on the other
> hand is already a well-known concept. Moreover, if history is any
> indication, we'll continue using it to implement deferred exec for
> awhile.