23

This question already has an answer here:

Through the years I've worked in web development it's been ingrained in me that client-side validation is absolutely and completely necessary in all web applications. Seems to me like all the people in the profession are very adamant on using it every single time. The most commonly mentioned benefits are:

  • Instantaneous showing of form errors
  • Less unnecessary requests to the server

But as we're moving towards the modern web, more and more applications are AJAX based. The simple task of submitting forms takes a lot less time now than it did before and validating on the server and returning errors barely impacts the user experience.

Could it be justifiable to completely avoid client-side validation (for example) on an application that only contains small and simple forms?

EDIT: I would argue that the linked duplicate question doesn't really capture the same example I'm giving here. A lot has changed since 2011. All of the answers on the related question are arguing for user experience whereas in my question I'm describing a scenario where the user experience would be unaffected.

When client-side validation no longer improves the user experience does it continue to rank in the same level of importance as before?

marked as duplicate by gnat, user22815, Scant Roger Nov 19 '15 at 6:00

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 21
    I would argue that server side validation is the only type that is "absolutely and completely necessary in all web applications" as client side can be bypassed completely. Either way, it's not too hard to do both. – Richard Dalton Nov 18 '15 at 8:54
  • 1
    What are the positives of not having client-side validation? – Ash Burlaczenko Nov 18 '15 at 13:01
  • 2
    @AshBurlaczenko - faster initial requests - we download a lot of Javscript for most client side validation, so much so that in some cases we're adding more overhead than a simple server side validation would be... and we're doing it on every request, not just the validation request. Also potentially providing a more consistent UX (for users without Javascript etc). – Jon Story Nov 18 '15 at 13:59
  • 3
    His point was that we can do an ajax request/response for the form validation rather than a full page request - eg the form request/response is much faster. So the tradeoff is one big request versus one smaller request, plus several tiny requests. In some cases, the latter may be faster – Jon Story Nov 18 '15 at 14:24
  • 1
    @AshBurlaczenko I spend a lot of time on unreliable and very speed-constrained internet connections, in hotels with faulty wifi or on third-world mobile phone providers limited to GPRS. Those big JavaScript libraries can make a page completely unusuable, particularly if the form cannot be submitted until the library has downloaded. – Calchas Nov 19 '15 at 1:07
64

Server side validation is absolutely necessary. Client side validation is purely a user experience improvement since the same validation should always happen on the server anyway. After all, you can always disable JavaScript or simply post arbitrary data directly via HTTP.

If you can provide server side validation which gives just as smooth a user experience as client side validation, you don't need client side validation.

  • 28
    agree. its a big 'if' though! – Ewan Nov 18 '15 at 9:23
  • 4
    ...Client side validation is purely a user experience improvement... I would argue that client side validation is more than "just" UX. Client side validation can save round trips to the server... save data, server cpu cycles, delays in response, etc. Server Side is MORE important - because you just can't trust them dang clients - but Client Side has MANY reasons for being needed. – WernerCD Nov 18 '15 at 16:41
  • 3
    @WernerCD If you stretched a bit, you could group all those under UX. After all, performance is part of the UX too, right? ;-) – Riking Nov 18 '15 at 18:32
  • 1
    @Riking Depends on what your definition of is is I guess lol. I think most of the reasons fall into more than one bucket. Increased response time would be UX, but decreased server utilization would be UX and infrastructure. Decreased data would be UX, costs (Mobile Data costs money these days), infrastructure (lower server requirements), etc – WernerCD Nov 18 '15 at 20:03
  • 1
    Server-side validation is a must, client-side is a bonus. – Ismael Miguel Nov 18 '15 at 21:47
25

While I agree with JacquesB, if you can provide the same level of interaction server side, then client side validation isn't always needed - however some other points to consider.

Point A (Speed): Client side validation is intended to be instant, as in 100% instant. While network speeds are improving, you're unlikely to be able to guarantee that this speed will be constant, and for everybody. Client side validation will generally always outperform the latency of a network request.

Point B (Performance): Server side validation, by definition is performed on the server. If you're working on a high traffic application on a budget server then saving additional requests no matter how small can make an impact in overall performance. Especially if we consider Point A where the latency can lead to multiple submission from the user, awaiting feedback.

Point C (Flexibility): Some validation isn't necessarily based on the value of a field, but can be based on the order or mechanism or populating a field. For example if a user copies and paste's into a password or email field, commonly this is nullified by javascript. This level of validation (which I believe this functionality still falls under) couldn't be achieved server side.

When client-side validation no longer improves the user experience does it continue to rank in the same level of importance as before?

While this is a valid question - it's alittle too abstract to answer yet. It's hard to imagine in the next year or so that this will ever become true, and as Point C covers, client side validation is often used to validate the users behaviour, not just values, which again is hard to imagine being managed server side.

Finally, as everybody already knows. Client side validation isn't robust enough to use solely on it's own. So just to reinforce the point, don't rely on client side validation without also checking server side. This includes javascript validation and validation included in the HTML5 spec built into certain input types.

  • 14
    "For example if a user copies and paste's into a password or email field, commonly this is nullified by javascript." This drives me insane. It actually reduces security, by making in painful to use randomly generated password. – Siyuan Ren Nov 18 '15 at 15:05
  • 4
    @SiyuanRen it drives me insane also. I had no idea until I read this answer that devs were intentionally inflicting this pain on users. Next time it happens to me I hope it is something I'm optionally signing up for/into so I can let them know that they've lost me as a customer. – Tony Adams Nov 18 '15 at 15:08
  • 3
    @samuelmr What is their justification for that? – Paŭlo Ebermann Nov 18 '15 at 19:48
  • 1
    @PaŭloEbermann Suspend your disbelief and pretend that there is a reason to restrict passwords to a maximum length - which there isn't. If the password field on the account creation page silently truncates and the password field on the signin page does not, then copy/paste would allow the user to create an account for which his/her password is invalid. If you don't understand why the two password fields don't have the same behavior, keep drinking beers until you have the same intelligence as the people who think passwords should have a max length. – emory Nov 18 '15 at 21:53
  • 1
    @emory passwords should have a (very high) maximum length. Hashing a password is (or should be) an expensive operation. A user just setting a rediculusly long password can denial of service attack a naive site. – Richard Tingle Nov 18 '15 at 22:57
4

Try high-latency connections

While rapidly firing a tiny AJAX request to do some on-demand server side validation may seem just as fast as doing it with client side javascript, having the same user experience, it is only true because you have a comparably good internet connection.

Some of your users will have internet connections that for various reasons are slow, unreliable, high latency or a combination of this. For them, this approach to validation will noticeably worsen the user experience.

It is often a good idea to run at least some usability testing with an artificially worsened network connection (there are tools to simlate that), so that you'd understand and have a chance to fix UX in such situations.

  • I agree - using any SPA with latency ~500ms is pure pain. – Ginden Nov 19 '15 at 0:22
  • With a slow connection one has to download the whole JavaScript validation library though. If the latency is high probably this is a drag as well. – Calchas Nov 19 '15 at 1:13
  • 1
    @Calchas the user can be on a high-latency, high-speed connection, as is usually the case of mobile connections where I live. Each request takes some seconds of overhead but loads almost instantaneously later, now imagine that happening on every field you fill - not nice – Délisson Junio Nov 19 '15 at 2:38
  • @wingleader An alternative would be to dispense with the client side checks altogether on a slow connection. – Calchas Nov 19 '15 at 9:54
1

It's still a very good idea to do "well-formedness" validation on the client-side...i.e. you expect a number, and encounter an alpha character, or a selection isn't made that renders the submittal moot...and of course, empty fields.

Doing business logic validation client-side is becoming, as the OP ponders, somewhat anachronistic these days, depending on the architecture. If your user interface is pure VIEW, with little or no MODEL or CONTROLLER aspects, then validating business requirements for data client-side is almost moot.

Not the answer you're looking for? Browse other questions tagged or ask your own question.