Validation – Client or Server-side?

I used to be pretty fanatical about implementing both client and server-side validation, however recently, I have stopped bothering with client side error messages almost entirely. The conventional wisdom is that client-side validation is necessary because it:

  1. Gives your users instant feedback.
  2. Saves CPU cycles.
  3. Lowers bandwidth use.

While all of these things are true, it is also true that:

  1. Client-side validation adds coding and QA time to the development process.
  2. Large amounts of JavaScript (which are often required for validation frameworks) also use bandwidth.
  3. Thanks to CSS-P, pages can be small enough that reloading them doesn’t have to take as long as loading Amazon.com.
  4. You have to do server-side validation in addition to client-side validation anyway since client-side validation can always be bypassed.
  5. JavaScript alerts can be alloying and less intuitive than well positioned, verbose server-side error messages.

In my experience, the amount of additional CPU cycles and bandwidth required to process requests with data that does not validate is really quite negligible (if it weren’t, I would say your app is not as user-friendly and intuitive as it should be). Additionally, I would personally rather reload a page and get clear instructions on exactly which fields need attention rather than instantly get something less helpful. DHTML solutions (which I have not experimented with extensively) may be a good compromise, but I think you would need to come up with a very solid framework to make the additional development costs such that they are practical since data must still also be validated on the server.

What are your thoughts on validation?

19 Responses to Validation – Client or Server-side?

  1. Mark Haliday says:

    Couldn’t agree more. Plus the fact people can turn off Javascript (more and more are doing this due to pop-ups and virus’s). It just makes sense to put all the validation on the server. HOWEVER, I think this is where Flash comes in. You can do client side validation in a RIA and know that the validation will run. Flash apps also offload some of the work back to the client.

  2. Rob Brooks-Bilson says:

    Christian, have you checked out qForms (http://www.pengoworks.com/index.cfm?action=qForms) from Dan Switzer? It’s a really slick JavaScript API for form validation. I’ve been using it for a while now, and I find that it doesn’t add a whole lot of additional time to my development time.It’s very flexible, and does a great job of providing useful feedback to the browser.

  3. Scott Keene says:

    Interesting point, Christian. I have always relied on JS client-side validation coupled with server-side validation, and it’s always seemed kludgy to me, but was always chocked up to the “conventional wisdom” you mentioned. I think there still is a lot to be said for client-side validation (and I still use it), but I definitely think it is time for a new paradigm.XForms. That’s our hope for the future!

  4. I switched completely to server-side a while ago. I developed my own validation platform, a pair of custom tags, and said goodbye to cfform and unreliability forever. Personally, I just hate javascript alerts, and I like to see all the fields I need to correct at one time. It seems more user-friendly, and it works with all browsers, which is a huge benefit for my company.Yes, in the future we can rely on flash and xforms more, but for now i’ve given up on javascript validation.

  5. Erik says:

    I understand the issues and woes of client-side vs. server side validation issues, though what interests me the most is more of a slient combination between the two. Take .NET for instance, a combination of HTTP KeepAlive & client side specific controls create a pipe of client/server interactions – fascinating stuff, really, when you think about it.What I’d dream of seeing is using an invisible flash control to act as some sort of data pipe – kind of like switzer’s WDDX remote gateway. Perhaps their may be architecture issues with this, but at least it attempts to bridge the gap between client and server. Each form of validation has it’s pros and cons, perhaps melding the two will be the best of both worlds? Just a thought…

  6. Mike Brunt says:

    Good subject Christian and something that we have been looking at. We do use qForms by the way as mentioned in this thread; it’s as good as it gets in JS in my opinion. However I do think that JS can get really untidy and often does. I think trying to do what is best for the user experience is paramount and I do avoid JS where possible.

  7. paulH says:

    yes, i agree w/rob, qForms is quite nifty. you can even do some db lookups, etc. with it for those really complex validation requirements (though i’ve only ever used this in production on intranets). i highly recommend it.i don’t think validation will ever be just one or the other. what would you call a flash form doublechecking stuff via remoting?

  8. Andy Jarrett says:

    I’ve only just started using qForms recently actually. Till now been i’ve writting my own tid bits for Js and putting the emphasis on the server-side validation. My opinon on it is keep Js validation for most things. I mean you can check all text fields have at least one character with 4 lines of Js, so why bother doing the round trip to the server.QForm is also just an amazing tool anyway and makes this job simple aswell so why not implement it and let the user know then and there whats wrong with the form. Plus you can alway be annoying to the people who have Js turned of by getting Js and document.write to write the submit button ;o)

  9. Nolan says:

    My only problem with server-side only validation is from a user perspective when I’m on a slow connection. Remember there is still a big percentage of people out there on 56K (and slower!) surfing the net. I’m sure these people appreciate knowing when they click “submit”, the page is going to go through and DO something, not spin for 3 minutes and tell them “you forgot to specify a zip code”.How fast are the wireless browser devices now? Are they all on T1s? Somehow I doubt it.Are you building trade show registration sites? When people register, the majority of your visitors may be in a hotel room, on a dial up connection with a poor quality phone line (a realistic scenario one of my team members had to deal with just 3 days ago).Perhaps server-side and/or client-side validation is best addressed on a case by case basis, depending on the site and the realistic audience.My .02-nolan

  10. Christian Cantrell says:

    Nolan, I agree that looking at each application’s individual requirements is the best way to go. For the types of apps I’m generally working on, server side is sufficient, however I do throw the occasional client side confirmation and alert in here and there. I think DHTML error messages might have some promise. I’ll have to mess with that some time soon.

  11. Vui Lo says:

    qForms is in fact the best js Form framework that I know of. Besides the robust validation routine, at form initialization, it can also configure field dependencies, data “binding”, attach events to inputs, set disabled fields. Of course, you can also set customized error messages on validation. I’ve spent only about a week on the API and have already developed a MVC Form Client model with CF tags.<!— business model to client-side model —><form:model name=”form1″>     <form:data objName=”user” value=”#user#”> <!— transform struct to js Object —></form:model><!—// end model —><!— client-side form controller —><form:controller onsubmit=”hello” wddxPacket=”true”>    <form:controlledItems validator=”#validator#” dependency=”#dependency#” disabled=”#disabled#”>    <form:controlledItem name=”income” validation=”Numeric” required=”false”>    <form:eventHandler type=”onChange” handler=”income” invoke=”setIncome()”>    <form:eventHandler type=”onClick” handler=”pickImg” invoke=”popIFrame()”>    <form:bind collectionList=”user”>    <form:bind name=”income” value=”#Evaluate(income[“2003”] + income[“1001″])#”></form:controller><!—// end controller —><!— remoting —><gateway:client remoteHandler=”clientSample_wdxjs.cfm” onReceiveHandler=”updatePoll” onStartup=”getPoll()”/><!—// end remoting —>I also use the Gateway js API from the same author. I’ve combine the concept of xforms model and the concept of MachII to arrive to this qForms MVC Form client. Of course, the data binding part is not what’s in xforms, still the concept is the same.There is also one other js validation API, fValidate http://www.peterbailey.net/fValidate/new/, which provides a friendly error message, kind of like the web forms on Macromedia site. However, the API only deals with validation routine.In my opinion, client-side validation is still viable and can be easy too.

  12. Kola Oyedeji says:

    I dont actually agree. For high traffic sites which perform really slowly it is a pain to have to wait for a server response to be informed that field xyz has not been completed. In addition to this there are still may websites – to my disgust which still insist on displaying one error message at a time. Using server side validation only this is very,very annoying. On the other hand the problem with a javascript pop up is, even if it does display multiple error messages, these are only visible until you click ok on the alert box. After that you have to remember which fields were responsible for the errors. I think the ideal option would be to use javascript to highlight the fields and or display a list of errors at the start of the page but using javascript to display the error message but *not* in an alert – perhaps using dhtml/flash. Finally there is a custom tag api terraforms which generates both client side validation (using q-forms) and server side.

  13. Kurt Wiersma says:

    Does anyone have a favorite cf custom tag for server side validate that they use to replace cfform’s poor implementation of server side validate?

  14. Kola Oyedeji says:

    Have a look athttp://www.electricsheep.co.nz/terraform/Looks very,very good although i havent yet used it myself.

  15. Gyrus says:

    Have to second (third? fourth?!) the big-ups for qForms. We’ve just created our own library of custom tags for creating forms (our own CFFORM et al I guess), and integrated qForms into it. Now we don’t have to think about client-side validation, it’s just bundled in.The qForms script is quite sizeable (about 25K even with whitespace stripped I think), but I suppose it gets cached, and we’re mostly dealing with backend CMS apps. We leave complex validation to the server-side scripts, but even basic integration of qForms seems worth it. Seems good to catch all basic errors client-side.

  16. Alex says:

    Just curious here:How are people determining how to validate form fields on the server side? Are people using CFFORM, or do others pass validation instructions (WDDXPACKETS?) hidden along with the form to the server side process?Just curious to see what others are using!

  17. Re TerraForm: yes it’s our company’s response to form construction and server-side validation, and as far as I can see it’s quite ahead of the game. It’s quite like cfform but fully extensible and server side. This might sound like an ad but I want to try to explain the logic behind the design. Personally I think CF has neglected forms for too long and this is the kind of thing I think should be built in — but unlike cfforms it needs to be flexible and extensible.TF uses a pair of custom tags (one for the form and one for each field). Validation instructions are included in each field. An alternative, elegant approach (similar to XForms) would be to keep the validation info completely separate, and perhaps simply use a regular HTML form. But then how do you get data back into the form fields when the submission is invalid? You could either use JS (bad answer) or you could insert cf variables into each HTML field. But then HTML markup for fields is quite frustratingly inconsistent, (text field vs multiple select field for example) so things would get really hairy. On top of that there’s the fact that so many essential form widgets are missing from HTML.Those are the primary reasons we decided to take complete control of the form, which has turned out to be a good, powerful answer. But we made sure you can get in there and edit or create new types of field. The one downside is that you can’t really simply add TF to an existing form, or remove it, like you can with qForms. In this way, switching to TF is much like switching to cfform tags.I think qForms is great too, and that’s why TerraForm includes native support for qForms.

  18. Buy.com says:

    QForm is also just an amazing tool anyway and makes this job simple aswell so why not implement it and let the user know then and there whats wrong with the form. Plus you can alway be annoying to the people who have Js turned of by getting Js and document.write to write the submit button ;o)

  19. Lelala says:

    I’d say, validate everything on the server – only doing it that way one can be absolutely sure that there is no nonsense in the content.
    Even if you have a full blown client-side validation script, you are better off doing it on the server – everything that can be manipulated by clients/users must be done/rechecked on the server.
    Regards