[whatwg] Criticism of pushState (was Global Script proposal)
dglazkov at chromium.org
Tue Sep 8 10:20:24 PDT 2009
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
>> 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
Ok, this sounds reasonable.
More information about the whatwg