Re: Proposal for separating script downloads and execution

On Wed, 09 Feb 2011 00:31:59 -0000, Kyle Simpson <getify@gmail.com> wrote:

> ?> Isn't this just a quality of implementation issue?
>
> No, frankly it isn't. No matter how good the implementation of the  
> JavaScript engine on mobile, the mobile device will always be much more  
> limited in processing power than a desktop browser environment.

By quality of implementation I mean the fact that script parsing *can* be  
non-blocking.

As far as I understand if you use <script async>, then the spec already  
allows browsers to download *and parse* the script asynchronously (syntax  
tree is not dependent on DOM state, so parsing can be done without any  
interaction with the page or UI).

The only time when spec requires browsers to block UI is during execution  
of the script itself. However, if the script you're loading doesn't  
immediately do any heavy work in top level (global) scope (i.e. all code  
is in functions), then it shouldn't cause perceptible delay, even on  
today's hardware.

e.g. if you have file:

function make_the_script_run(){
     // lots of stuff
     // megs of code
     // thousands of definitions
};

and load it with <script async>, then all the heavy bits can be (in good  
quality implementation) parsed asynchronously without any adverse effect  
on UI (other scripts and UI events can be executed while this one is still  
parsing). Execution of top level of that script will not execute huge  
amount of code, it will only hook up one already-parsed function in global  
scope, which is very quick.

I wouldn't want to add API to the platform that only solves implementation  
issue in today's (and near-future) implementations, because the API is  
going to outlive them. In near future you'll have to use workarounds  
anyway, because it will take some time before feature is specced,  
implemented, ships with next OS and all users upgrade their OS/phones.

-- 
regards, Kornel

Received on Wednesday, 9 February 2011 22:48:21 UTC