1

in backbone the hashbang was removed from the code with standard fallback to "#/path" which should be fine for crawling (see https://github.com/documentcloud/backbone/commit/10230e4d76e21f08a1dee1fe5d28994e2cf5f11d#commitcomment-477992)

but if a ie9 user wants to do a facebook share (copy paste url), i still need a _escaped_fragment_ handler, there i could do a canonical url or redirect to handle it in a clean way, but the "#!" fallback is still necessary, right ?

nici
  • 95
  • 1
  • 8

2 Answers2

2

The problem was when servers NEEDED the #! to determine where you were (a la Twitter/Gawker a few years ago). If you set your server correctly -- i.e. to always return your backbone app and (and start the router) for any URL within your app, it will handle correctly for all users.

IE8/9 users will see hashed urls. Sane browsers will display normal URLs. If a "sane" browser loads a hashed URL, the backbone router will know what to do. The same goes for IE8/9.

And as long as you're returning the correct view state for a given URL from the server, (i.e. pre-rendering on the server end), Google will have no problems just using your site like a normal website and indexing it merrily along.

The issue #! and _escaped_fragment_ were designed to handle really shouldn't matter much anymore.

EDIT

Example:

Lets say you have a Backbone app running on your server and it lives at http://myserver.com/myapp/. This is the base you pass into your Backbone.history object:

Backbone.history.start({pushState: true, root: '/myapp'});

This explains to the router that all the paths under /myapp/ are "owned' by the Backbone application. So long as ANY route requested that starts with /myapp/ returns your Backbone application, it will work, regardless of browser.

So, lets say your user is using the app and ends up with /myapp/awesome/thing/to/share. For an IE8/9 user, their URL will be /myapp#awesome/thing/to/share.

When the browser requests this from the server it only asks for /myapp. This returns your Backbone application and starts the history object/router. The router sees there is a hash fragment and says "oh give the user awesome/thing/to/share". This happens for ANY browser that requests this URL.

When an IE8/9 user requests /myapp/awesome/thing/to/share so long as your server returns that same Backbone app, the router will once again see that the path is /awesome/thing/to/share' and then automatically change the URL in IE8/9 to /myapp#awesome/thing/to/share.

The only place you need to do something tricky is if you want Google/Facebook to be able to scrape this page. Since they don't run javascript, the page will have to be sent from your server exactly as if Backbone had composed it in the browser -- or for Facebook, have the <og:*> tags available in the <head> section of the document.

tkone
  • 22,092
  • 5
  • 54
  • 78
  • if an ie8/9 user does a copy/paste to share the url in facebook they still need a #!, right ? – nici Jan 17 '13 at 11:48
  • They won't get a `#!` rather just a `#`. They don't need it as long as your server is configured correctly. Updated answer to explain. – tkone Jan 17 '13 at 13:38
  • thank you for your update, my question is concerned with the topic you discussed in the last paragraph, if i use the facebook linter i'm only able to scrape content specific to the hash code if it is followed by an "!" otherwise no escaped fragment parameter is added, i can't configure that with the server that lies with facebook, its server decides when to ask for the escaped fragment – nici Jan 17 '13 at 14:15
  • Facebook does not use the `_escaped_fragment_` system -- if you want Facebook to scrape a URL, it must have the correct tags in it at the URL that Facebook is scraping. What I've done in the past is look at the user-agent of what is accessing the page and sent just a page with the correct facebook tags out to the facebook user-agent. – tkone Jan 17 '13 at 17:39
  • sorry for being persistent but if you do a linter request on e.g. a twitter URL: https://developers.facebook.com/tools/debug/og/object?q=https%3A%2F%2Ftwitter.com%2F%23%21mashable%2Fstatus%2F291963112851140608 facebook tries to access _escaped_fragment_ – nici Jan 17 '13 at 17:44
  • ah, that's newish then. or something we never got working correctly :). You can set that up as well then! – tkone Jan 17 '13 at 17:49
  • My recommendation still stands though. Lets move forward and not support those obnoxious shadow urls – tkone Jan 17 '13 at 18:08
  • so the answer is very simple, if you are in dire need of ie8/9 compatibility, you allow for "#!/path" fallback and ideally do a canonical url statement on the escaped fragment to the actual "/path" otherwise if you want to nudge the web into the right direction you don't :D – nici Jan 19 '13 at 12:28
  • You don't have to do that. If you set your server up correctly to always respond with the page the client requests, everything will just work. If you don't want to do the work to make your server pre-compile the pages on the server end, then yes, you'll need take extraordinary measures to support this. Both are going to take you probably the same amount of time to do, but the former is a much better experience for your users AND helps facebook/google in the process. – tkone Jan 19 '13 at 13:07
  • what do you mean with if i setup the server correctly ? how can facebook scrape #/path ? – nici Jan 19 '13 at 13:14
  • As I referenced in my answer. If your app is /myapp/ and you've got /myapp/awesome/thing/to/share/ as a route in that app, so long as when someone comes to your website to that URL, the page sent from your server is exactly what they'd see when they navigate there in your app, facebook & google do not need `_escaped_fragment_` at all. – tkone Jan 19 '13 at 13:26
  • i understand that, however my question relates to the circumstance that an ie8/9 user does a copy and paste of is url in the address bar – nici Jan 19 '13 at 13:30
0

The answer is (if no one provides an alternative) no if you have these requirements its not a bad idea, see discussion with tkone

nici
  • 95
  • 1
  • 8