Dan Webb, Twitter's engineering manager, web core team, has outlined in a blog post that Twitter is to rework its underlying architecture in order to boost performance. The changes will see Twitter move way from the JavaScript-heavy web application architecture approach of late 2010, with the company "working to take back control of […] front-end performance by moving the rendering to the server".
According to Webb, initial page load times will be one-fifth of what they were previously, and other changes should help Twitter's team to more rapidly add new features in the future. One of the most obvious changes to those who pay attention to web addresses will be the hashbang's removal during the transition. "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," explained Webb. "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."
'New Twitter' was never hugely popular. Tim Bray complained about the manner in which hashbangs break the web and almost exactly a year ago, Webb himself also stated he was unhappy with hashbang usage.
Today, most developers are understandably happy with Twitter's announcement. Mozilla developer evangelist Christian Heilmann told .net: "I love this change. Hashbang URLs are a horrible hack and only needed for environments that don't support the history pushState API. I also like that Twitter shows the most mentioned argument about the need for hashbangs in the past – performance – is bogus." He added that URLs should be "real URLs that can be followed in an environment without JavaScript or a browser," and hoped others would follow Twitter's example, perhaps through Twitter "providing numbers to back up its decision, thereby debunking myths about the perceived excellent performance of JavaScript-only apps."
Developer Mark Damon Hughes told us that Twitter's approach for New Twitter was doomed from the start. "There's a neat, modern way to build a dynamic site: have a tiny stub of HTML, jQuery, and your JavaScript in a static file. This calls up to the server in AJAX queries and fills in the page. If you do it right, you cut down on bandwidth and loading times. You can put most of your site on CDNs near the user."
Hughes explained this isn't what Twitter did: "It made a giant fat client that loaded slowly, loaded your entire home page with a big background image and feed, then replaced it with whatever you had actually requested." But he also said that the updated architecture in itself won't be a magic wand for the service: "Twitter's going back to a server-rendered page, which for a single query like viewing one tweet will be faster for the service's server and the user. But if you then hit a user's page, or your own, or do anything that needs a reload, Twitter either has to send the whole page again like it's still 1995, or go back to the fat client and AJAX. Maybe someday it'll trim that client down…"
