Hacker News new | ask | show | jobs
by michaelvillar 3450 days ago
They could use `pushState` to change the query without reloading the page?
2 comments

They could if they were building it now. IE got pushState support in IE 10 in 2012.

The hash state has been there since Instant Search was launched in 2010.

Graceful degradation/progressive enhancement is a thing, though.
The amount of money Google makes supporting older browsers is most likely measured in billions.

Not to mention, why fix something that isn't broken? There are cases for it, but it's roughly the same tech that it was 4 years ago. What would they gain by spending developer time on it?

Perfect. They definitely don't need optimization for search engines, which is probably the most important reason to a clean URL.
Exactly. You are someone who gets it.
I suspect they spend a ton of developer time. It is their #1 source of income. What they won't do is releasing it unless it is 99.9% certain that it yields an improvement.
Yes, but in this case the benefits of the enhancement are small enough that Google may have decided that consistent behaviour was more desirable.
Consistent and long-lasting support is a thing too.

Rare on today's web, but still a thing.

Would that not remove the possibility for sharing or manually editing the URL? (I'm asking because I don't know how much cool stuff pushState can do.)
No, but it makes shared links less inefficient. If you share a URL like this, the server will not receive the hash on the initial request, so the js client will have to do the search as a second request after the page load. The reality is that most users will never even notice because it's still fast.

Manually editing the link causes that same fetch-render-refetch flow.

Edit: Oh, you were asking about pushstate. No, that specifically fixes the problem with the double fetch, so long as the server side and client side do the right thing to make the user see the same page for the same URL.

Pushstate just lets the JS client modify the URL without triggering a page reload, so the client can change the actual query param instead of the hash.

Not unless the server doesn't interpret the URL the same way.
The fragment of a URL is not sent to the server as part of an HTTP request