<br><br><div class="gmail_quote">On Mon, Sep 14, 2009 at 4:41 AM, Ian Hickson <span dir="ltr"><<a href="mailto:ian@hixie.ch" target="_blank">ian@hixie.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div>On Mon, 7 Sep 2009, Dimitri Glazkov wrote:<br>
> On Sat, Aug 29, 2009 at 2:40 PM, Ian Hickson<<a href="mailto:ian@hixie.ch" target="_blank">ian@hixie.ch</a>> wrote:<br>
> >> Another case is an application that uses navigation from page to page<br>
> >> using menu or some site navigation mechanism. Global Script Context<br>
> >> could keep the application state so it doesn't have to be<br>
> >> round-tripped via server in a cookie or URL.<br>
> ><br>
> > You can keep the state using sessionStorage or localStorage, or you<br>
> > can use pushState() instead of actual navigation.<br>
><br>
> First off, sessionStorage and localStorage are not anywhere close to<br>
> being useful if you're dealing with the actual DOM objects. The JS code<br>
> that would freeze-dry them and bring back to life will make the whole<br>
> exercise cost-prohibitive.<br>
<br>
</div>Indeed. I don't see why you would want to be keeping nodes alive while<br>
navigating to entirely new documents though.<br>
<div><br>
<br>
> But more to the point, I think globalScript is a good replacement for<br>
> the pushState additions to the History spec. I've been reading up on the<br>
> spec an the comments made about pushState and I am becoming somewhat<br>
> convinced that pushState is confusing, hard to get right, and full of<br>
> fail. You should simply look at the motivation behind building JS-based<br>
> history state managers -- it all becomes fairly clear.<br>
><br>
> The best analogy I can muster is this: pushHistory is like creating<br>
> Rhoad's-like kinetic machines for moving furniture around the house in<br>
> an effort to keep the tenant standing still. Whereas globalScript<br>
> proposes to just let the poor slob to walk to the chest to get the damn<br>
> socks.<br>
><br>
</div><div>> My big issue with pushHistory is that it messes with the nature of the<br>
> Web: a URL is a resource you request from the server. Not something you<br>
> arrive to via clever sleight of hand in a user agent. So, you've managed<br>
> to pushState your way to <a href="http://a.com/some/path/10/clicks/from/the/home/page" target="_blank">a.com/some/path/10/clicks/from/the/home/page</a>.<br>
> Now the user bookmarks it. What are you going to do know? Intuitively,<br>
> it feels like we should be improving the user agent to eliminate the<br>
> need for mucking with history, not providing more tools to encourage it.<br>
<br>
</div>The only criticism of substance in the above -- that pushState() lets you<br>
change the URL of the current page when you change the page dynamically --<br>
is pretty much the entire point of the feature, and I don't understand why<br>
it's bad. I certainly don't want to require that every pan on Google Maps<br>
require a new page load.<br>
<div><br>
<br>
On Tue, 8 Sep 2009, Anne van Kesteren wrote:<br>
><br>
> If JavaScript can be somehow kept-alive while navigating to a new page<br>
> within a single domain, be in control of what is displayed and without<br>
> security issues and all that'd be rather cool and also solve the issue.<br>
<br>
</div>This seems substantially less preferable, performance-wise, than having a<br>
single Document and script, using pushState().<br></blockquote><div><br></div><div>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. </div>
<div><br></div><div>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.</div>

<div><br></div><div>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.</div>
</div>