This article is an oversimplification describing basic forms, but as soon as you try to implement any sort of advanced validation using just HTML, the whole paradigm falls apart. Browsers support JavaScript for a reason.
This article is an oversimplification describing basic forms, but as soon as you try to implement any sort of advanced validation using just HTML, the whole paradigm falls apart. Browsers support JavaScript for a reason.
How can you ever trust validation on the client side though? The user can just mess with it and submit anything they want anyway.
Why not validate on the server and return a response or error as HTML?
I’m not trying to argue in bad faith here. I know client side validation is necessary in some cases, but IMO it’s only an augmentation for UX purposes on top of server side validation.
> Why not validate on the server and return a response or error as HTML?
If your form has files you'd want to at least check it before sending data unnecessarily to the server.
Also it's always better to have a tighter feedback loop. That is really the main reason why there's validation on the frontend and backend, not just the latter.
Client-side validation is a progressive enhancement. You always have server-side validation. The validation in the browser exists to provide additional feedback that lets users have realtime feedback about their input.
Typically for fetch() I return the error as "text/plain" with the appropriate status code. It is still necessary to give a preflight validation in Vanilla JS, apply an error style and helpful feedback.
HTML has come a long way since the bad old days. General constraints can be applied directly to the input element. It still makes sense add additional explanations for the invalid input with JS though.
https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
Just use a generic data structure for your validation rules that you can apply on the front-end, and validate on the back-end. Using JavaScript and doing validation on a server are not mutually exclusive.
You're answering yourself here: client side feedback/validation is essential ux for any complex form. Even for simple signup forms with a few required fields.
You have a human in the loop somewhere. This is how we do to not lose clients who accidentally typed @gmail.co
It's also essential in order to not make forms to difficult to fill in, because that means you lose customers and a lot of money.
[dead]
You can use JS to provide validation and still submit the form from HTML.
That’s not validation. It’s more like helpful hints.
A pointless distinction when we all know what we're talking about.
Is it? I’ve seen devs bring complicated code to the frontend when a required attribute on the tag would have done the job just as well. Preventing user mistakes is not the same as ensuring correct input.
We've all seen bad implementations of any given thing I'd imagine. Ever submit a form that triggers a full page refresh after about 8 seconds of hanging, only to lose half the data and reveal some arcane requirement to you that wasn't stated up front? Of course this isn't the proper way to do it, but it happens.
What is the difference?
The same is true for any JS "validation" and I was using common terminology.
From a user point of view as long as you keep the feedback loop short what difference can they see?
Neither is it validation when you use JS if the server doesn't check it. You can always send requests with postman, curl or your tool of choice.
Helpful hints are all you can rely on from client-side. Client-side validation doesn't really exist, true validation only happens server-side.
There's a lot of validation that can be done with HTML; I'd even say most client-side validation can be handled by HTML/the browser. You can specify input types, do RegExp matching, etc. There's a lot in the spec.
You'll need server-side validation anyway…
You can have a minimal library like HTMX or if you have access to a solution Phoenix LiveView, you need minimal JS to have an interactive page, the only downside is that you could introduce some latency because of the network trip.
I think a part of the point is to question the need for things like that. Do your users actually need all of these bells and whistles?