[whatwg] Proposal for separating script downloads and execution

[Nicholas Zakas]

I don't think readyState as Kyle describes is an appropriate candidate mechanism because it's not an actual indicator that the functionality exists. The only thing you can really be sure of if readyState is "uninitialized" is that the script element supports readyState. The fact the only browser supporting this presently is the same one that supports the desired behavior is a happy coincidence. There's nothing about the presence of readyState in general or the particular value that gives any explicit indication that adding the script node will result in a particular download/execute behavior. You may as well test another well-known IE property like (typeof ActiveXObject == "object").

The thing I like about my proposal (with of course, the obvious bias that it is my proposal), is that it's easy and unconfusing to determine if the browser supports delayed execution by testing for the presence of script.execute. 

Even if my solution isn't the best one, I do believe the best one needs to follow this model of explicit feature detection.



-Nicholas
 
______________________________________________
Commander Lock: "Dammit Morpheus, not everyone believes what you believe!"
Morpheus: "My beliefs do not require them to."

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Steve Souders
Sent: Thursday, February 03, 2011 2:31 PM
To: whatwg at whatwg.org
Cc: Nicholas Zakas; Jonas Sicking; Tony Gentilcore
Subject: Re: [whatwg] Proposal for separating script downloads and execution

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.

-Steve


On 2/1/2011 9:53 AM, Nicholas Zakas wrote:
>
> *Problem Statement:*
>
> Loading JavaScript onto a page poses several performance issues. With 
> 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 
> (http://www.phpied.com/preload-cssjavascript-without-execution/) by 
> Stoyan Stefanov, which describes how to download JavaScript without 
> 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.
>
> 3. Gmail putting JavaScript in comments and then parsing later 
> (http://googlecode.blogspot.com/2009/09/gmail-for-mobile-html5-series-reducing.html) 
> 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";
>
> document.head.appendChild(script);
>
> //later
>
> script.execute();
>
> *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:
>
> https://docs.google.com/document/d/1s8_iRr1TcwcDtShgfuGThapwZtVXItymw5zc16D0Pz8/edit?hl=en&authkey=CNbDlo8J 
> <https://docs.google.com/document/d/1s8_iRr1TcwcDtShgfuGThapwZtVXItymw5zc16D0Pz8/edit?hl=en&authkey=CNbDlo8J>
>
> I'd love some feedback on whether or not this a) makes sense and b) is 
> feasible.
>
> -Nicholas
>
> ______________________________________________
>
> Commander Lock: "Dammit Morpheus, not everyone believes what you believe!"
>
> Morpheus: "My beliefs do not require them to."
>