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