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.”
Bingo!
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
Comments
Well, how do you explain something like meebo.com? 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 meebo.com 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.
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
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
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
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.
Sorry. Comments are closed.