[whatwg] Proposal for separating script downloads and execution

[Nicholas Zakas]

The reason for using readyState/onreadystatechange was to build on kind-of-existing functionality rather that introducing something new. When thinking through the problems, I was easily able to map this onto my main goals:

1) Determine if a script is downloaded successfully or not.
2) Determine if a script has already been executed.

I'm not suggesting this is the only possible implementation, just that it was something familiar to developers already, and building on top of it may make understanding the new functionality a bit easier.

And from earlier in the thread: I'd also be fine if this were a scripting-only feature and wasn't used in markup. That was always a secondary use case in my mind.

Glenn - thanks for steering the conversation back towards interfaces.

-N

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Glenn Maynard
Sent: Wednesday, February 09, 2011 7:43 PM
To: Kyle Simpson
Cc: whatwg at lists.whatwg.org
Subject: Re: [whatwg] Proposal for separating script downloads and execution

On Wed, Feb 9, 2011 at 10:06 AM, Kyle Simpson <getify at gmail.com> wrote:

> The original proposal is in fact more focused on the markup-driven use-case
> than on the script-driven use-case. The original proposer, Nicholas, agreed
> in an earlier message that he's really more concerned with script-driven
> functionality than markup driven functionality. And I completely agree with
> that assertion.
>
> In fact, I'd go so far as to say that the use-case for separating script
> loading from its parsing/execution phase (and thus being able to
> control/trigger when that phase occurs, later) is 99% driven by the
> script-loaders use-case. Script loaders by and large do not use markup
> semantics to accomplish their tasks (because most of them do not use
> document.write("<script...."); to load scripts)
>
> So, if we consider the spirit of the original proposal, we should examine
> it in the proper context (the vast majority use-case), which is script
> elements being created from script logic rather than markup.
>
> Given that proper context, the proposal becomes something like:
>
> 1. Give a dynamic script element a "noExecute" property (a boolean
> property, defaults to false, can be set to true)
> 2. Give a dynamic script element an "execute()" function which executes a
> script that has been "deferred" by the "noExecute" property.
>

This is precisely what I described.  (Obviously, the "noexecute" flag would
be exposed both as a DOM attribute and a script property.)

The problem with *that* phrasing of the proposal (compared to the
> "readyState" preoloading I'm advocating) is:
>
> 1. It asks for two new unprecedented additions to the script element
> specification. The other proposal asks to take the existing spec wording and
> change it from a "may" to a "must" (from suggestion to requirement).
>

It would take more than that.  It wouldn't make sense to put a "must"
requirement for "must begin loading data when the src attribute is set, even
if the script element has not been added to the document" inside a list of
steps that only happens when the script has been added to the document.

It would also require adding readyState to the script element spec; it's
currently only defined for document and media.  It would require specifying
onreadystatechange, which is only currently defined for document (and not
media, I believe).  The "error" event would need to be updated to reflect
the fact that it can fire when the script element isn't in the DOM tree if
the fetch fails; I think IE's behavior of firing that event in this case is
currently off-spec.

I'm not against this approach fundamentally; I'm just pointing out that it's
not a one-word "s/may/must/" change.  I do believe noexecute is cleaner and
more powerful: it allows executing a fetched script synchronously, which
would make using this transparently behind a black-box script API easier.
With readyState, if you call a function and it needs an interface that isn't
yet loaded, it needs to trigger execution (by adding the script to the
document) and return with "try again later", which is restrictive.  I'd also
expect most of the engine work needed to support noexecute is already
implemented for defer (a question for implementors, of course).

In any case, I'm not too worried about either approach; my main goal was
getting back to discussing interfaces, since it seemed like most of the
debate was tangental--the main relevant point seems to be guaranteeing
browsers retain the freedom to parse scripts at whatever point they want
(during load, after load, during idle time, or upon execution), which I
think everyone is strongly agreed on.

-- 
Glenn Maynard