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

[Dimitri Glazkov]

On Tue, Sep 8, 2009 at 9:21 AM, Justin Lebar<justin.lebar at gmail.com> wrote:
> To be clear, I'm not suggesting that pushState obviates the need for
> global script.  My point is that pushState is useful in its own right,
> with our without global script.
>
> Without pushstate, you can't make a non-hash navigation without
> hitting the network.  Even if you're clever and store all of JQuery
> and your whole DOM in global storage, if you want to change the
> pre-hash part of the URI, you need to load a new page.
>
> Imagine Google Maps trying to update the URI to match your current
> location as you pan around the map.  Right now, they could update the
> hash as you panned.  With pushstate, they could update the URI in an
> arbitrary way.  With global state, they'd have to load a new page
> every time you panned.  That's obviously worse, and probably not even
> an option.

Ah, that's a use case I haven't thought of -- although now that you
mentioned it, I vaguely remember reading about it. You're right, this
one looks like a valid and appropriate use of pushState.

>> Then why the heck would we want to come up with a fancier way to
>> provide hash-navigation?
>
> Perhaps the point is to do something which works like hash-navigation,
> but to the user, looks like real navigation.  Imagine Bugzilla using
> pushstate to navigate between bugs, but keeping the familiar
> show_bug.cgi?id=1234 URI.  I don't pretend that the code necessary to
> make this work would be easy to write, but it's certainly no more
> difficult than changing the hash, and the resulting URLs are much
> nicer.
>
>> Once you introduce pushState, you deviate from the normalcy -- now you
>> can have a URL in the address bar that the user agent hasn't requested
>> from the server.
>
> Again, this is just what happens when you're at your Gmail Inbox and
> click a link to http://mail.google.com/mail/#Drafts.  You now have a
> URL in the address bar that the UA hasn't requested from the server.
> pushState improves this -- at least now the URL you didn't request
> from the server looks like one which you plausibly might have
> requested from the server.

I guess what I was trying to say is that the server is completely
blind to hashes, so both http://mail.google.com/mail/#Drafts and
http://mail.google.com/mail/#inbox are the same URL from its
perspective: http://mail.google.com/mail/, and that has been the case
since the browsers were born (I think).

>> I really don't care about how the URLs
>> look. I just want the Web development to be easier. And in my humble
>> opinion, building a request controller in JS and essentially a whole
>> alternative reality navigation system using hashes is not.
>
> If you don't care how URLs look or if you don't mind making a network
> request when you navigate a page, then don't use the feature!  A lot
> of people do care about one or both of those things, though, and
> they're willing to go through the pain of developing these
> alternative-reality navigation systems.
>
> PushState does not subsume global script.  For many applications,
> storing the whole DOM in global script would get you sufficiently fast
> navigations -- I agree.
>
> But global script does not subsume pushState, either.  Even with
> global script, you can't change the URI arbitrarily without navigating
> the page.  Panning on Google Maps and changing the referer sent to a
> page are two instances where extra page navigations might be
> unacceptable.

Ok, this sounds reasonable.

:DG<