Twitter is a web site, not a web app. First-page load performance is critical for them. I wouldn't have chosen a client-side rendering architecture.
My perspective is that of web apps. By using client-side rendering I can prefetch more data than the user needs at almost no extra cost, and render it when they click without hitting the server. Not having to contact the server at all beats any server-side rendering architecture. Even web apps that supposedly do server-side rendering will end up with some prefetching for performance (e.g. tooltips and detail panes are already embedded in the page but hidden).
The reality is that the big bottleneck in any web app is not the fetching of data but the fetching of the front-end. The more front-end code (images, js, css) that you can fetch from browser cache or CDN the faster your app. The "ideal" case is not having to fetch anything except the data from the server. You can do that today with client-side rendering combined with far-future expiration or HTML5 appcache. The caveat here is that the performance benefits only start compounding for client-side rendering if you can prefetch data. Twitter couldn't do that, so there was no benefit.
Like any complex technical issue, there is no right answer in general, only a right answer in context. People should just be careful about what they're measuring. The important benchmark is time to load the page, not time to process the page on the server (a huge difference), and measurements should be globally distributed (you should be measuring transcontinental page visits).
My perspective is that of web apps. By using client-side rendering I can prefetch more data than the user needs at almost no extra cost, and render it when they click without hitting the server. Not having to contact the server at all beats any server-side rendering architecture. Even web apps that supposedly do server-side rendering will end up with some prefetching for performance (e.g. tooltips and detail panes are already embedded in the page but hidden).
The reality is that the big bottleneck in any web app is not the fetching of data but the fetching of the front-end. The more front-end code (images, js, css) that you can fetch from browser cache or CDN the faster your app. The "ideal" case is not having to fetch anything except the data from the server. You can do that today with client-side rendering combined with far-future expiration or HTML5 appcache. The caveat here is that the performance benefits only start compounding for client-side rendering if you can prefetch data. Twitter couldn't do that, so there was no benefit.
Like any complex technical issue, there is no right answer in general, only a right answer in context. People should just be careful about what they're measuring. The important benchmark is time to load the page, not time to process the page on the server (a huge difference), and measurements should be globally distributed (you should be measuring transcontinental page visits).