

Its About The Hashbangs - bentlegen
http://www.danwebb.net/2011/5/28/it-is-about-the-hashbangs

======
marknutter
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.

~~~
dave1010uk
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.

~~~
jahmed
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...](http://arstechnica.com/web/news/2011/05/web-browser-market-share-
upgrade-analysis.ars)

~~~
dave1010uk
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".

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

------
pohl
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
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
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
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
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
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
Ah okay I see now, code-on-demand as a primary method does run contrary to
REST. Thanks for clarifying.

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

~~~
simonw
pushState.

~~~
voidr
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.

~~~
udp
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/>

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

------
zbowling
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

------
swah
What about single page apps?

~~~
keeperofdakeys
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.

~~~
riobard
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.

~~~
wahnfrieden
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.)

~~~
riobard
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.

