Its About The Hashbangs | Hacker News Reader

Its About The Hashbangs

danwebb.net

82 pointsbentlegen31 comments

Hashbang urls probably don't make sense for a blog like Gawker is using them for, because maintaining link history and being indexable are pretty much the most important things for a blog. But they DO Make sense for rich, desktop-like javascript applications that don't want any page refreshes but would like to preserve states that people can bookmark for later (and that want the browser's back button to work for).

I've heard a lot of FUDD surrounding hash-bangs, but no real convincing arguments why they're so evil. The argument will be moot once the majority of the internet community upgrades to modern browsers, which is not too far off.

IE9 does not support the History API, nor does the current platform preview of IE10. Microsoft have quite a bit of time to get features into IE10 and I really hope the History API is one of them.

I there was a bug tracking this for IE9 but it got closed. Not sure if there's one for IE10.

While IE's market share is decreasing, I believe it will be a long time before > 90% of users are not on IE 6-9.

Well 44% of users already dont use IE, so that day long since passed.

http://arstechnica.com/web/news/2011/05/web-browser-market-s...

44% of people currently not on IE 6 to 9 is under half way to the 90% I was refering to. Not sure what you mean by "that day long since passed".

I agree with this comment. There some web apps with no backend, like the games providing a hashbang url like "#!/game/1" for each session, storing the data on the browser. No backend means, we need to pick index.html as 404 page (I never prefer this way), to implement same thing without hashbangs. And there is no explonation for these kind of apps, in this blog entry.

Excellent article - this is the best explanation I've seen of why I personally find hashbangs so completely objectionable. URLs and HTTP response codes are fundamental parts of what makes the Web work so well, and throwing them away just to gain a tiny bit of loading speed in browsers that don't support pushState is a terrible tradeoff for almost all sites and applications.

Hashbangs damage the Web.

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"?)

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.

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)?

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.

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?

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.

Ah okay I see now, code-on-demand as a primary method does run contrary to REST. Thanks for clarifying.

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 #!.

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.h...

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

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.

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

I's not an all or nothing package, I mean if you have blogs and articles, you will need the traditional URLs, but if you have a single page application, then you need hashbangs, there is no traditional way of achieving this, let's say all your content is rendered and you have a tab view on your page, and you want to make sure that if your page gets reloaded, the user would get the same tab opened, you have no better way of doing this.

pushState.

Currently it is not widely supported, I actually developed a hybrid mechanism that can use either one or the other.

Push state is really good because it lets the server know what's going on, but it did not work in Firefox when I last checked.

It does work in FF4, but it's not widely supported enough to rely on just yet, you're right.

I also find the best thing to do is use a hybrid approach (pushState where available, hashbang as a fallback.) If anyone else is interested in implementing this, there are some good frameworks[1][2] to give functionality similar to pushState via the fragment identifier.

Note that these constantly poll the hash in browsers that don't support the onhashchange event. It's a good idea to turn down the polling frequency to half a second or so, because I've found it can cause performance problems in IE.

[1] http://code.google.com/p/reallysimplehistory/

[2] http://benalman.com/projects/jquery-bbq-plugin/

The URI fragment makes single-page web apps possible. It removes the waste of having the browser re-parse DOM and re-interpret Javascript each time the user switches interfaces.

One disadvantage is that the Referrer header does not include the fragment identifier. But that's a problem with the Referrer header and not necessarily the fragment identifier.

The fragment identifier has been a part of the web for years, for the purpose of describing the user's state on the client. It's just that we interpreted this as just meaning "bookmarks" and didn't use it for anything more than that. We've only recently started to understand the fragment identifier and use it more fully.

I thought the article was "#!" in scripts from the title. I think the ops term is wrong. I know there other's using it, but it feels totally wrong.

The only javscript hashbang I know is:

#!/usr/bin/env node

What about single page apps?

I'm currently building a hybrid. An app would benefit from pure javascript frontend (speed), but to honor accessibility (and SEO), I've decided to serve pages traditionally using static urls, and only if client has javascript enabled, it will take over and make page fully dynamic, updating content via ajax and address bar with history.pushState. Been considering hashbangs for a while, but that thing just doesn't feel and look right to me. Although not all browsers support pushState yet, browsers evolve pretty fast, so I expect this feature to be supported by all browsers fairly soon, no point to waste time and break the web implementing inferior solution.

You don't need to use hashbangs or fragments for this, you just implement some javascript to not visit links, but change the page with javascript, then change the url to the new one. Your links are still linkable, and you can still have dynamic pages. As for search engines, if the site is a web app, they shouldn't be indexing it.

Look at http://tumbledry.org/2011/05/12/screw_hashbangs_building for how this would work, it was on HN yesterday. Visit just http://tumbledry.org to see how this can work.

One additional challenge is that POSTing a form will result in the whole page reloading by default. You will need to take this into consideration if you're supporting dynamic pages with graceful fallback.

I wonder if there's some JS library that transparently "fixes" issues like this for single-page sites with graceful degradation. Form handling, link click events, redirects, etc.

There is no way you can change the URL (not fragments) without refreshing the page (a.k.a single page app) if the browser doesn't support history.pushState. IE doesn't. That's why people are stuck with hashbangs.

The parent's method is still the best way as long as you do it by using replaceState or pushState where available, falling back to modifying the hash. This way, if Javascript is off, links in the HTML still work. (I suspect this is what he meant too, since changing links to modify window.location via Javascript provides no practical difference.)

The parent said “You don't need to use hashbangs or fragments for this”. I'm just pointing out there is no way to _not_ use fragments and still have a single page app.

I do agree that we should probably leave IE users to reload pages and provide graceful degradation. Modern browser users will enjoy the benefit of no refreshing on single page app. However, for some, this is not an option.

FOA, it's not a good idea to code for search engines.

Secondly, pushState is useless for single page apps. It's not all about changing the url, what's the way of handling that urls with just a single HTML document? To make index.html 404 page? What about the browser cache?

Reply on news.ycombinator.com