W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2011

[whatwg] Proposal for separating script downloads and execution

From: Nicholas Zakas <nzakas@yahoo-inc.com>
Date: Tue, 8 Feb 2011 12:32:50 -0800
Message-ID: <B66541E954ECF146AD8CA69D34A283FF282228A979@SP2-EX07VS02.ds.corp.yahoo.com>
Web Workers don't adequately solve this problem because:

1) There is no DOM. If the script being loaded and execute requires interaction with the DOM, it will just error out.

2) Assuming that #1 doesn't get in your way because you're not interacting with the DOM, you still have the potential for a double-download if caching headers are not set correctly.

#2 is a common problem with existing solutions as well, and one that I wanted to address with my proposal.

-N

-----Original Message-----
From: whatwg-bounces@lists.whatwg.org [mailto:whatwg-bounces@lists.whatwg.org] On Behalf Of John Tamplin
Sent: Tuesday, February 08, 2011 11:57 AM
To: Anne van Kesteren
Cc: Steve Souders; Jonas Sicking; whatwg at whatwg.org; Henri Sivonen; Nicholas Zakas; Tony Gentilcore
Subject: Re: [whatwg] Proposal for separating script downloads and execution

On Tue, Feb 8, 2011 at 11:35 AM, Anne van Kesteren <annevk at opera.com> wrote:

> They have a way to download and execute scripts. So if the UI thread has a
> minimal script that takes care of creation of workers and creates a tunnel
> for DOM modifications you could theoretically be all set. (I have not
> followed this entire thread though, so apologies if I missed something.)
>

Is every developer having to write their own proxy to do DOM manipulations
on behalf of a Web Worker really the model you want to push here?  I know
everything looks like a nail when what you have is a hammer, but surely we
can do better than that.  I suspect the hack of downloading a commented
script and then evaluating it when needed is both easier to implement and
faster overall than such a solution, especially if the commented source is
stored in app cache.

Note that in the blog they mention that on an iPhone 2.2 parse time was 2.6
seconds for 200k of JS, compared to 240ms to just download it in a comment
-- the mobile network isn't the issue, it is the JS parser in mobile
browsers.

-- 
John A. Tamplin
Software Engineer (GWT), Google
Received on Tuesday, 8 February 2011 12:32:50 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:30 UTC