4 ms·
> Right.. But I think often times the difference is pretty overblown. Clicking "save" and getting that feedback in ~100ms is not Let's say the form has 5 field
by ncallaway 7y ago
> Right.. But I think often times the difference is pretty overblown. Clicking "save" and getting that feedback in ~100ms is not
Let's say the form has 5 fields, and I as the user make an error in the first field.
Why do I have to finish filling out the entire form to hit "save", to discover I made an error in the first field? That's not a difference of ~100ms, that's a difference of several seconds (or tens of seconds for a medium-complexity form).
- flukus 7y ago>Why do I have to finish filling out the entire form to hit "save", to discover I made an error in the first field? Because more validation will usually happen on the server side anyway and finding out when you hit save creates less interruptions to your flow. There's no tabbing back to re-enter a field, there's no thinking it's fine only for the server side validation to reject it and there's no nagging when I skip a field to come back to it later, there's no UI jumping around when the error is shown. Client side validation takes a stateless form and interrupts me with it's stateful validation. At best it's an interruption, all too often there are silly things like not letting you tab to the next field or warning you that the second password you haven't yet entered doesn't match (and then later telling you about other problems when the backend does the validation). Not to mention it's easier, whether you agree or not with "developers are expensive so performance doesn't matter" in a world where this is often said I'd expect more server side only validation because client side validation is duplicating the work. I don't think client side validation is necessarily bad, but most implementations get in my way more than the server side equivalent.
- ncallaway 7y ago> all too often there are silly things like not letting you tab to the next field Well, that's a criminal use of client-side validation, but it shouldn't condemn all client-side validation. > Not to mention it's easier, whether you agree or not with "developers are expensive so performance doesn't matter" in a world where this is often said I'd expect more server side only validation because client side validation is duplicating the work. That's fair, but as others have noted if you're in a world where a polished user-experience really makes a difference or is a competitive advantage I'd argue that well executed client-side validation can get you to a UX-quality bar that no amount of server-side validation can reach (edit to add: server-side validation is still, of course, absolutely required). Whether that's truly important for a given business or product can only be argued on a case-by-case basis. I think it's definitely a colorable argument that there's some overuse of client-side validation relative to product goals, but I think there are definitely places where client-side validation is hugely impactful. Again, all of this assumes that the client-side validation is implemented at a high quality bar. Of course bad client-side validation is not useful.
- wilsonrocks 7y agoThere is definitely a happy middle ground. Feedback too soon can be jarring, but waiting till the end of a form can be very frustrating, especially if there are many fields and you have to reparse to find the error. I think you need both to have a good experience.
- ncallaway 7y agoOh, I agree. I just think that, if you're aiming for the highest UX-bar, you're going to need client-side validation at some point. For any mildly complex form, server-side validation will usually be far past the sweet-spot you're referring to. Now, as others have mentioned, it might be questionable whether every web-app and website should be targeting the highest UX-bar.