[whatwg] Global Script proposal.

[Dmitry Titov]

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/495e3e9c/attachment-0002.htm>