Twitter Rolls Twitter.com Back to a Server-Side Architecture

This isn't a rollback of the API-oriented architecture, it's a rescue of a bunch of wrong-headed design mistakes, like forcing the rendering of individual status pages through a JavaScript function, using a hash-bang URI.<p>One of the major drivers behind the constraints in a RESTful architecture is user-perceived response time. Routing all content through "code on demand", which is effectively what you're doing when you force a JavaScript function to do all the rendering, instead of the browser itself, is not taking advantage of the fast, incremental rendering nature of plain old HTML generated by the server.<p>One can still design good API-oriented URIs with a server-side approach, you're just providing different serializations of the same resource (a nice HTML one and a JSON one for API access).... so there's nothing fundamental that Twitter has lost or abandoned here. They're just using the web better.

I am so proud of twitter right now, that I feel words will fail me, so I shall keep this short and to the point:<p>It takes serious balls to admit you were wrong after you kicked off an entire avalanche that has been breaking the web ever since. Yes, a lot of us knew then it was a ridiculously bad idea and we all said so; but for them to actually take this advice after going so out of their way to go completely client-side is just fantastic. Kudos, twitter folk!

Here is the original post, by the Twitter engineers:<p><a href="http://engineering.twitter.com/2012/05/improving-performance-on-twittercom.html" rel="nofollow">http://engineering.twitter.com/2012/05/improving-performance...</a>

To mark this momentous occasion I'm going to go back and reread Steve Yegge on Amazon's SOA.<p><a href="http://plus.google.com/112678702228711889851/posts/eVeouesvaVX" rel="nofollow">http://plus.google.com/112678702228711889851/posts/eVeouesva...</a>

It is always a little misleading reading articles like this because they don't get into many of the details. At the end of the day, you need to build to meet the requirements of your target audience. It doesn't really make sense to think that just because Twitter does something, then you should do it. The optimizations they are talking about may be so specific that they don't even apply to the common mid-sized web app. I think that the overall client-side architecture has broken new ground and does provide benefits that make sense for a lot of sites. I wouldn't think twice about not using the client side architecture just because of Twitter making a change.<p>Also, as some people already noted, Twitter didn't abandon client side rendering. If you go on the site now, you will still get redirected to the #! page.

I wouldn't call it a rollback completely, but an improvement on the first time load. The whole Twitter page is rendered initially server side but then any subsequent request is made by JSON calls and rendered client side -- probably the best approach given the time it took for Twitter.com to load.

Twitter is used in a lot of developing countries, through a lot of outdated browsers, on a lot of slow computers. I'd imagine that this plays into their choices somewhat.

I think this is great. The browser isn't an OS, it's a portal. It's already running on an OS. It didn't work for mobile (remember Apple was all about the web apps back in the day), it shouldn't work for desktop.

Thank the creator. It was a blindingly unnecessary fashion statement that caused more problems than it solves, and I wish it safe passage on its way to the closet of failed experiments.

But Twitter.com is slow (like a couple seconds to load twitter.com/#!/someone) even if you're using the latest Chrome browser - it can't be just fault of the client side architecture...<p>If the initial JSON was coming bundled with the page, the only reason for the slowdown is parsing JS? I thought that was what browsers were good at those days...

Sorry, but what's the difference between using a web application architecture and using a server side architecture? I'm curious!

Seeing as the web is more service oriented than object oriented..<p>Are we surprised to see a step towards SOA (presumably from OO that was also at the service layer)?<p>For me Web / mobile apps that are architected from a primarily OO perspective can turn out very differently (often with unique OO bottlenecks) than apps architected from a service-first perspective, using OO to fulfill services.

There's still a shebang in the URL. If I enter a URL without a shebang, it redirects to one that contains a shebang. Since the browser won't include the fragment in the request, how does the server know which page to send back without using JavaScript to make another request? So it's not really "server side", not even the initial page load.

I feel they were doing it wrong. If they preloaded the page with bootstrapped data + templates then it should be as fast.

2011-02-11: "We've made a tradeoff, however, in making twitter.com into an application using the hash, which is that it now cannot be both an app and a site at the same time."<p><a href="http://www.adequatelygood.com/2011/2/Thoughts-on-the-Hashbang" rel="nofollow">http://www.adequatelygood.com/2011/2/Thoughts-on-the-Hashban...</a>

I welcome this but sticking with the fastest twitter client yet - their mobile site. i use it even on desktop plus they recently made improvements on it<p><a href="http://news.ycombinator.com/item?id=2977580" rel="nofollow">http://news.ycombinator.com/item?id=2977580</a>

The client-side approach would work great if they didn't try to cram in so many features.

from what i can tell, they are just rendering the initial page load on the server now.

I'm glad to see this. While it was an interesting experiment for Twitter to undergo, their front end performance really took a hit. I expect they'll see their usage numbers on twitter.com start going up again as they fix things.

Twitter is doing the best approach which is a mix of both client-side and server-side. It is not an either or situation.