It's About The Hashbangs(danwebb.net)
danwebb.net
It's About The Hashbangs
http://danwebb.net/2011/5/28/it-is-about-the-hashbangs
18 comments
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.
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...
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.
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.
"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.
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.
Searching through ShowSlow.com provides more visibility:
http://www.showslow.com/details/92778/http://twitter.com/#!/...
That's 1,887 ms to render anything and almost a full second of JavaScript execution time.
Waterfall graphs show a similar story: they pushed everything past the document load event so the monitoring tools are a bit off:
http://www.webpagetest.org/result/120414_9W_3Z15P/ shows an acceptable 1.4 second start of render, which isn't great but acceptable, but looking at the actual video shows that's merely how long it took to render a tiny part of the page - displaying the content which the user actually wanted about took over 8 seconds!
http://www.webpagetest.org/video/view.php?id=120414_2a4075f2...
http://www.showslow.com/details/92778/http://twitter.com/#!/...
That's 1,887 ms to render anything and almost a full second of JavaScript execution time.
Waterfall graphs show a similar story: they pushed everything past the document load event so the monitoring tools are a bit off:
http://www.webpagetest.org/result/120414_9W_3Z15P/ shows an acceptable 1.4 second start of render, which isn't great but acceptable, but looking at the actual video shows that's merely how long it took to render a tiny part of the page - displaying the content which the user actually wanted about took over 8 seconds!
http://www.webpagetest.org/video/view.php?id=120414_2a4075f2...
Sorry I didn't realized this was 2011, someone referred to it on G+ and I posted as new...
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.
Hat tip to dan webb.
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.
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.
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.
Funny this was written just before Old Twitter (that did not use hashbangs) was removed:
http://goodmorninggeek.com/archives/1766
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.
Then it would be nice to have some background on what pushState is (or will be) and what its purpose is.
Also I find it unfortunate that of anything they used the same term as the oft-used Unix program loader feature.
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.
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.
[deleted]
Thanks!
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.
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.
I explained them in a post about a year ago:
http://tumbledry.org/2011/05/12/screw_hashbangs_building
which was discussed here:
http://apps.ycombinator.com/item?id=2592741