Ah, yes, I did not see that. Well, after reading the article on the Twitter Engineering site, I think this answers my question about the reasons for the switch:
-------
When you come to twitter.com, we want you to see content as soon as possible. With hashbang URLs, the browser needs to download an HTML page, download and execute some JavaScript, recognize the hashbang path (which is only visible to the browser), then fetch and render the content for that URL. By removing the need to handle routing on the client, we remove many of these steps and reduce the time it takes for you to find out what’s happening on twitter.com.
------
My original point is still valid, though. Twitter is dealing with a situation where they have a lot of code, a boat load of users and the need to squeeze every bit of optimization out of the site. The initial download of the JavaScript is a one time hit that would not make a bit of difference for most sites. More than likely they were also concerned about the proliferation of API calls due to increased functionality over time. I still think that if your combined and minified JS is < 1MB and you are able to keep your API calls relatively simple, the client side architecture is still pretty powerful.
Besides, in many cases I think you can fix performance issues on a one off basis where a page that gets too slow because of heavy JS and/or API proliferation could move server side if that makes sense while the rest of the app rendering stays client side. It doesn't have to be all or nothing.
I'm not sure how you expect the discussion to be accurate or informative without details that the article you summarized happily goes into. We already see confusion about where it's rolled out because we're reading you, not Twitter Engineering.
I'm not looking to add anything to theirs. Thats why I link to them. I'm looking to get discussion here and on Twitter...while I formulate my own thoughts...and more analysis. That's why I said...your the detail of this post.
>I'm not looking to add anything to theirs. Thats why I link to them.
Then link to them here as well. Save your own blog post for when you've got some original insight to add, then submit it to HN. Not before.
>I'm looking to get discussion here and on Twitter...while I formulate my own thoughts...and more analysis. That's why I said...your the detail of this post.
So we can remove your link, go straight to the twitter page (which would have probably been linked here eventually anyways) and not lose anything? Sounds great. Let's do that.
You want this: http://engineering.twitter.com/2012/05/improving-performance...