Client input should never be trusted. Server needs to validate, but that doesn't mean client shouldn't validate as well.
> I've never seen a form that really benefitted from client-side validation. As long as required fields are clearly marked, I don't really understand the value here.
Client side validation is not only about required fields, it's much more than that. Have you ever used a web store where you need to enter your shipping address, credit card info, etc? Address, zip code (or worse, UK style postal code), phone number, email, credit card number - all that needs to be validated.
Sure the server can (and should) validate that. The problem then is how to let the user know they've made a mistake and how to fix it. Accessibility issues aside, users need to be told that they've made a mistake as soon as it is made, otherwise there is a chance they won't find the error message, and simply give up trying. Lost sales is the reason client side validation was invented.
> Hmm? What about them needs React?
If you don't want to submit a form with full page reload, you need to make an Ajax call with form info. When response comes back with a list of errors, you need to walk through the fields on the page and mark the relevant ones as invalid, with corresponding error messages displayed _close_ to the input fields. Of course that is doable in plain JavaScript, and doing that seems trivial for one form. Then you have to duplicate that code for another form, or abstract it in a library... Congrats, you're on your way to reinventing React. Or worse yet, Angular.
> You can poll very cheaply. And even Websockets are pretty simple.
When the results of that poll come back, you need a way to display them. You need to decide which part goes where, which elements to hide and which to create, etc. The mechanics of this is what React (or a similar library) does for you, so that you could concentrate on writing logic instead.
> We're talking about React being overkill in a lot of places.
React might be overkill in a lot of places, but it's extremely hard to tell where and when. If you start with a simple hand rolled JavaScript app, at some point you might realize that maintaining it is a chore beyond one person's capacity, and hiring someone to do that for you is plainly impossible. You should have started with (React|Angular|Vue|whatever) in the first place, and now it's a choice between ground up rewrite in (React|Angular|Vue|whatever), or long stagnation and eventual death of your business. Do you want to take that chance?
Optimizing for developer productivity is the only safe bet in the majority of cases, unless we're talking about a personal project with no commercial value.