How much of a usability win is making things “real time?” Submitting a form and having the server do validation and render the error messages can feel just as fast. Plus, if you use the correct HTML input types the browser will handle the most obvious validation without any JS.

You have to do validation on the server anyway. Why do it again on the front end?

haha... Have you ever worked with a product manager?

(:

Sorry, those turn up as 'must have' features in like, meeting #2 with the product owner, because the UI feels old and rubbish without them.

Technically? You're 100% right.

...but, I guarantee that even a LOB app, this will turn up, again and again and again as a feature request, until it becomes a tier 1 priority.

This clearly seems to read as a problem with the "product manager", not the technology.

Or maybe it's a problem with people railing against the stack pretending it doesn't solve any problems in at least 1 thread per day.

And also the problem was with “the” product manager, not “a” product manager.

You don’t have to do all validation on the server side.

Did the user forget to fill a mandatory field? Is this phone number actually even possible? Does this zip/postal code exist? Is the age entered too low to create an account? Is the password long enough? Does it meet all the requirements. Can we dynamically show which requirements it doesn’t meet.

Even email, which you will want to verify by actually sending an email, can have some basic front end checks (is there an @ in the email entered by the user).

In fact, I bet the vast majority of validations can in fact be done in the front end in real time.

You still have to do all the validation on the server, but you can duplicate some or all of it on the front end for convenience.

For simple projects, the validation built in to HTML form elements may be sufficient.

Client-side code is subject to potential manipulation. No validation you perform there can be a guaranteed truth for the server-side. Thus you cannot replace validation on server-side with validation on client-side.

> You don’t have to do all validation on the server side.

Yes you do.

You had all this (most often as free & open source jQuery plugins) 10 years ago.

Honestly, 99% of webapps today are 2 very interactive pages (which could often be developed in jQuery anyway) + bunch of generic datagrids & forms we have seen many times since the introduction of <form> and <table> tags decades ago.

While this could be achieved on the frontend with jQuery + plugins (or even vanilla JS, let's be honest) I think you're not remembering how cumbersome and error-prone building forms / complicated flows was without a dedicated framework. Speaking from experience, I believe Backbone.js was the first time I felt confident building state based UI on the web. Newer frameworks (first Angular, then React/Vue since then) have upped the stakes.

Honestly, my problems as a developer generally aren't with the frameworks (I'm mostly defending Vue here, as I find it predictable and easy) but with the build tools, which have gotten a bit out of hand and always feel brittle.

Personally, I think the main problem with jQuery was .data instead of having proper state management. If we used jQuery just as a library and not the centre of everything without any layer above, we might be perfectly ok with it even now in 2023 for everything that's 100* simpler than GMail (which most of webapps are).