Over at Encytemedia, Justin Palmer wrote Dispelling the Myths of Javascript Degredation where he questions Particletree’s reasons for going degradable. He makes some valid points, and I just wanted to go over our stance to open this up for more discussion. When creating the store for Treehouse, we decided to make it degradable. Why did we decide to do so when it is pretty much guaranteed that our audience has JavaScript enabled?
Ajax is relatively new, and so is our experience with it. On the other hand, we have plenty of experience with normal web pages. By making a non Ajax version first, it is easier to iron out bugs, and create a reliable version. If we had jumped straight into Ajax, we would have been left with more bugs and an unstable site.
When we we’re working on the store, we had a very nice Ajax interface working in Firefox and IE. Just before launching it, we had to take all of it out because of Safari, Opera, and Netscape. If we didn’t have a degradable version to fall back on, we would have had no store at all. Now, we can easily go through and start adding features in small chunks and make them work in all browsers.
We’re getting much faster at making a degradable page. Soon, and with the help of XSLT, we’re hoping that no additional work needs to be done. If we can get to that point, then why not make sites degradable?
We would like to start calling Flash files with JavaScript. This means users must have Flash and JavaScript enabled. This will increase the percentage of people who can’t see our site. By having a degradable version, it is easy to default back if either is disabled.
Regardless of those points, it is tough to make the argument. Personally, I am not convinced degradable is the way to go, but I think it is worth seeing through because it could help in the future. Just the same, the future could turn out to be a web where JavaScript and Flash are a must. What are your thoughts on this?
I think Justin also makes a very interesting case about building applications that are cookie dependent. I believe some believe we can answer those concerns with flash (which usually gets about a 98% browser penetration within 2-3 years of releasing a new version of the player) or by brute force tracking people by their IP address (ala google). Not ideal because one is just another requirement and the other takes access to resources.
I think the case for degradation is an easy one now because we’re in a period of transition. Years from now, having JavaScript turned off will probably be a thing of the past, but until browsers are a bit more uniform and reliable in their implementations of specs and standards, I think it’s always best to be safe rather than sorry.
Also agree on the case for graceful degradation of JS in as many cases as possible, even if a good majority of people have it enabled.
Now I wonder if there’s a fallback in the case of cookies… Query strings maybe?
Thanks for elaborating a bit Ryan. I think the question of ease certainly impacts the decision to degrade because it has a business impact. We wouldn’t have to pull out near as much hair while reaching the conclusion to degrade a contact form.
Another good point to make is how we as a culture determine what’s optional on the web or the desktop for that matter? Referring back to The Man In Blue’s post, he addresses this. I think it has a lot to do with making the distinction between an application and a web page.
When a user makes a conscious decision to purchase Windows, they wouldn’t have a valid argument if they couldn’t run OS X apps. There is a double standard in play for web developers. If a user makes a conscious decision to purchase an application that you’ve built, why is making Javascript a requirement a bad thing? There has to be line drawn in the sand at some point.
Kevin, good points on the cookie issue. Sessions exists on the server (whether in the file system or database) and only persist beyond that if we write cookies to the users machine. However, should we fall back to basic to single session persistence or brute force ip tracking to make our applications and websites usable for those with cookies disabled? It’s possible, but has yet to be labeled as practical.
Just keeping you guys on your toes! ;-)
A site should be where possible available to any user-agent and any user. Derek FeatherStone suggested at @media2005 that screen reader users should turn javascript off based on the fact that current screen readers struggle to interpret data changed by client side scripts.
I think that where possible apps should be made in a way that means they still work without javascript being enabled and that any use of AJAX should be to enhance the existing functionality rather than be the sole functionality of the app.
Even google maps has a fallback to search engine style map results when javascript is turned off. Try it!
Degradable’s the only user-friendly approach. A perfect example is GMail. Virtually all the links are done with spans and onclicks instead of real links using the a element type. What’s the problem - surely everybody using GMail has Javascript enabled? Well sure, except for the fact that when I middle-click to open in a new tab, it just breaks. There’s no sensible behaviour because the idea that a link can be activated without the javascript being run never occured to the Google developers.
There are so many instances of this happening, where a person using a perfectly capable browser was given shoddy treatment simply because the developers were too short-sighted to think of “non-standard” interaction, that I’ve given up counting. It’s a mindset like this that gives rise to breaking back buttons and the other annoyances that people have to put up with all over the web.
I’d also question your assumption that technically minded people are more likely to have Flash and Javascript enabled. If anything, I’d say the opposite is true - the technically minded are the only ones who know why and how to switch these things off.
Just one more thing - from the supporting article you linked - disabling Javascript “renders most of the web useless”? Simply false. Try it sometime, Justin. The sites that break are a small minority.
>There’s no sensible behaviour because the idea that a link can be activated >without the javascript being run never occured to the Google developers.
I’m not sure I agree with you here Jim. The Google developers did consider users that don’t have Javascript enabled (albeit eventually - the basic html version came later). If you try to access Gmail with Javascript turned off you get asked if you wish to use the plain old html version.
The GMail plain version is a good example. I’m a web developer, so I know why it’s happening, but why on earth would a regular user think of going into their account settings and switching on the plain HTML interface so that their links work correctly? And why should this compromise be necessary? I’m not using an old browser that can’t handle Javascript, I’m using a modern browser in a modern way.
My point is that Javascript support isn’t a question of whether it is on or off. It’s a big grey area. JAWS executes inline event handlers but not event handlers added through the DOM. Typical web browsers execute onclick handlers for links when they are activated normally, but not when they are opened in a new tab or a new window. Internet Explorer supports XMLHttpRequest when ActiveX is switched on, but not when it is switched off.
There isn’t a sensible point at which to say “this user has Javascript available” - as the examples show, even in situations you would normally consider to be “Javascript on”, common user interactions bypass the Javascript. All you can do is offer optional improvements should the user-agent be in a position to take advantage of them - i.e. graceful degradation. Once you start assuming that the Javascript will be executed, you break things for people - even the ones using modern browsers with Javascript switched on.
The decision to make an AJAX based application depends entirely on the intended user of your application. Most dyanmic websites that I develop have an admin area and a front-end. When I design the admin area, the access to it is limited, so I can require JS enabled browsers for it to function properly, and my clients accept that. The front-end though, if it is accessible to the general public, does not have that “freedom of limitation”. It would seem to me that AJAX methods are most useful in a targeted application anyway, and that requiring users of your application to have JS enabled is no more restrictive than requiring a USB port be available when trying to use a USB device. If you don’t have it you can’t use it. Simple.