Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Why does Google put the query in the URL hash instead of query string?

news.ycombinator.com

Post reply on HN
Print view View original

51–60 of 71 posts

Re: Ask HN: Why does Google put the query in the URL hash instead of query string?

#51

Post by benbayard »

oneeyedpigeon wrote: post #48
Illniyar wrote: post #20

As others have said, it's to show the data without reloading the page. They could of course do it without actually adding anything to the url - but then it won't be bookmarkable (and refresh would get you back to a page without results). They could use the new history pushstate api, but then: 1. it won't work in older browsers 2. if they wanted it to work in older browsers they'll have to shim it (which ends up using…

Why would google.com/?q=search-term not be bookmarkable?

OP is saying if you do not update the URL between searches it will not be bookmarkable. Not, if you update the URL with the actual search term in a query string. The reason they do not update the URL query string itself is due to browser incompatibility. Doing it this way they get support for all browsers released after 2010, whereas they could only support IE 10 or greater by using History.pushState

Re: Ask HN: Why does Google put the query in the URL hash instead of query string?

#52

Post by currysausage »

jasonkester wrote: post #37

I had always assumed they did this for financial reasons. The hash won't be sent along as part of the referrer header, so the search query won't be available to 3rd party analytics. The only way to track search queries is to use Google's own analytics, which can correlate queries to traffic since it's watching both ends of the handoff. The technical explanation discussed in this thread is certainly valid. But it only…

If you click a search result, you still have a google.com/url?… redirector in between, so hiding the search term in the hash wouldn't really be necessary.

Re: Ask HN: Why does Google put the query in the URL hash instead of query string?

#53

Post by jessaustin »

shezi wrote: post #41
jasonkester wrote: post #37

I had always assumed they did this for financial reasons. The hash won't be sent along as part of the referrer header, so the search query won't be available to 3rd party analytics. The only way to track search queries is to use Google's own analytics, which can correlate queries to traffic since it's watching both ends of the handoff. The technical explanation discussed in this thread is certainly valid. But it only…

There are good technical explanations of the behaviour in the comments. And the observed behaviour is that only subsequent queries get put in the hash instead of the query. The why is also addressed by the comments (IE only got support for pushState after the solution was already built). Besides, for a long time, Google added intermediate pages when you clicked through a search result, adding the appropriate referrer…

If that's "malice" then everything Google does is malicious. There's nothing wrong with doing something for multiple reasons. It seems exceedingly unlikely that "now we can control Referer" never came in search product discussions.

Re: Ask HN: Why does Google put the query in the URL hash instead of query string?

#54

Post by lloeki »

wmil wrote: post #23
michaelvillar wrote: post #16

Earlier quoted context omitted.

They could use `pushState` to change the query without reloading the page?

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.

Re: Ask HN: Why does Google put the query in the URL hash instead of query string?

#55

Post by bpicolo »

lloeki wrote: post #54
wmil wrote: post #23

Earlier quoted context omitted.

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?

Re: Ask HN: Why does Google put the query in the URL hash instead of query string?

#56

Post by untog »

lloeki wrote: post #54
wmil wrote: post #23

Earlier quoted context omitted.

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.

Yes, but in this case the benefits of the enhancement are small enough that Google may have decided that consistent behaviour was more desirable.

Re: Ask HN: Why does Google put the query in the URL hash instead of query string?

#57

Post by MiddleEndian »

notzorbo3 wrote: post #28
piyush_soni wrote: post #26

Earlier quoted context omitted.

Yes, and if you're using Firefox, you can this with the knowledge of its Smart Keywords to create super quick shortcuts! https://support.mozilla.org/en-US/kb/how-search-from-address... For example, I directly go to Wikipedia's page on "India " by typing wp India in my address bar using these search keywords, or search images of birds on google by typing gi birds in it. (There's a rather cumbersome way to do the same…

It's not that cumbersome in Chrome. Right click the URL bar -> "Edit search engines" -> Find the search engine you'd like to easily search, double click the second column and enter a keyword for it. For example, for wikipedia, I have "wp" as a keyword. In the URL bar, you can just type "wp " and you can search wikipedia.

The level of customization offered in Firefox is a nice benefit though, as you can add a wildcard to any portion of a URL.

I have some specific shortcuts like wdir (walking directions from my home address) and some shortcuts that allow me to quickly jump to subsections of specific sites.

Re: Ask HN: Why does Google put the query in the URL hash instead of query string?

#58

Post by adamdonahue »

bpicolo wrote: post #55
lloeki wrote: post #54

Earlier quoted context omitted.

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?

Exactly. You are someone who gets it.

Re: Ask HN: Why does Google put the query in the URL hash instead of query string?

#60

Post by dpark »

thomasahle wrote: post #38
michaelvillar wrote: post #16

Earlier quoted context omitted.

They could use `pushState` to change the query without reloading the page?

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.

Post reply on HN