> How about client-side validations? Easy. On every input change, round up the form values and send ’em down the WebSocket. Let your server framework validate and send back changes to the HTML of the form, including any errors that need to be rendered. No need for JSON or complicated error objects.
Maybe in an ideal world where responses are 1ms this would work, but imagine real world, real-time validating user input (ie email) and the user needs to wait before they find out their input is valid.
Input formatting like, emails, phone, or things that you can know in the frontend, can all be done (and should be) on the client side (many even on html itself although it's a bit lacking in some cases, that would definitively be the ideal although I also don't think html is going to be able to cover all use cases ever - or that it should - but in the end it always seems to be missing just one tiny thing that forces you to write JS).
What you may want to do is to submit changes in case you want to see if an email has been taken already, for instance, to display additional information while the user is writing and this no matter what technology is used would always require a round-trip? No saying that you need that, but it's up to you when implementing deciding on what is the UI/UX you need and take it from there, it's not like it forces you to do that.
(sometimes articles take it a bit too far and end up showing anti-patterns, mixing problems it solves and problems it creates when misused)
Maybe in an ideal world where responses are 1ms this would work, but imagine real world, real-time validating user input (ie email) and the user needs to wait before they find out their input is valid.