[whatwg] Proposal for separating script downloads and execution

On 2/8/11 11:04 PM, Kyle Simpson wrote:
>>> 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.
>>
>> That's not what the question was about.
>
> The context of the original assertion is clearly about optimizing things
> in mobile (like the Gmail mobile team did) by deferring
> parsing/execution of scripts from happening during initial page-load
> (when the mobile device's CPU is already taxed). Then, the question is
> asked "is that just a quality of implementation issue".
>
> And so I think my response is quite on target and germane.

If that's what you were responding to, then I think your response is 
simply incorrect.  There's nothing whatsoever that requires that a web 
browser freeze up its UI while parsing a script.  If it does so, it's a 
quality of implementation issue, pure and simple.

> I'm asserting that the solution to the problem can't just be "the mobile
> implementation needs to be more efficient (higher quality)", because the
> issue is not really about the JavaScript engine, but the limitations of
> the device it's running on.

You don't need to be more efficient to avoid freezing the UI.  You just 
have to not do the parsing work in a single shot on the main thread. 
You can either break it up (cooperative multitasking, effectively), or 
put it on a separate thread (preemptive multitasking).  None of that is 
limited by the hardware of the device, really.

> We're saying we need a feature to assist in working around such issues,

And I'm saying that I just don't want this feature getting in the way of 
browsers improving.  As long as it doesn't, it's fine by me.

>> The thing is, if a browser is idle, why shouldn't it go ahead and parse
>> the script?
>
> In most cases, a web author trying to second-guess a browser is not a
> fruitful endeavor. However, browsers are not always perfect in their
> behavior and decision making. If a web author needs to do something that
> they then observe is causing issues on a slow mobile device, in general,
> why shouldn't they have a little more control over how/when it happens?

If that was a non-rhetorical question, then because authors exercising 
such control tend to create sites that only "work" in one particular 
version of one particular browser.  Especially so in cases like this 
where the thing being frobbed by the author can't even be measured directly.

Now you may be right that authors who really want to screw up like that 
will just do browser-sniffing hacks of various sorts and still screw up. 
  But it's not clear to me that we need to make the barrier to shooting 
yourself in the foot lower as a result....

> I am not sure that I'm asking specifically to give a web author the
> ability to "forbid" a browser from doing something. I think I'm asking
> for something slightly less militant. I'm asking for the web author to
> have a way to opt-out of normal default behavior (which is that a script
> downloads, parses, and executes all together practically without
> interruption)

That's not quite true; the download is completely independent of the 
parse and execute in pretty much any modern browser.

> and instead have some way to pause that process after
> download and then resume it at a later time.

In other words, forbid the browser to start parsing the script, right? 
How would you tell whether a browser implemented this as specified?

> IF the browser chose to implement this feature request in such a way
> that they actually break it into 3 distinct steps, and the middle step
> (the "parsing") they reserve the right to do at any time, but they still
> give us the ability to indicate when we want execution to occur separate
> from the loading, I think that's a reasonable compromise here.

OK.  I definitely agree that better user control over when script 
_executes_ is a good idea.  Sounds like we're on the same page there.

-Boris

Received on Tuesday, 8 February 2011 20:26:47 UTC