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.
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.
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!
Hat tip to dan webb.
Then it would be nice to have some background on what pushState is (or will be) and what its purpose is.
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.
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.