“What does the client know? You’re the expert and so you know what’s important and what isn’t.”

I hear you James and what you’re saying probably holds true for small to possibly medium sized projects but when you’re working on projects in excess of 500k the client has no choice but to get involved. If the investment is large, the client will need to know where and how each dollar is being spent as well as the rationale behind your recommendations.

“What I’m saying is, there are some things the client shouldn’t be told about, because if they are told then they’re likely to make the wrong decision.”

It’s not uncommon practice for projects with large investments to bring in expert consultants for the duration of the project, so not giving full disclosure usually isn’t an option.

I guess what I’m saying is that what you’re saying is true… just not for every project.

All I’m saying is that everything isn’t always cut and dry. It’s not always as easy as replacing onClick() with a $(a).click().

Please don’t misunderstand me, but degrading isn’t always the answer. A totally new version is sometimes needed. Degrading just may not fit the layout that is required.

“The cost of building to that expectation AND having it gracefully degrade is quite large. Large enough for a client to make the decision that they won’t pay for users who aren’t browsing with javascript.”

What does the client know? You’re the expert and so you know what’s important and what isn’t. I know it’s different with large firms and agencies but I would never lower my standards because of one ignorant client. What I’m saying is, there are some things the client shouldn’t be told about, because if they are told then they’re likely to make the wrong decision.

@Kevin,

“However, some functionality simply doesn’t degrade well.”

Please specify…

“whatever you do, the client needs to pay for it”

This is true in principle but it doesn’t negate the importance of graceful degradation.

However, I will agree with “Some Idiot” here and say, whatever you do, the client needs to pay for it. There is also some burden on the web developer to educate their clients.

The whole iPhone topic raises an interesting point: When do we degrade and when do we build a separate version? Sometimes the latter is far simpler.

And while that’s true. I certainly wish the reality was otherwise because I agree that it’s a web developers responsibility to build intelligently. Given a rich enough UI, the cost is just too prohibitive.

University, Library, Company / Corporate, School computers and networks were system administrators have disabled JavaScript, or where it has limited functionality (ajax and cookies disabled), and keep running IE6, because it works for them, they haven’t had any problems with it, and they’re lazy, and there’s no budget for upgrading, so why would they care.

It’s not about the 0.1% that intentionally turns off JavaScript. Ensuring backwards compatibility (i.e graceful degradation) for a web application isn’t hard or even time consuming if you design it the right way, and have the proper knowledge on how to do so.

Conclusion: As long as all basic content and functionality is accessible, that is OK to me, oh and don’t get me wrong. I love JavaScript 🙂

As long as software is advancing, backwards compatibility will be an issue! What is new now will be old in a year and users who are still using what is currently considered new will have to be catered for.

I purposely didn’t mention the iPhone in my post because it really is a whole other argument. Every time some big-shot company brings out a new product we have to (with no warning) jump on the bandwagon and develop for it…

@Antione, the problem is that these technologies won’t be standardized across platforms/software for quite a while, well, this is what I fear anyway…

Mobile phones are absolute hell to develop for. Constant testing is required which really makes it take ages, plus what renders correctly on one device will render differently on another, even if they’re both using the same browser! Opera mobile is great but it’s still a compromise – Opera proxys most of the data to strip out unnecessary stuff (they say it saves their customers bandwidth and money). Like I said to Carlos, unfortunately, as long as software and technology advances there will always be a need to be backwards compatible.

That’s frustrating when I want to check something with my phone (Windows Mobile) and the site expects JavaScript for basic functionality. It’s already a lot better with the latest Opera, but it’s still not like we are browsing with a desktop…

The line between web sites and web applications has blurred significantly over the past few years. In 2004 I would have agreed strongly with you. But the power of Javascript is undeniable, and not only web applications but Web servers and the communication of content nowadays is relying on functioning Javascript.

Regarding your reasons for users consciously disabling Javascript, or corporations or firewalls doing so, I’d be curious if there are any mainstream mass-market Web sites (Amazon, CNN, etc) nowadays that don’t rely on the use of Javascript. Every year the additional cost of making the functional Web site backwards-compatible is going to be less tolerable. Someday these mainstream Web sites shouldn’t have to worry about users that use very old browsers.

Your points about screen readers and mobile devices are valid, but often the easier path is to build an alternative site that caters to those device capabilities. As good as the iPhone is in rendering regular Web sites, companies are CHOOSING to spend money to build iPhone-specific sites that better suit the usability principles that device encourages.