GitHub is a web application, Twitter is not (yet)
The Web Dev Zone is brought to you in partnership with Mendix. Discover how IT departments looking for ways to keep up with demand for business apps has caused a new breed of developers to surface - the Rapid Application Developer.
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.
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.
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.
- 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.
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:
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.
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.