[whatwg] Criticism of pushState (was Global Script proposal)

PushState is also useful for e.g. making sure that the "referer" header
contains useful information. Not to say that there aren't other ways to
accomplish that, but it is one thing that Global Context won't give you.

2009/9/7 Justin Lebar <justin.lebar at gmail.com>

> > Dimitri Glazkov wrote:
> > But more to the point, I think globalScript is a good replacement for
> > the pushState additions to the History spec.
>
> I'm not sure I agree.  pushState lets you change the URI very quickly,
> without doing any kind of navigation at all.  To emulate a pushSate
> with globalScript, you'd have to save and restore the whole document,
> and the browser would still have to do at least one network request,
> unless you were only changing the hash of the URI.
>
> > 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.
>
> Could you elaborate on these points?  It seems to me that pushState
> attacks a specific problem and delivers a simple solution which is
> much better than the current workarounds (using the URL's hash to
> identify a page and store state).  Yes, it's nontrivial to develop an
> AJAX app which uses pushState and works correctly with bookmarking and
> page refreshes.  On the other hand, pushState makes this a lot easier
> than it would be otherwise.
>
> > 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.
>
> Like it or not, this ship has already sailed.  When I load Gmail, I'm
> taken to https://mail.google.com/mail/#inbox, but my browser never
> sends "#inbox" to the server as part of the HTTP request.  Pandora and
> Facebook do something like this too.  Perhaps the new intuition is
> that a URL tells you how to get back to where you were.
>
> > 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?
>
> When reading this message in Gmail, my browser shows that I'm at
> https://mail.google.com/mail/#label/WhatWG/{guid} .  If I bookmark
> this page and go back to it, Gmail takes me back to this exact
> message.  There's no actual resource named #label/WhatWG/{guid} on
> Google's servers, but the URL I bookmarked is sufficient to identify
> where I was, and Gmail's servers were intelligent enough to take me
> there.
>
> Maybe you think that Gmail's URLs should name "real" resources; maybe
> they should look like
> https://mail.google.com/mail.cgi?label=WhatWG&message={guid} or
> something.  I'm not convinced this is better, but even if it suits
> you, pushState still helps you navigate between mail.cgi?label=WhatWG
> and mail.cgi?label=Drafts without a page refresh.
>
> I think pushState API is really useful, but what do I know?  We're
> going to land it in Firefox trunk Real Soon Now, so developers and
> members of this list will be able to play with it and decide for
> themselves whether it's the right API to solve the problem at hand.
>
> -Justin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090907/29029717/attachment.htm>

Received on Monday, 7 September 2009 20:05:28 UTC