Client-Side Web Architecture and Graceful Degradation

Not all browsers have the same capabilities; however, for various reasons, we want our web pages to exploit the cool new technology that modern browsers enable but still have the web pages work in old browsers. We use graceful degradation techniques so the pages work in all browsers.


Development time is limited and expensive.

People who write about CSS and JavaScript like to write about graceful degradation and that it is something that should be done because it can be done and is the right thing to do. Just because we know it can be done and even if we know how to implement it, it doesn't necessarily mean we always should. A web page that degrades gracefully is more difficult ane expensive to write and maintain. The return on this investment may not justify the extra expense.

If we want to build truly cross-browser sites that degrade gracefully we have to worry about many things. For example, a disabled client (that's the browser software) may have various levels of support or no support for HTML, images, CSS, JavaScript and/or cookies. Every browser has bugs and every pertinent bug must be handled properly. A disabled user (that's the person) may be partially or completely blind and using a screen reader. And there are many browsers out there. With limited developer time, it may not be realistic to attempt to build a cross-browser web page for anything more than a simple web page. Due to constraints we may have to pick a subset of browsers and develop for those.

Here are four case studies of main four types of web pages/sites/applications. Each case tries to identifies the target group, design tradeoffs and appropriate times to use each. Making these decisions is all in the grey area. The pros and cons have to be weighed.

Government of Canada

Accessibility to the content is the number one priority as citizens have a right to the content. The government doesn't have competitors and doesn't have to wow users. Spending tax payer's dollars on building fancy pages with JavaScript that must work with JavaScript disabled is not worth the expense. This site is built for the lowest common denominator client and is a typical Web 1.0 site with static pages and a few forms. Even the basic layout of the pages is with tables so that old browsers with poor CSS support will see reasonable pages. Nothing or close to nothing needs to degrade.


The Amazon site displays products. The urls should change as the user browses the site so that each url can be emailed. Users don't spend a long time on a single page and need it to dynamically update.

The main function of each Amazon page is to display information about products and make sales. This doesn't need or necessarily benefit from drag and drop, WYSIWYG or Ajax. The basic HTML page must work without JavaScript or otherwise disabled browsers.

On many of the pages, Amazon had added some JavaScript that will enhance the user experience. These little bits of code are not essential to the main function and don't change the way the pages work overall. This JavaScript gives each page some stretch so that for users with JavaScript the page works a bit better. The Amazon pages are the one size fits all graceful degradation technique that could be called Web 1.5. Each individual page works with various browser abilities. This is a nice compromise for what the Amazon site needs to do.


37signals is profitable and famous but they didn't invent anything new. The Internet already had solutions for business like to-do lists, group chat, and file sharing. 37signals repackaged these solutions and inspired payed subscriptions. What design decisions helped lead them to such success?

37signals is largely successful for the same reason the Internet is: The World Wide Web. More or less, anyone with an Internet connection and a modern Web browser can use the 37signals solutions. That's a lot of people! It doesn't matter if you are using Windows or Mac. You don't have to download any browser plugins, or standalone chat or file-sharing client applications and learn how to install and use each. 37signals made it simple. Your new computer came with the necessary browser installed. Just plug in your connection, point your browser at a 37signals site and start sending them money.

To use the 37signals solutions you need a modern Web browser. Your browser must support images, cookies, enough CSS, enough JavaScript. Some corporate networks do not allow some of these requirements (likely cookies and/or JavaScript). You need a computer new enough for modern Web browser. You need an Internet connection fast enough for a acceptably responsive user experience. If you are disabled, you need to be able to use a web browser the way most people do or have sufficient software to help you navigate. You need to know English.

Not everyone can be a 37signals customer but by using a relative relaxed set of requirements most Web users can (maybe 80% or more). 37signals developers are not worried about selling to people without the necessary technology or with other limitations that make the 37signals unappealing. Why would they be willing to dismiss any potential customer base? Increased profit.

37signals is optimized for profit and to a lesser degree developer enjoyment and even developer fame. 37signals is a wily startup that wants to skim the cream. By quickly developing modern, exciting, competitive applications that work for 80% of Web users, the small company can attract a large proportion of this 80%. To make their applications usable by the other 20% of Web users the development time would increase dramatically. The 20% of Web users that currently cannot use their solutions probably contains a small proportion of people interested in business solutions anyway. Business users likely have modern computers and browsers with all the bells and whistles. Instead of trying to get the last few possible users to subscribe to one of their current solutions, 37signals could instead use the time to develop another solution to a different problem that works for the 80%. This is the more profitable option.

So 37signals JavaScript throws errors your older browsers. They don't care. Their site layouts don't work your older browsers. They don't care. Don't have cookies and can't use their site? They don't care. They don't need to care about you if you don't have the necessary technology. You and the 20% representing diminishing returns. 37signals has found its profitability sweet spot. Want their products? Get a new computer.

Who said Web 2.0 had to be backwards compatible with web 1.x?


Email is a far more generic web application than the 37signals applications and the big companies with deep pockets are in the game. The Microsoft Hotmail and Yahoo! Mail email applications were in the Web 1.0 category. When Google decided to enter the email battle they had to be better. They had to crush the competition in every possible market even if it was just for pride. Google knew that whatever solution they released, the other two companies would try to match or better it...and Google had the funding to win.

Google's Gmail with it's use of Ajax definitely did out do Hotmail and Yahoo! Mail. This repackaging of email in a more modern user interface that requires a modern web browser won Gmail success similar to the success of the 37signals applications. However, Google did decide to release a Web 1.0 version of Gmail so that users without a modern browser or disabled browser could still use Gmail. Google also released a Gmail version for cell phone users. And RSS. And POP. Why was it wise for Google to release multiple versions when it wasn't for 37signals?

Web 1.0 versions of the 37signals solutions might bring them 1000 more users which might not even pay for the needed development time. For Google, a Web 1.0 version for their email solution might gain more than 100 000 Gmail users. That is a lot of people for the time necessary to develop a simple, static email application. Remember that Gmail scan's all your emails and advertises down the right side based on your content. They want access to every last user they can get.

When web pages for different browser environments have to be drastically different then it is faster to develop several completely independent UI's than try to have one gracefully degrading web page that works in all cases. This overlapping of UI's is a nightmare for coding and maintenance. Gmail has avoided this nightmare by using a gateway JavaScript when the user arrives. This script determines the client type and it's capabilities and forwards the user to the correct version of Gmail. For regular browsers, you are directed to either the static Web 1.0 site or the Web 2.0 application with all it's Ajax goodness. This divide and conquer approach to separating the site into different version makes the site as a whole degrade gracefully rather than individual pages that degrade gracefully like Amazon has.


Have something to write? Comment on this article.

Murali February 9, 2007

Lots of us (software developers) are tempted to develop a web application that can be opened on literally any browser and yet with a rich ajax-ian user interface, without considering the target audience and business limitations. Your post articulates various constraints and offers a clear and precise guidance on the topic citing real world examples. Thank you very much for the insight.

Santosh February 18, 2007

Nice write-up and analysis of strategies companies deploy. Followed it through Murali's page.

- Santosh

Have something to write? Comment on this article.