> 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 <dim...@chromium.org> wrote: > > > On Mon, Sep 14, 2009 at 4:41 AM, Ian Hickson <i...@hixie.ch> wrote: > >> On Mon, 7 Sep 2009, Dimitri Glazkov wrote: >> > On Sat, Aug 29, 2009 at 2:40 PM, Ian Hickson<i...@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. >
