4 ms·

> * This is using a plain hash instead of a hash bang, > which, correct me if I'm wrong, means sub pages are > not hit by search engines. Fortunately

> * This is using a plain hash instead of a hash bang, > which, correct me if I'm wrong, means sub pages are > not hit by search engines. Fortunately, you're wrong about hashbangs. They were a temporary hack to allow the GoogleBot to index Ajax-driven pages before the HTML History API existed. Because of New Twitter, many sites have cargo-culted the hashbang without implementing the required "escaped_fragment" functionality on the server-side to make it actually work. It's the web developer equivalent of an SEO rain dance. Please don't use hashbangs in 2011. Use pushState() if you're a public-facing site that needs to be indexed by search engines.

jsdalton 15y ago
TIL. Thanks for disabusing me of the notion that this is a good idea. I have seen it used in numerous places which is what led me to assume it was the "right" way. I assume, then, that the developers of this site could have used pushState() instead of the hash? I mean, I assume that Backbone encourages this style if the developer makes use of it.
- jashkenas 15y ago
  Backbone encourages pushState() if you can swing it -- you'll need to implement every client-side route as a server-side page as well ... so it's not possible if you're hosted in an inflexible environment. Backbone falls back to hashes for browsers that don't support the API, and transparently converts URLs between the two. But regular hashes ("#") are fine for internal single-page-apps that don't need google indexing -- of which the majority of Backbone projects probably are. It's just the hashbang "#!" that's a particular pet peeve of mine ;)
huhtenberg 15y ago
Can you elaborate? I don't follow how pushState (being a javascript function) replaces the need for _escaped_fragment contraption for letting crawlers fetch page snapshots in a specific state.
- Skalman 15y ago
  With pushState you can actually push a URL without the hash. It looks like I'm GETting /about, while it's really just / with the content of /about fetched via AJAX. A HTTP GET /about should of course give the same content as the AJAX version.
  - huhtenberg 15y ago
    Right, but this still doesn't alleviate the need for "prerendering" specific pages for the crawler, which is the most tedious part of the whole thing. In other words, when a crawler requests /about, it should be getting a fully-formed About page with the content already in place, and not a bare container that ajax'es the content on page load (which is how most of pageless sites work).
    - Skalman 15y ago
      Yeah - that sucks, but is actually also necessary for optimal performance for users as well. I don't think it's excusable to have two HTTP requests for page content. (and hash bangs are just as bad when loaded directly)
dfabulich 15y ago
This is mostly right, but there's a very important exception: IE doesn't support pushState. If IE users are an important part of your user base, you should use hashbangs with _escaped_fragment_, but only on IE.

jsdalton 15y ago

TIL. Thanks for disabusing me of the notion that this is a good idea. I have seen it used in numerous places which is what led me to assume it was the "right" way. I assume, then, that the developers of this site could have used pushState() instead of the hash? I mean, I assume that Backbone encourages this style if the developer makes use of it.

jashkenas 15y ago
Backbone encourages pushState() if you can swing it -- you'll need to implement every client-side route as a server-side page as well ... so it's not possible if you're hosted in an inflexible environment. Backbone falls back to hashes for browsers that don't support the API, and transparently converts URLs between the two. But regular hashes ("#") are fine for internal single-page-apps that don't need google indexing -- of which the majority of Backbone projects probably are. It's just the hashbang "#!" that's a particular pet peeve of mine ;)

huhtenberg 15y ago

Can you elaborate? I don't follow how pushState (being a javascript function) replaces the need for _escaped_fragment contraption for letting crawlers fetch page snapshots in a specific state.

Skalman 15y ago
With pushState you can actually push a URL without the hash. It looks like I'm GETting /about, while it's really just / with the content of /about fetched via AJAX. A HTTP GET /about should of course give the same content as the AJAX version.
- huhtenberg 15y ago
  Right, but this still doesn't alleviate the need for "prerendering" specific pages for the crawler, which is the most tedious part of the whole thing. In other words, when a crawler requests /about, it should be getting a fully-formed About page with the content already in place, and not a bare container that ajax'es the content on page load (which is how most of pageless sites work).
  - Skalman 15y ago
    Yeah - that sucks, but is actually also necessary for optimal performance for users as well. I don't think it's excusable to have two HTTP requests for page content. (and hash bangs are just as bad when loaded directly)

dfabulich 15y ago

This is mostly right, but there's a very important exception: IE doesn't support pushState. If IE users are an important part of your user base, you should use hashbangs with _escaped_fragment_, but only on IE.