That’s what Doug suggested when I asked him for a nicer spin on a something that was going through my head:
In a similar vein, the whole concept of AJAX is generally regarded as a hack. It is a way to simulate two-way communication in a technology built for one-way delivery. When something new comes along that more naturally accommodates two way browser-server communication, AJAX is gone. If it can be done with another language, use the other language.
When TO Use
Am I right? Is this narrow minded thinking?
No, that is most definatly NOT narrow minded.
The way I work is as follows, my basic design philosofy is that a website should degrade gracefully completly under all circumstances:
1) I design the page in HTML. It should look good, accessible and logical.
2) I write the PHP scripts/functionality I need.
At this point the site should be fully functional to everybody.
3) I style the page with CSS.
The same applies to CSS, if it is disabled, the pages are still viewable, readable and functional.
Everything in CSS and js is “added candy” to me.
Rarely I stray from this workflow (but sometimes one cannot help it). So it is not a set rule, but I do try to live by it.
Here, you are correct.
However, when you say:
You disagree with:
“If it can be done with another language, use the other language.”
It might muddy the water, but there is no real way of out of things if you want to have a cutting edge design right now…
You are definitely right!
I will quote you guys on it!
You make some valid points, but I’m going to have to take a different stance here (respectfully).
Client-side validation is a convenience for your user to not have to wait for the entire page to refresh to see they missed something, and you’d have to repopulate their fields if you didn’t want them to lose the data (or have the state saved in .NET which has a ton of overhead).
In summary, I would say that this post is good and you made some good points, but I think you’re looking at it the wrong way.
I don’t disagree with any of this, so I’m not sure how our stances differ.
Thanks for the post!
That’s pretty darn clever =)
Heck, that technique even preserves browsing history!
I think the statement “if it can be done in another language, use the other language” somewhat conflicts with the idea of graceful degradation and what Matthew is pointing out. For instance, form validation can be done solely on the server side, but the best alternative currently is server and client side validation. That way you have all the benefits of a cleaner and more responsive ui if js is enabled while still being able to fall-back on server side validation if it isn’t. The “use another language if possible” statement implies that you always should choose a js alternative if one is available and leave it at that. Graceful degradation on the other hand implies “enhance the experience with js, just make sure it is still functional without”.
You should check Stu Nicholls CSS light box:
CSS Light box.
It doesn’t work in Safari or Chrome, but it’s still very impressive.
I agree whole-heartedly with this article!
When JS use is unavoidable, that’s one thing, but using it when there are alternatives available, without providing fallbacks (especially for functionality critical to correct operation) is just bad design.
One of the common operations for which JS gets used frequently is popping up links in new windows. Avoid Those Ugly <a href=”#”></a> Links illustrates a way to provide an elegant fallback.
I think you should use both, but server side is mandatory.
Another vote for “you’re not narrow minded”.
The way I see it: Just because you can do it, it doesn’t mean that you should do it.
Anyone remember flash intros? The blink tag? The cursor trails?
Webpages should *always* be focused, in the first place, on content.
They should always provide a decent page for those who:
– Don’t have/don’t want Flash.
– Can’t display images.
– Can’t display CSS properly.
What you present here is definitely the rule that should be broken only in very specific, calculated use cases… not the other way around.
Whilst I agree with your premise, we need to work out how to educate the clients as well.
This might be too “elementary” of a statement but a simple “slider” can be done in flash but I despise flash so the “if it can be done in another language…” statement is disagreeable in this instance. Is it wrong to NOT use flash here? (If so, I’ll be doing it wrong).
Flash uses a different go-to statement:
“Don’t use it”.
(That is, unless you have a SUPER good reason and there is no alternative.)
haha, I love it. I agree completely. Unless your using video or audio, I don’t see many good reasons to use Flash.
I disagree. Proper use of flash can have thousand times more effect on the user than plain old html. Not just video or audio, (in case of audio, have you seen Yahoo Media Player? It’s completely with no flash!) but animation. And web apps! Flex is the most powerful I’ve ever seen.
I (and many other web savvy) users block flash by default. Using it for any kind of actual content to me is absurd (bar the regular uses e.g. video/audio). I’ve seen sites that use flash for navigation(?!), needless to say, I did not return to that site again.
I 100% agree with this. I do work on a PowerPC Mac sometimes. It’s very good for using Photoshop, it flies on it. My 1.0GHz G4 runs faster than my 2.8GHz Dual-Core AMD Athlon. I won’t go into why, since it’s a long topic…
But!, the flash player for PowerPC Mac is TERRIBLE. It’s incredibly slow, and any site I go to that uses sIFR crashes Safari.
I love that people like Flash, and that’s great. I’m a Flex Developer in my spare time, but I do believe that it is only good for niche websites (where you are 99% sure of your target audience or internal development) or wrap it in AIR and drop it on the desktop.
Very interesting, a philosophy I like to incorporate into my projects is to “use the right tool for the job at hand.”
I would much rather combine HTML with CSS to achieve effects because it’s lighter and users are less likely to have either disabled (if it’s even possible to have those other technologies disabled).
When it comes to forms, a server-side language is the way to go. Not only will people always get the server-side end of things, you have less security holes to worry about.
If I can get away with relying on HTML/CSS/PHP, then that’s the route I take. I want accessibility for my visitors, being pretty should come after. Naturally it only makes sense to make sure JS doesn’t hamper your website. Use it for enhancement, not core functionality that would break if a user didn’t have it.
disagree with “Form Validation” section!
For the form validation, you have to put your validation logic in the backend anyway. For whatever reason. For example, to build a secure app. the malicious user can easily bypass your frontend validation and post invalid data by plain http post. also, if you are build something big, you might possible have different frontend, webpage, desktop app, java webstart etc. the validation will be part of logic and has to be done in backend.
so backend validation is enough? absolutely NOT! To get a nice user experience, really couldn’t think any reason why we dont do the validation in the frontend. no matter how nice you did for the serverside validation (keep all entered data and highlight the error fields etc), it takes your user 2 seconds to see the results, by not mentioning some sites will lost all captured information.
I totally agree with you. However I disagree with some comments in regards to avoiding JS frameworks. (I used to be one of them) You have to face the fact that this is where the web is heading and I am very sure that JS Frameworks will soon be directly included into browsers or cached for all websites (You can do this today by using the Google projects link for instance). Also good compression and use of distributed content networks help speed up the site. Size and distribution of these frameworks still needs attention, but it’s the way forward. I can’t live without them as they open up a new world of better usability (And backwards compatibility for that matter!)
Um….2001 called – it wants its graceful degradation back.
The frameworks – I use jQuery – handle a lot of browser-related issues nicely, and have simplified writing JS code to the point it’s almost fun!
JS used to be seen as a fancy-pants way of doing flashy, but unnecessary things. That’s no longer the case. JS handles a lot of the workload on a lot of sites these days, making pages look and act much more professional.
As far as AJAX being a hack – well what isn’t a hack? It has changed the web completely and works incredibly well. Again, the frameworks make it a 3rd grade level task these days – simple as can be. Love it.
More than you think! Just because your brand new iPhone plays nicely with your JS doesn’t mean some dated S40 nokia will.
As an owner of such an old phone you can’t really expect the get a full web browsing experience. Only since the Opera mobile 9.5 and the iPhone browser came along mobile phones really get used for browsing. You can’t support every old phone, how would we otherwise ever progress?
“how would we otherwise ever progress?”
By following the “progressive enhancment” paradigm, not by completely locking out old sevices and browsers.
Lots of users use non-browser user agents. If you works from the bottom up, you ware always sure your pages load in ANY UA, not just browsers with all the bells and whistles on.
I don’t see it that way.
Great article !
“If it can be done with another language, use the other language.”
<3 JQuery :D !!
Every modern browser has supported it for many years now – and it’s no longer just a language for “useless UI stuff” – it has grown tremendously in recent years and the libraries are pushing the limits even further – and with cross-browser abstraction even.
I mean, hey – to each his own. But the “only for UI enhancement” argument just seems totally dated to me. I think we’re way past that now.
The 99.5% of my users:
– Have Java script enabled
– Use broadband connections
– IE 5? Who uses it on my website?
– IE 6, my scripts works without pain on IE 6.
– Lightbox’s improves user experience, reduces server requests.
should be done using a mix of server and client side validations. Is about a efficiency, why SPAM the server with simple petitions to validate simple things that can be validated on the client side such telephone numbers, ZIP codes? Let the Advanced Validation be done by the server.
I use JS to reassigning css classes to the content.
CSS are defined on the css files. But it lets the user to change the way the content is being displayed ( switch the position of the content.. play with the css on the fly). Customizable interfaces are almost a Must on some type of communities and websites.
Example: gmail, facebook
Well, if this the only way… then use JS & Ajax.
If using JS/ajax is a benefit, and it reduces the server load, OK, use JS.
This is one of those good rules of thumb that risks being having the nuance removed and taken as gospel.
I don’t need to repeat the very good points about great user experience being a requirement, not just icing on the cake. (but I guess I just did!)
I’ll add that as we enter a period where more and more types of devices and user agents are hitting our content, having a site or application that gracefully degrades is once again becoming important.
I totally disagree with this statement: “In a similar vein, the whole concept of AJAX is generally regarded as a hack. It is a way to simulate two-way communication in a technology built for one-way delivery. When something new comes along that more naturally accommodates two way browser-server communication, AJAX is gone.”
AJAX is the browser-implemented technology that supports two-way communication (without a new page load – you could always do this with simple request/response that is the core of HTTP). If you want two-way communication and don’t want to use AJAX, you can use Flash or i-frames. Now that’s a hack.
Absolutely agree. Ajax doesn’t need to be used, but it IS the current 2-way communication… and to be honest, it works well. If your server side responses come up fast enough, ajax can be an integral part of your website, and with either js or a js lib, like Dojo(I’m a fan), can be seamless and cool looking for a user.
Hold up a second here…
Some of the people “for” graceful degradation (at least one comment in this post, and countless thousands elsewhere) have argued that JS should be used for FX/eye candy.
When it comes to form validation, I tend to lean towards server side validation, but that’s probably because I work on Ruby on Rails where very little code is required for validation.
I agree with most of the points you make, but Ajax a hack??? I hope you’re kidding there, Chris. At the moment there is no alternative to Ajax that can be thought of as “not a hack”.
There aren’t any super practical alternatives, no. And I’m not saying AJAX is bad. I think it works pretty well and It’s very cool, but it’s definitely a hack, I’m not kidding at all about that. A hack in terms of “we managed to shoehorn this in pretty effectively”, not a hack in terms of “we really shouldn’t be using this. If we could start all over writing all the different web protocols and languages, you can bet the two-way communication stuff would be wildly different.
Yeah, we managed to shoehorn AJAX in pretty well – kinda like how we shoehorned in tables, CSS support, the DOM, etc. Maybe it was “shoehorned in” because it wasn’t in the first HTML RFC or maybe it was the natural progression of the technology.
Have you seen this CSS Light box by Stu Nicholls:
I think that for most situations you make a valid point. Client and server side languages are designed to serve a certain purpose by principal and will be most efficient that way.
It is however not about what engineers made up years back, but what the users / clients demand. If your client wants an online personality with a great accessible site, gracefull degradation is the way to go. There are other situations though.
It’s really important to look what the end-users demands are, that’s the only way you can optimize usability / functionality for them.
But if I’m building a complex, AJAX-based web app – how on earth is that going to degrade gracefully without writing 50 times the amount of code? It would be absurd to try to build a dynamic, interactive, and cutting-edge web app like a mashup using multiple API’s – say Google Maps, facebook, and Twitter on one page along with storing and retrieving dynamic data to and from your database – and have it degrade gracefully. Have fun with that!!!
Ok, I partially agree with you, but perhaps we should make a better distinction between web design and web development. Personally I am a web designer, and as such I have very little to do with web-apps. Besides, to me a web-app has very little to do with web-pages. A web-page is a page with information whereas a web-app is an application that works on the internet.
This is a great point. It’s hard to argue this stuff while being theoretical, that’s why examples are important.
This is probably the comment I most agree with in this article.
I personally am a huge fan and active promoter of Progressive Enhancement and Graceful Degradation as I’m a bit of a usability nut and I’m a firm believer that catering using basic principals can make design and development so much simpler in the long run.
However, the browser has in a way gone full circle in what it’s used for, it was originally an interface for handling simply HTTP and other protocols, then as ‘web design’ and ‘web sites’ kicked off it became about serving ‘pages’.
Now, coding effective HTTP requests is a lot easier and as Brett says I think it is very important to define things like web ‘Apps’ as being very different to web ‘Pages’, a blind person wouldn’t insist on having a way to use Photoshop!
I totally agree with your post,
That’s the way i tray to work :-)
This is so absurd!
The point is, the browser is indeed becoming the operating system and will interact with the user completely within web apps. Browsers are not just for displaying text and images for clients to read any longer.
Those libraries are being abused, and I am starting to fear the whole DHTML era all over again. I am still trying to forget those awful animations.
I agree with you in part. I don’t think any business wants to know their site doesn’t work somewhere. However, the more people you want to include in your support, the larger the cost and time of the project becomes. It think it is important, especially in business cases, that you outline just what should and should not be supported (or who should and should not).
Partially disagree with two points, fully agree with one:
1. Yeah, you should always validate on the server side. That kinda goes without saying if you want good data. However, JS is useful for quick validation feedback without a server roundtrip to give the user quick signals about whether their input is useful. Example: if you validate an “email” field when a user blurs it, you can highlight it in red if it’s a non-valid email. This cuts down on bad form submits. JS form validation should always supplement server side validation.
2. Ajax is not really a “hack”, it’s a tool that should be used when it’s appropriate to request page content without a full page load.
An example: on a site I work on there is a menu in every page that is hidden until a user rolls over a menu item. The content in the menu comes from a slow webservice. I don’t want to slow down every page load by forcing every user to wait for the Webservice, so I only request that content if the user invokes that menu. Good usage of AJAX.
That being said, I see a lot of developers making AJAX requests when they simply could have their additional content hidden in the page and just shown when appropriate.
3. Yes! JS should not apply styling. A pattern I use a lot is to have JS apply a class and keep the rules in the stylesheet with all my static content rules. That way you don’t have to go hunting for styling in your scripts, it’s all just in your CSS.
Try this in the new YUI 3, it’s amazingly easy.