[whatwg] Global Script proposal.

[Michael Nordman]

> to say that every app should necessarily be a single complex AJAX page
morphing itself.> That in itself may be a serious limitation.

Agree very much so.

On Tue, Sep 15, 2009 at 5:54 PM, Dmitry Titov <dimich at chromium.org> wrote:

>
>
> On Mon, Sep 14, 2009 at 4:41 AM, Ian Hickson <ian at hixie.ch> wrote:
>
>> On Mon, 7 Sep 2009, Dimitri Glazkov wrote:
>> > On Sat, Aug 29, 2009 at 2:40 PM, Ian Hickson<ian at hixie.ch> wrote:
>> > >> Another case is an application that uses navigation from page to page
>> > >> using menu or some site navigation mechanism. Global Script Context
>> > >> could keep the application state so it doesn't have to be
>> > >> round-tripped via server in a cookie or URL.
>> > >
>> > > You can keep the state using sessionStorage or localStorage, or you
>> > > can use pushState() instead of actual navigation.
>> >
>> > First off, sessionStorage and localStorage are not anywhere close to
>> > being useful if you're dealing with the actual DOM objects. The JS code
>> > that would freeze-dry them and bring back to life will make the whole
>> > exercise cost-prohibitive.
>>
>> Indeed. I don't see why you would want to be keeping nodes alive while
>> navigating to entirely new documents though.
>>
>>
>> > But more to the point, I think globalScript is a good replacement for
>> > the pushState additions to the History spec. I've been reading up on the
>> > spec an the comments made about pushState and I am becoming somewhat
>> > convinced that pushState is confusing, hard to get right, and full of
>> > fail. You should simply look at the motivation behind building JS-based
>> > history state managers -- it all becomes fairly clear.
>> >
>> > The best analogy I can muster is this: pushHistory is like creating
>> > Rhoad's-like kinetic machines for moving furniture around the house in
>> > an effort to keep the tenant standing still. Whereas globalScript
>> > proposes to just let the poor slob to walk to the chest to get the damn
>> > socks.
>> >
>> > My big issue with pushHistory is that it messes with the nature of the
>> > Web: a URL is a resource you request from the server. Not something you
>> > arrive to via clever sleight of hand in a user agent. So, you've managed
>> > to pushState your way to a.com/some/path/10/clicks/from/the/home/page.
>> > Now the user bookmarks it. What are you going to do know? Intuitively,
>> > it feels like we should be improving the user agent to eliminate the
>> > need for mucking with history, not providing more tools to encourage it.
>>
>> The only criticism of substance in the above -- that pushState() lets you
>> change the URL of the current page when you change the page dynamically --
>> is pretty much the entire point of the feature, and I don't understand why
>> it's bad. I certainly don't want to require that every pan on Google Maps
>> require a new page load.
>>
>>
>> On Tue, 8 Sep 2009, Anne van Kesteren wrote:
>> >
>> > If JavaScript can be somehow kept-alive while navigating to a new page
>> > within a single domain, be in control of what is displayed and without
>> > security issues and all that'd be rather cool and also solve the issue.
>>
>> This seems substantially less preferable, performance-wise, than having a
>> single Document and script, using pushState().
>>
>
> It depends, right? That single Document+script would have to have all the
> resources and code to be able to morph itself into all the possible app
> states, preventing benefits of lazy-loading. Or, to be more efficient, it
> should load additional resources on demand, which looks very close to
> navigation to subsequent pages.
>
> Today, those natural navigations from page to page are prohibitively
> expensive, even with caches - they are equivalent to serialization of
> everything into some storage, terminating the app, then launching the app
> again, loading state from storage and/or cloud, setting up the UI etc. So
> AJAX is the only real alternative today, although it comes with complex
> pages that have to construct UI dynamically.
>
> History management API is great, but it is also an overkill to say that
> every app should necessarily be a single complex AJAX page morphing itself.
> That in itself may be a serious limitation.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090915/b458eb8c/attachment-0002.htm>