(Is the present essay only concerned about the strict subset of navigation state encoded in fragments that seeks to be indexed by spiders? Or is it concerned about all such usage and is abusing the term "hashbang"?)
(Is the present essay only concerned about the strict subset of navigation state encoded in fragments that seeks to be indexed by spiders? Or is it concerned about all such usage and is abusing the term "hashbang"?)
What's worse, fixing this flaw necessitates breaking all of the application's URLs.
When pushState is used properly, a single-page app essentially becomes a transparent client-side proxy/cache, which maps much better onto REST.
An application composed of a single representation that implements the entire app with code-on-demand is not exploiting the REST architecture very much.
Actually, even if the application is properly broken up into URIs, it's still not entirely RESTful because the "engine of application state" has become Javascript + secret protocol rather than hypermedia.
In what sense is using a hash as part of the address a hashbang?
Hashbang refrers to #!, #!, and only #!.
http://code.google.com/web/ajaxcrawling/docs/specification.h...
Nick Denton: "Dip in uniques largely because of drop in Google refers. Pageviews (which are driven more by core audience) less affected." -- http://twitter.com/nicknotned/status/61152134929981440
Nick Denton: "Google does not fully support "hashbang" URLs. So we're eliminating them rather than waiting for Mountain View." -- http://twitter.com/nicknotned/status/61465859079671808
Nick Denton: "Yeah, I'd advise against hashbang urls. Will kill search traffic -- even if you abide by Google protocol." -- http://twitter.com/nicknotned/status/62595141927583745
So here's a high-profile failure of hashbangs when it comes to being indexed by Google. Which means if it's search indexability you want, hashbangs isn't it. The Google spec just isn't mature enough, or well supported by Google search itself.