| > The server still needs to validate, no? 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. |
A couple points:
1. The ~100ms between submitting a form and getting error messages isn't that big of a hurdle, in my experience.
2. HTML5 has validation attributes for forms, which can handle every one of your examples.
> 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.
Negative. You can do an ajax call, and re-render part of the page (e.g., the entire <body> pjax-style). This is fast, doesn't cause the "flash" of a page reload, and doesn't require more than a few lines of js to setup.
> 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.
Again, turbolinks on pjax has solved this problem very well. Just re-draw the bulk of the page. All the simplicity of reloading the page with none of the user pains of actually reloading the page.
> 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.
I agree. But I don't agree React _benefits_ developer productivity. On the contrary, I think it (and its competitor frameworks) are responsible for a lot of wasted developer time and frustration.