

It's About The Hashbangs - swah
http://danwebb.net/2011/5/28/it-is-about-the-hashbangs

======
camwest
This is a very old post and I thought we were past this. It guess it may seem
relevant due to the recent change in Twitter's client side architecture (Dan
works there). As far as I know Dan is implementing real urls without hash
bangs but will use pushState on supported browsers. The end result will
basically be the same but with an optimized initial page load since the whole
URL is delivered to the server.

~~~
timhaines
I think the post is relavant (today) considering Dan (the author) was
instrumental in removing the hashbangs. Twitter's Engineering Blog Post from
today: [http://engineering.twitter.com/2012/05/improving-
performance...](http://engineering.twitter.com/2012/05/improving-performance-
on-twittercom.html)

~~~
mattmanser
Weird thing they seem to have completely misidentified the reason why their
architecture was slow:

 _The bottom line is that a client-side architecture leads to slower
performance because most of the code is being executed on our user’s machines
rather than our own._

From a brief look I had at it a few months ago they were sending a 1.5Mb
javascript file which contained a template for every single action you could
ever perform on twitter. Because it was squished I assume it got invalidated a
lot as they made any tweak to their UI. That seemed to be the greater problem
rather than these mysterious execution times.

Seriously, who has ever had a performance problem transforming a bit of JSON
with something like jQuery.tmpl or mustache? They ultimately seem to have
thrown the baby out with the bath water.

Then again we had this discussion about client v server rendering when
37signals posted their new architecture, I understand there are advantage of
doing the template transforms serverside.

~~~
simonw
"Seriously, who has ever had a performance problem transforming a bit of JSON
with something like jQuery.tmpl or mustache?"

Mobile devices. Just parsing and executing a big chunk of JavaScript (like the
jQuery library itself) can take the best part of a second on many mobile
phones.

------
dfc
Wow, it is rare that you see a site look so nice when JavaScript is disabled.
More often than not when I click a link on HN I have to enable a ton of
domains in NoScript and RequestPolicy in order to get a sane rendering.

Hat tip to dan webb.

------
chadhietala
Using push state and using non-hash banged urls is the right move. Twitter is
pretty much unusable without javascript, and it doesn't look like they ever
got around to implementing a non-js fallback for the site. Best solution is to
have both (JSON and static) representations or use something like pjax
<https://github.com/defunkt/jquery-pjax>.

------
nthitz
I recently came across history.js <https://github.com/balupton/History.js/>
which will use pushState where supported and falls back to hashbangs
otherwise. It was overkill for my project, (we were already relying on several
other advanced html5 features so most users should have pushState) but it
certainly seems useful.

------
bceagle
I share your basic feeling that something with hashbangs are not right and I
do think that improper use can create issues. However, I do think it is
possible to utilize them effectively. I like the idea of using hashbang and
the javascript single page architecture for the heavy duty "app" portion of
your website (fyi which you likely would not want users to bookmark and link
to directly anyways) and then still have clean URL and server side code
generating the landing pages and static content. I think this is the best of
both worlds.

------
yuhong
Funny this was written just before Old Twitter (that did not use hashbangs)
was removed: <http://goodmorninggeek.com/archives/1766>

------
FixYourLogIns
It would be nice to have a little background on exactly what "hashbangs" do
and why they are used.

Then it would be nice to have some background on what pushState is (or will
be) and what its purpose is.

~~~
wisty
pushState is a way of going to a new page within a site without reloading
everything. If you go to twitter/posts/1 to twitter/posts/2, then all the HTML
and the twitter assets (images, css, javascript files, etc) will be reloaded.
(OK, there's caching, but ... it can still be slow).

pushState lets you rewrite the bits of the page you want to change using
javascript, without reloading anything inessential.

Hashtags do the same thing, because technically, hashtagged urls
(twitter/posts#1 vs twitter/posts#2) are on the same page. It's a way of
changing the URL in the address bar without technically changing the page.

~~~
DavidAbrams
Thanks!

~~~
wisty
OK, in retrospect that was confusing.

Both hashtags and pushState are ways of changing the page _and_ the URL using
Javascript. pushState is the "legal" way, which changes the page's URL (i.e.
twitter/posts/1 -> twitter/posts/2). hashtags technically don't change the
page, they change the part of the URL after the hash (i.e. twitter/posts#1 ->
twitter/posts#2).

hashtags are used because older browsers don't let you use pushState.
pushState is used because it's more correct, and doesn't exploit a hacky
loophole.

Both are used because they are faster than a whole new page request, and they
let you share the post by cutting and pasting the URL in your address bar.

