[whatwg] Proposal for separating script downloads and execution
steve at souders.org
Thu Feb 3 14:31:20 PST 2011
This behavior is important to the next generation of web apps,
especially for mobile.
- download the bytes of JS now
- execute later when specified (eg, when the user initiates a feature)
I've talked to several development teams that have already deployed this
functionality but it is complex to build & maintain, and often does not
work across even the most popular browsers. We need to lower the bar to
developers and raise the standardization of behavior across web clients.
I'd like to see this move forward.
On 2/1/2011 9:53 AM, Nicholas Zakas wrote:
> *Problem Statement:*
> a regular <script> tag, the UA waits for download and then waits for
> execution. The defer attribute helps by not blocking on download and
> deferring execution until later but preserves execution order; the
> async attribute helps by not blocking on download but does block on
> execution (the timing of which cannot be controlled) and does not
> preserve order.
> Each of the existing solutions shifts around when download and
> execution happens by giving developers control over when the download
> occurs but only minimally when execution happens. As a result,
> developers have created ever more ingenius/fragile solutions to allow
> the separation of script downloads and execution. Examples:
> 1. Preloading JS without execution
> execution it, as a cache-warming technique.
> 2. ControlJS (http://stevesouders.com/controljs/) by Steve Souders,
> which extends Stoyan's model to allow on-demand execution of scripts.
> to enable download without execution and then execution on-demand.
> The ability to separate download and execution is a trend that has not
> only emerged, but continues to be explored. There are problems with
> the previous solutions, the biggest of which (in the case of #1 and
> #2) is the reliance on the browser caching behavior which may, in some
> instances, lead to a double download of the same script. It would be
> preferable for a standardized approach to achieve these goals.
> *Overview of Proposal:*
> Add a new attribute to the <script> called noexecute (for lack of a
> better term) that instructs the browser to download the script but do
> not execute it. Developers must manually execute the code by calling
> an execute() method on the script node. Simple example:
> var script = document.createElement("script");
> script.noexecute = true;
> script.src = "foo.js";
> *Proposal Details:*
> Because there are a lot of nuanced changes to <script> as a result of
> this proposal, I've written up a full description here:
> I'd love some feedback on whether or not this a) makes sense and b) is
> Commander Lock: "Dammit Morpheus, not everyone believes what you believe!"
> Morpheus: "My beliefs do not require them to."
More information about the whatwg