I am a programmer and architect (the kind that writes code) with a focus on testing and open source; I maintain the PHPUnit_Selenium project. I believe programming is one of the hardest and most beautiful jobs in the world. Giorgio is a DZone MVB and is not an employee of DZone and has posted 636 posts at DZone. You can read more from them at their website. View Full User Profile

GitHub is a web application, Twitter is not (yet)

03.08.2011
| 11258 views |
  • submit to reddit

Yesterday, in a lecture on web technologies, we consider Flash application and what is their position in the web.

Is a Flash application a web application? The answer was yes and no. It is in some sense, since it is delivered over HTTP. However, it is not limited to use HTTP to communicate with the server: that is what make Flash a cool platform that has made YouTube years before HTML 5, but not strictly a Web technology.

Immediately, Chris Shiflett comparison of Flash and modern-JavaScript applications came to my mind:

Everything I used to hate about Flash is back, this time in the form of JavaScript. Like Flash sites, there is a new breed of web apps that don't feel quite right. Maybe it's because they scroll like a supertanker. Maybe it's because the back button doesn't work right. Maybe it's because the browser tells you it's done, but you don't see any content. (I'm looking at you, Twitter.) -- Chris Shiflett

In fact, I am one of the Twitter user hurt by the revolution of the Twitter.com user interface, which is becoming more and more brittle.

The hashbang syndrome

The hashbang (#!) usage for client-side routing is one of the causes. When you load twitter.com/#!/username, you do not really load the profile of username.

Instead, you load simply twitter.com, and JavaScript code executed on the client side will read the part of the URL after # (which is normally ignored by the browser, as an hash fragment which do not affect synchronous (via the URL bar) HTTP requests, and perform an Ajax call to build the rest of the page (a pun: it's not really REST.)

Add to this the forced redirect: if you load the equivalent URL twitter.com/username, you're redirected to twitter.com/#!/username where, again, JavaScript calls will load the parts of the page for you. This makes sense, as it is done to avoid URLs like twitter.com/username1#!/username2, but the fact that they can work is a design smell.

After reading the many contributions on the topic, I am convinced that the use of hashbangs instead of real URLs has consequences you can't ignore:

  • first of all, crawlers and other browser-like tools are cut out. HTTP was becoming universal, but Google has to invent and push new standards for translating hashbang URLs into real ones.
  • Bookmarks/permalinks work, but only if you load them in the browser. If you get the permalink and tell an extension, or curl, or a feed reader, or every tool not capable of executing JavaScript over a DOM to use it, it breaks.
  • You have to reimplement caching from scratch, as I don't believe many proxies and HTTP caching systems care about different hashbangs. If they adhere to the standard, they should ignore them.
  • Requests which do not complete or become slow are usually ignored. When on an unreliable connection, this behavior is really annoying, as the user is not told what is happening (like a browser would do), nor he can know if the application is really loading or needs a restart. 37Signals has better solutions from the usability point of view.
  • The back button has to use the same mechanism of rebuilding the DOM via JavaScript, so between the action and the execution there is a delay and another potential failure mode.

Basically, it's SOAP vs. REST all over again, where instead of using standard features of HTTP you reinvent a superstructure of metadata over it, in this case to point to a page which has to be rebuilt via execution of custom code instead of by a browser rendering algorithm.

The cure: HTML 5 History

Fortunately, Twitter developers are well-aware of it:

There is hope on the horizon, in the form of the HTML5 History API. This new browser feature will allow developers to change the entire URL path and query string without incurring a page refresh. By using this, we could drop the hash, and get all the benefits of traditional Web sites with all the benefits of a desktop-class application. Support for this has been in Chrome and Safari for some time (albeit with a bug we found (now fixed)), and will arrive in Firefox 4. Internet Explorer currently has no plans to implement this in IE9, which is a shame. Had it not been for the bug we found, we would have shipped #newtwitter with HTML5 History on day one (and in fact, the integration is already built). -- Thoughts on the hashbang

What's this HTML 5 History? Something Github is doing already:

The new HTML5 History API (which really has nothing to do with HTML — it's a JavaScript API) allows us to manage the URL changes while CSS3 transitions handle the sliding. Permalinks are always maintained, your back button works as expected, and it's much faster than waiting for a full page load. -- GitHub blog

Of course, GitHub has an audience who has certainly the technical know-how for changing his browser, and they only serve the new version to browsers that support HTML 5 History. I bet Lady Gaga and Justin Bieber won't be such familiar with Chrome and Firefox in case they are on Internet Explorer.

The logic for GitHub navigation is clear: the URL in the bar always points to the whole page you're seeing, even if you're navigating via JavaScript; the application is fully degradable and you can load the content of an URL via telnet if necessary; it's an utopia.

For Twitter this may be more difficult than for GitHub, as Twitter has various screens really only three conceptually different screens: tweets, tweets with side panel, and list of people The only thing necessary (in fact, they have already done it in the hasbang version) is to update the URL to reflect the state of the view everytime something changes.

If you render HTML on the server, there's very little duplication as the components of a screen can change, but they are requested one by one to the server instead of as a whole <html> tree.

If browsers keep up with HTML 5, intended as an umbrella for the new HTML, CSS and JavaScript standards, we will see more degradable and RESTful applications in the future. In the meantime, let's wait for Internet Explorer upgrades for Twitter to return a web application instead of a window-wide Flash widget.

Published at DZone with permission of Giorgio Sironi, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)