4 ms·

Why are people calling URL fragment a "hashbang" now? The exclamation point is only as recent as Google's Ajax spider standard proposal. (Is the present essay

by pohl 15y ago

Why are people calling URL fragment a "hashbang" now? The exclamation point is only as recent as Google's Ajax spider standard proposal. (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"?)

barrkel 15y ago
Because the convention as used by Gawker and similar is not about referencing an anchor but describing a page. IOW these things should be part of the url proper, not fragments.
- pohl 15y ago
  Ok, so the hue and cry is specifically about the use of the technique when the content seeks to be indexed (and therefore includes the bang)? The author would not find a problem with GMail, for example, using a bookmark-able fragment like "#inbox/13038eb4c2b587f7" in the same manner as Gawker (that is: not referencing an anchor but describing an addressable page full of content)?
  - extension 15y ago
    The problem is with any site that uses stuff after the hash to distinguish between what should be different application states. From the REST perspective, these applications just have one huge state and thus miss out on many of the benefits of REST. 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.
    - wahnfrieden 15y ago
      Sorry but REST is fine with forcing the client to maintain its own state (in fact it's pretty much assumed the client will, for any non-trivial application). Using hashes in this manner shouldn't require the server to maintain additional state. If I'm missing something here, could you please elaborate?
      - extension 15y ago
        Well, an application has many kinds of state on many different levels. The sort of state that serves as the S in REST is the one that a client changes by requesting and manipulating representations of resources identified by URIs. 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.
        wahnfrieden 15y ago
        Ah okay I see now, code-on-demand as a primary method does run contrary to REST. Thanks for clarifying.
sp332 15y ago
I think this article has a good explanation of what people find distasteful specifically about those hashbang fragments: http://news.ycombinator.com/item?id=2592741 http://news.ycombinator.com/item?id=2592741
dedward 15y ago
I'm quite puzzled there too. In what sense is using a hash as part of the address a hashbang? Hashbang refrers to #!, #!, and only #!.
- JeremyBanks 15y ago
  Google published a specification [1] for "Making AJAX Applications Crawlable" which uses #!. This has been widely adopted; it's plausible that the majority of web apps that store their state in fragment identifiers use this convention. That is why people are using the term "hashbang" to refer to the practice in general. http://code.google.com/web/ajaxcrawling/docs/specification.html http://code.google.com/web/ajaxcrawling/docs/specification.h...
  - Isofarro 15y ago
    Once of the reasons Gawker moved away from hashbangs is that they weren't well supported by Google, despite this being a "Google specification". Nick Denton, the founder of Gawker, has some interesting tweets about the use of hashbangs over the past few months: 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 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 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 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.

by pohl 15y ago

barrkel 15y ago

Because the convention as used by Gawker and similar is not about referencing an anchor but describing a page. IOW these things should be part of the url proper, not fragments.

pohl 15y ago
Ok, so the hue and cry is specifically about the use of the technique when the content seeks to be indexed (and therefore includes the bang)? The author would not find a problem with GMail, for example, using a bookmark-able fragment like "#inbox/13038eb4c2b587f7" in the same manner as Gawker (that is: not referencing an anchor but describing an addressable page full of content)?
- extension 15y ago
  The problem is with any site that uses stuff after the hash to distinguish between what should be different application states. From the REST perspective, these applications just have one huge state and thus miss out on many of the benefits of REST. 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.
  - wahnfrieden 15y ago
    Sorry but REST is fine with forcing the client to maintain its own state (in fact it's pretty much assumed the client will, for any non-trivial application). Using hashes in this manner shouldn't require the server to maintain additional state. If I'm missing something here, could you please elaborate?
    - extension 15y ago
      Well, an application has many kinds of state on many different levels. The sort of state that serves as the S in REST is the one that a client changes by requesting and manipulating representations of resources identified by URIs. 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.
      - wahnfrieden 15y ago
        Ah okay I see now, code-on-demand as a primary method does run contrary to REST. Thanks for clarifying.

sp332 15y ago

I think this article has a good explanation of what people find distasteful specifically about those hashbang fragments: http://news.ycombinator.com/item?id=2592741 http://news.ycombinator.com/item?id=2592741

dedward 15y ago

I'm quite puzzled there too. In what sense is using a hash as part of the address a hashbang? Hashbang refrers to #!, #!, and only #!.

JeremyBanks 15y ago
Google published a specification [1] for "Making AJAX Applications Crawlable" which uses #!. This has been widely adopted; it's plausible that the majority of web apps that store their state in fragment identifiers use this convention. That is why people are using the term "hashbang" to refer to the practice in general. http://code.google.com/web/ajaxcrawling/docs/specification.html http://code.google.com/web/ajaxcrawling/docs/specification.h...
- Isofarro 15y ago
  Once of the reasons Gawker moved away from hashbangs is that they weren't well supported by Google, despite this being a "Google specification". Nick Denton, the founder of Gawker, has some interesting tweets about the use of hashbangs over the past few months: 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 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 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 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.