[whatwg] Installed Apps

On Wed, Jul 29, 2009 at 1:53 PM, Jeremy Orlow <jorlow at chromium.org> wrote:

> On Wed, Jul 29, 2009 at 11:43 AM, Michael Davidson <mpd at google.com> wrote:
>
>> On Wed, Jul 29, 2009 at 11:38 AM, Tab Atkins Jr.<jackalmage at gmail.com>
>> wrote:
>> > On Wed, Jul 29, 2009 at 1:34 PM, Michael Davidson<mpd at google.com>
>> wrote:
>> >> With a hidden page that's accessible to all Google Finance visible
>> >> pages, they could share a connection to the server. Even if the hidden
>> >> page is closed when the last Google Finance page is closed, this is a
>> >> better situation than we currently have.
>> >
>> > Can't SharedWorkers do that right now?  If all you're doing is polling
>> > for data, it seems like you don't need all the extra stuff that these
>> > various proposals are offering.
>>
>> It's my contention that frequently large web apps are doing more than
>> just polling for data. They're trying to maintain complex data
>> structures that they pass up to the UI. The programming model of
>> SharedWorkers makes this difficult. Take the chat client in Gmail, for
>> example. It's much more complex than passing stock quotes from a
>> worker to the UI.
>
>
> I understand that this isn't helpful for existing web apps like Gmail, but
> I think a MVC type model will work pretty nicely with shared workers.  It's
> just the transition phase that's going to be painful.
>
> This idea of a hidden page just seems like a big hack to support today's
> applications.  If it were adapted into the spec, I think 5 years from now
> we'd be very sorry that it was.
>

I disagree. The proposal plays to the strenths of the web platform.

HTML parsing, layout, and rendering is very optimized, much more so than
programmatic HTML DOM manipulation. The incorporation of stateful script
contexts within each page considerably slows page loading. As navigations
occur, that statefullness has to be reconstructed from scratch. In addition
to creating and populating a new script context with the <script> itself,
this often involves reconstructing data the script operates on. So
additional server roundtrips and desrializing into js objects. With the
introduction of local storeage and databases, augment the server roundtrips
with the reading of those local repositories and deserializing into js
structures.

The sharedContext / backgroundPage provides a means to cut out completely
the need to reconstruct that JS world on each page navigation.

I really like the proposal... its elegant... (and more generally applicable,
and easier to use than fully asyn workers).

<hyperbole>
I think 5 years from now, people will be wondering why it was ever done
otherwise.
</hyberbole>



>
> The other APIs we've been talking about that satisfy the requirements that
> were originally broken out by Drew seem like much more sustainable
> solutions.
>
> J
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090729/7ff06c20/attachment.htm>

Received on Wednesday, 29 July 2009 15:02:52 UTC