Perpetuating the myths of JavaScript degradation.

I came across a blog post on Justin Palmer’s site called Dispelling the Myths of Javascript Degredation. Unfortunately, the title isn’t very accurate. I was going to post a quick comment in response, but as I found myself writing more and more, I decided to just post it here.

I’m a little confused by his logic. He says:

“There was no added business benefit I can find to justify the reason for degrading.”

The implication here is that graceful degradation is some kind of expensive luxury that will cost both time and money. In reality, it is simply good practice, like using semantic markup, CSS for layout and ensuring that your pages are accessible — each of which have also been misconstrued in the past as “extras” that will cost more. In fact, the opposite is true. Graceful degradation (like semantic, accessible markup) is simply a matter of doing things the right way from the start — it doesn’t cost anything extra.

If you find yourself in a situation where it will cost you extra time and effort to rectro-actively make sure that your Ajax site degrades gracefully then, I’m sorry, but you’ve probably built it the wrong way to begin with.

It’s all in the approach. In the comments to the post, Gabe da Silveira states:

“I think making an application degradeable is mostly solved in the architecture phase to make sure that the core functionality is modular enough be accessed through the Javascript/AJAX interface or through a Server-side/GET/POST request.”


In many ways, it’s easier to make an Ajax enhancement degrade gracefully (compared with non-Ajax JavaScript) because all of the processing is shifted to the server rather than the client. When the client environment is limited (by a lack of JavaScript), you can still allow your visitor access to the core functionality, which is handled on the server side. Whether that functionality is delivered through discrete updates to an already loaded page (i.e. Ajax) or whether that functionality is delivered through old-fashioned page requests simply becomes a matter for the visitor’s browsing device.

Once you can view Ajax this way, then it becomes clear that graceful degradation is built in from the start, almost without thinking about it.

I’m not aiming to single out Justin here. His mental model of Ajax is very prevalent. He begins his post by saying:

“I’ve been working on an application that makes heavy use of Ajax, so much so, that without Javascript enabled the application is useless.”

I hate to say it, but the problem lies with how the application logic was planned and implemented from the start.

The issues of progressive enhancement and graceful degradation run through the DOM Scripting book. For those of you who have a copy of the book to hand, you can skip to the last chapter to read more on my thoughts about Ajax and progressive enhancement.

Posted by Jeremy on Tuesday, October 18th, 2005 at 2:00am


Well, how do you explain something like I mean, I can see how 90% of the ajax is being used in some way to streamline a common web procedure, but in a case like or a game, something that’s trying to replace a normal desktop app…I don’t see a problem with saying the app would be useless without javascript.

That’s not to say that I’m throwing all my unobtrusive javascript techniques out the window while I build my super secret ajax app….I’ve already adopted those methods as common practice for all the reasons you’ve stated. But I’m only using these techniques because that’s what I’ve become most familiar with.

# Posted by scott on Tuesday, October 18th, 2005 at 5:04am

Jeremy, all good points. I think we are looking at it from two different perspectives. Like Scott suggested, applications that are meant to be replacements for the desktop loose there characteristics when Javascript is disabled. I too am not throwing out all the degradable techniques and I’m still researching methods to keep the back button.

When I read post like this I ask myself am I in a state of denial like those who were opposed to CSS and XHTML before it was considered a requirement and not an extra.

CSS and XHTML we’re ways forward, like Ajax and Javascript are now but they are two totally different beast and I think we need more education on the benefits of degrading beyond the point that it’s just the right thing to do.

CSS and XHTML had many good selling points: * Faster page loading/Less bandwidth usage (time and money) * Ability to make 1 change in 1 file and have it applied globally (time and money) * Separation of style and structure (Technical)

I believe we’re approaching accessibility techniques such as degrading Javascript and other techniques like selling candy bars with plain white wrappers and only the ingredients is shown on it. It’s a hard sell to make this way.

How do we approach clients and say that we can build an application that will work for 95% of your audience, but in order to capture another 3% it will take X amount longer and cost you X amount more.

Do you think clients should be made aware of facts like this, or do we just do it transparently and answer questions later on why the application is taking longer to build? The fact of the matter is that is does cost time, and to tell a client that time isn’t money just won’t cut it. It is a business decision in my mind, and I have yet to be convinced other wise.

I appreciate all your efforts and others who are pushing for these techniques, and showing us methods to implement them. Implementation is the easy part, but when your not your own boss you have to have justification.

I’d be interested in hearing your comments on the cookie issue. Do we brute force track ip’s to bypass enhancements that cookies give us?

Kind regards, -Justin

# Posted by Justin Palmer on Tuesday, October 18th, 2005 at 6:09am

Justin, you ask:

"How do we approach clients and say that we can build an application that will work for 95% of your audience, but in order to capture another 3% it will take X amount longer and cost you X amount more."

My point is: it won’t! Unless you can get your head around that fact — that making Ajax degradable or building in accessibility doesn’t cost extra if it’s done from the start — then I’m afraid we are both going to be talking at complete cross purposes.

As for the selling points of CSS and XHTML, I’ve never, ever talked about them with clients: it’s just the way I build websites. They don’t need to be convinced of anything, they certainly don’t want to hear the details of the technology, and it doesn’t cost them any more money than if I used tables and font tags (quite the opposite in fact). It’s the same with degradable JavaScript. The term should really be a tautology: it shouldn’t enter our heads to do it any other way.

"Do you think clients should be made aware of facts like this, or do we just do it transparently and answer questions later on why the application is taking longer to build?"

Justin, Justin, Justin. I’m afraid that once again you are begging the question. You insist on believing that it takes longer to make degradable Ajax apps. That is only true if you haven’t planned the application logic correctly to begin with.

"The fact of the matter is that is does cost time"

That is quite simply not true. Or, at least it’s not true if you consider graceful degradation from the start.

Look, I’ve heard these same arguments before about things like accessibility and usability: Somebody builds a website and then tests it for accessibility; changes need to be made; those changes will take too much time; time is money; the changes aren’t made. Or: Somebody builds a website and then does some usability testing; changes need to be made; those changes will take too much time; time is money, etc.

It’s no different for degradable Ajax. If you come along after the fact and attempt to retrofit graceful degradation, then yes, it will cost you time and money and I can see how that would be a very difficult business decision to justify. But the problem lies with the process. That’s what I’ve been trying to say the whole time. This isn’t an issue of technology or time or money or business decisions. It’s purely about process and planning.

I know in these days of 37 Signals’ "getting real", words like process and planning are used less and less but I think they are incredibly important if you want to avoid incurring time and money penalties further down the line.

# Posted by Jeremy Keith on Tuesday, October 18th, 2005 at 11:00am

I think it’s just wrong to believe that the problem is simply due lack of planning. I certainly have spent months thinking about it and trying different things before I accepted that sometimes you have to sacrify something for a completely degradable solution.

I believe most of the time this is an acceptable compromise, but I also have no doubt in my mind that this might not always be the case.

I think we don’t disagree on usefulness or general preference. I think our disagreement is more or less limited to a difference between "always" and "most of the time".

Btw, I use a question "Would I ever want to bookmark this?" to make a quick decision between building a nicely degradable solution or thinking more about it.

# Posted by Marko Samastur on Tuesday, October 18th, 2005 at 12:39pm

Hehe, I admire your patience Jeremy, and I assure you your comments aren’t falling on deaf ears. ;-)

The point you make and that I completely understand is that this time shouldn’t be looked at as optional, it should be part of the planning just like planning the database schema or graphic design. It’s not the cherry on top, it’s part of the cake.

It would sound absurd to me if someone told me that we must use table layouts and no css because it cost to much time to do it otherwise, so I can level with you on your comments about it not taking longer.

I’m going to let everything simmer for a moment and I’ll get back with you.

# Posted by Justin Palmer on Tuesday, October 18th, 2005 at 12:59pm

Marko wrote:

"I use a question "Would I ever want to bookmark this?" to make a quick decision between building a nicely degradable solution or thinking more about it."

Good point. But I think that question is more useful in determining whether or not to use a solution like Ajax at all for the situation. In other words, the answer to that question helps answer the question, "should I use Ajax for this?" The finer question of whether or not that Ajax solution should be degradable should hopefully be a no-brainer. :-)

# Posted by Jeremy Keith on Tuesday, October 18th, 2005 at 2:19pm

A good question to ask yourself when developing ajax applications is "What is our fallback?"

If you’re developing something new, you might want to consider graceful degradation. More and more folks are disabling JavaScript these days than developers think. Believe it or not, my stats are showing a whopping 10%. That’s more than the global usage of Firefox. Degradation is not only a ‘best practice’ - it’s practical and logical. It’s the third element to cross-brower development - because now you’re developing ‘cross-DOM’ compatible.

If your application becomes so ajax rich, it may be better to create an entirely separate application for non-js users. Take for instance Yahoo! mail. There was basically no room for degrading such a large application. Way too much drag and drop, way too much server calls… building a degrading layer would make it run that much slower. So what happens - you get kicked back to Y! mail classic. Excellent idea! Then if you’re not on a modern browser that supports css, we even kick you back to the pre-historic classic Y! mail. This would be known as ‘application fallback’ and Y! does it because they can.

If ajax is built in a modular sense that can be used anywhere in any application, a developer should consider fallbacks for all their little widgets.

So, back to the question "What is our fallback?" - is it:

A) Graceful Degradation B) A separate application C) Unhappy users

I opt not for the unhappy user.

# Posted by Dustin Dia on Tuesday, October 18th, 2005 at 10:54pm

I think an important thing to note when we are talking about people complaining about it being "too hard / expensive" to make their new AJAXy application degrade is talent and experience.

If the people actually writing your application keep putting this kind of thing in the too hard basket and claiming it will cost more time / money, because they don’t understand how to do it right…

Well if it will cost THEM more time /money

This is a problem I am facing in my new job. I am designing a system, then the developers are claiming it is too hard. What hurts for me is that I know how to do some of the things they want to avoid (for me pretty easily) but for them it is outside their current skillset. Of course they have to build it, and maintain it so we have to make a compromise.

It is the same story as css layouts a couple of years ago, we just have to keep annoying people until they give up and learn how to do it right.

# Posted by scottbp on Wednesday, October 19th, 2005 at 9:18am

That’s a very good point. We’ve been kind of ignoring the human issue here. Let’s face it, "difficult" is a relative term. What seems straightforward to one person might be very hard for someone else to grasp

# Posted by Jeremy Keith on Wednesday, October 19th, 2005 at 11:33am

Another factor no one mentioned yet is QA time. If you’re really planning to support early versions of Netscape and multiple browser configurations, you’re putting a lot more burden on your QA people. This is one reason why it might make sense to block certain browsers outright. While I commend Jeremy for highlighting best practices we should strive for, I’m not quite buying the point that implementing them doesn’t cost extra.

# Posted by Adam on Thursday, November 3rd, 2005 at 1:16am

Sorry Adam, but you have missed the point entirely. Please re-read what I was saying. There’s a reason why I never mention specific browsers or QA time.

You’re still thinking in the mentality of "build it with all the bells and whistles first, then think about making a simplified version", whereas I’m talking about the exact opposite.

# Posted by Jeremy Keith on Thursday, November 3rd, 2005 at 3:48pm

Sorry. Comments are closed.

October 2005

Recommended Reading

XML Subscribe

Grab the RSS feed for this blog.

JavaScript API

Grab the RSS feed of comments for this entry.