[whatwg] Global Script proposal.

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().

The pushState() model is basically fixing the AJAX model to work right; it 
seems like a good thing to me.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 14 September 2009 04:41:36 UTC