I do not entirely agree, because if the data does not pass the client-side validation, it won't even get to the server-side(backend) validation. So technically it does.
True, but still it does not take the away the importance and essence of client-side validation. The point of the article is to share tips of how to validate on the client side with html, it doesn't disregard the server-side validation.
Front-end engineer and Co-Founder @VisualEyes. Striving to write clean and maintainable code by using modern web technologies. Currently passionate about Node, ReactJS, Three.js, CSS animations.
Location
Greece 🌎
Education
Master in Electrical & Computer Engineering
Work
Indie Hacker, Front-end engineer and UI designer at VisualEyes
The client side validation enhance the user experience of the end user, too. About security, the backend should be the final layer and have its own validation.
So both of them are important🎉
Use Ajax for your forms and you can put all of your validation on the back end so it's all in one place. This makes it much easier to test. Some simple JavaScript and css can handle output of messaging. That said, my point was only to draw attention to the fact that these frontend shortcuts offer no security or protection for the back end. Handy for traditional form post methods, but ultimately pointless for more advanced solutions.
Pointless? not really. This has nothing to do with testing this is just basically using HTML to validate the data that is been gotten from a user.
It is not a frontend shortcut, because this does not stop you from performing any server-side validation but rather helps for better validation while delivering good user experiences.
Sending a backend request for every form field is overload. Yes, the backend is the final layer of security, but that doesn't make frontend validation pointless.
I wouldn't bother sending an AJAX request on every field either, but it depends on the complexity of the form and how it was designed. In most real world examples, if you care about data integrity, HTML5 validation is a giant pain for testing since you need to edit the markup to disable it. If you are doing unit testing, could skip manual testing without the client-side validation, but most websites are not configured for unit testing and just as many devs have no idea what that even is.
Personally, I like to do a combination of light client-side and full server-side validation. Javascript will do things like highlight an empty field that is required on blur, but ultimately all validation and messaging is handled in AJAX requests on submit. Again, it depends on the form, but in 20+ years and hundreds of form implementations, I've completely discarded use of HTML5 validation. I was on board when it first came out years ago, but dropped it within a year of applied use. Once you start working with WAS or understand how malicious users attack form handlers, you'll realize that the convenience is not that convenient.
There is almost always a matter of preference involved in how you approach technology problems; my only goal from the original comment was to point out to unsuspecting visitors that HTML5 validation, by itself, will not prevent abuse.
An experienced software developer with a strong background in developing award-winning web and mobile applications for diverse clients with 6+ years of industry experience.
I admit, I didn't know that. @nedy I think a brief note about the novalidate property would be a good addition to your article. Preferences aside, it's a great explanation of html5 validation.
None of these things actually protect the back end.
I'd love to hear explanation.
I do not entirely agree, because if the data does not pass the client-side validation, it won't even get to the server-side(backend) validation. So technically it does.
User can bypass client-side validation.
True, but still it does not take the away the importance and essence of client-side validation. The point of the article is to share tips of how to validate on the client side with html, it doesn't disregard the server-side validation.
The client side validation enhance the user experience of the end user, too. About security, the backend should be the final layer and have its own validation.
So both of them are important🎉
Very true @d__raptis
Use Ajax for your forms and you can put all of your validation on the back end so it's all in one place. This makes it much easier to test. Some simple JavaScript and css can handle output of messaging. That said, my point was only to draw attention to the fact that these frontend shortcuts offer no security or protection for the back end. Handy for traditional form post methods, but ultimately pointless for more advanced solutions.
Pointless? not really. This has nothing to do with testing this is just basically using HTML to validate the data that is been gotten from a user.
It is not a frontend shortcut, because this does not stop you from performing any server-side validation but rather helps for better validation while delivering good user experiences.
Sending a backend request for every form field is overload. Yes, the backend is the final layer of security, but that doesn't make frontend validation pointless.
I wouldn't bother sending an AJAX request on every field either, but it depends on the complexity of the form and how it was designed. In most real world examples, if you care about data integrity, HTML5 validation is a giant pain for testing since you need to edit the markup to disable it. If you are doing unit testing, could skip manual testing without the client-side validation, but most websites are not configured for unit testing and just as many devs have no idea what that even is.
Personally, I like to do a combination of light client-side and full server-side validation. Javascript will do things like highlight an empty field that is required on blur, but ultimately all validation and messaging is handled in AJAX requests on submit. Again, it depends on the form, but in 20+ years and hundreds of form implementations, I've completely discarded use of HTML5 validation. I was on board when it first came out years ago, but dropped it within a year of applied use. Once you start working with WAS or understand how malicious users attack form handlers, you'll realize that the convenience is not that convenient.
Great, I think I understand you better now, but this sounds more of a matter preference.
There is almost always a matter of preference involved in how you approach technology problems; my only goal from the original comment was to point out to unsuspecting visitors that HTML5 validation, by itself, will not prevent abuse.
True, and the essence of this article was to show tips on how to use HTML to validate the type of data being sent to the server.
In case of unit testing, you can easily add
novalidate
attribute to theform
element to bypass browser validation.I admit, I didn't know that. @nedy I think a brief note about the novalidate property would be a good addition to your article. Preferences aside, it's a great explanation of html5 validation.
Thank you @lawrencejohnson . I'll be sure to add that.