25

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?

Alternatex
  • 1,033
  • 2
  • 13
  • 24
  • 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 08: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
  • @JonStory One of the main points in the question is that requests/response are much faster so I don't think that's a valid argument. With the speed of connections nowadays, I doubt some extra bytes are going to be noticeable. Especially when it's likely the response is already bloated with other libraries needed for the page. The validation code is likely to be a very small percentage of the total page size. – Ash Burlaczenko Nov 18 '15 at 14:22
  • 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
  • I don't think any programming technique is important **always**. – GrandmasterB Nov 18 '15 at 21:15
  • 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 01:07
  • 1
    "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." You're assuming everyone has broadband/fibre. Try it on a mobile device with GPRS, and see how much it impacts the user experience. – Gavin Coates Nov 19 '15 at 09:15

4 Answers4

65

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.

JacquesB
  • 57,310
  • 21
  • 127
  • 176
  • 28
    agree. its a big 'if' though! – Ewan Nov 18 '15 at 09:23
  • Furthermore, there are some things that cannot be validated on the client side (e.g. whether a specified value exists in a database or not), and yet these features can be made usable. It follows that client-side validation isn't a usability requirement *in general*, although it might be made into a requirement for specific things *other* than the ones that can't have it. – Steve Jessop Nov 18 '15 at 13:29
  • 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
  • There are many situations where client side validation is essential. If the user requires validation offline in order to fulfill business requirements. e.g. salesperson uses date of birth validation to determine if they are allowed to sell to someone. If the server is offline for any other reason - outage. If the server limits API calls (eg. Salesforce). Failure to apply client side validation can also weaken security substantially and compromise the client and server. Opens up to spam, pass-thru of attacks. – Bradley Thomas Nov 18 '15 at 23:27
  • @BradThomas: Client side validation can always be circumvented, so it cannot and must not be essential. – JacquesB Nov 19 '15 at 07:46
  • @BradThomas: You can (and should) perform date-of-birth validation on the server. – JacquesB Nov 19 '15 at 10:48
  • What if your business requirement is such that sales doesn't grind to a halt when you are offline? Where do you validate then? – Bradley Thomas Nov 19 '15 at 19:11
  • @BradThomas: If you are offline you cannot place an order anyway. What does it help you can validate a form locally when you cannot submit the data to the server? If you want an app which can run fully disconnected, you shouldn't use a web app in the first place. – JacquesB Nov 19 '15 at 19:26
  • Salesperson might go through the whole process, wasting time, as a result of the client not validating date of birth or some other field. It may be that the person is simply not eligible for a sale, but if the client does not validate then in order to continue the sales process while offline, the salesperson has to do the validation manually. With respect to your second point, are you telling me that applications that need to operate offline sometimes, should never be internet connected apps? You are saying that if an app needs to operate offline at all, it should always be offline? – Bradley Thomas Nov 19 '15 at 22:10
  • @BradThomas: No, I'm saying that if you want an app to be able to function without network connectivity you shouldn't design it as a web app. A desktop app could be designed to function without network access, but still be able to connect to the internet when possible. – JacquesB Nov 19 '15 at 23:19
  • Ok, I see what you are saying, but where does this leave the plethora of apps that are really native apps but are built as web apps e.g. using Cordova. People are widely using web technologies, eg HTML5 to develop apps that need both online and offline functionality these days, because of the ease with which web technologies can be ported cross platform. – Bradley Thomas Nov 19 '15 at 23:50
  • @BradThomas: I think you should ask that as a separate question. It will get more answers that way. – JacquesB Nov 20 '15 at 06:54
26

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.

samuelmr
  • 361
  • 2
  • 7
  • 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
  • @TonyAdams It can sometimes be an issue with the tool; depending on the browser, fields generated by React that can have auto-filled values don't necessarily get auto-filled (this is due to certain browsers not creating expected events on page load, iirc). Or maybe it was a paste issue, now I'm not sure anymore... – JAB Nov 18 '15 at 15:29
  • @SiyuanRen I agree with you, it's not a feature I like implementing, however our commercial pentesting provider always fails me for it in our audit. – samuelmr Nov 18 '15 at 15:56
  • @samuelmr: They "always" fail you for it? Should have learnt by now! – Lightness Races in Orbit Nov 18 '15 at 16:51
  • 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
  • @RichardTingle That is a good reason to truncate the password. Let the user enter a 1,000 digit password and client side truncate it to 100 digits. If the user bypasses the client side truncation truncate it server side. From the client's POV, there is no maximum password length. – emory Nov 18 '15 at 23:07
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.

Peteris
  • 1,097
  • 6
  • 9
  • I agree - using any SPA with latency ~500ms is pure pain. – Ginden Nov 19 '15 at 00: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 01: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 02:38
  • @wingleader An alternative would be to dispense with the client side checks altogether on a slow connection. – Calchas Nov 19 '15 at 09: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.

dwoz
  • 401
  • 2
  • 4