You can still throw in something like Vue later, easily. It is one script tag away. That is what most do not get. You can go the traditional template rendering way for as long as it serves you well and then you can still have interactive components, when you really need them.
I was recently writing raw html and the typesystem compared to js components (aka JSX) is... just not there? I hate coding without proper autocomplete.
Yep. My experience has been that you can start with a wonderfully simple tool, but you end up jamming in dynamic behavior because users today want it and expect it... even in "simple" internal LOB apps.
Updating the UI in response to user value input and state changes in real time: error messaging, validation, presenting more relevant additional inputs, formatting, etc.
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?
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.
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 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).
Verbosity is hardly the problem these UI libraries/frameworks solve. They establish idioms for data flow and composition.
The UI component model’s data flow might vary between libraries, but they’re all generally opinionated and fairly consistent internally. The equivalent in “vanilla JS” can easily become unwieldy even with a lot of discipline, because the underlying APIs are designed with the view as the source of truth. That’s almost always the opposite of how you’d want to design a system with more than a very small amount of complexity. But that’s where inertia will guide you because there isn’t even a notion of state that doesn’t reference the DOM etc.
Once you’ve succumbed to this even partially, composition becomes incredibly difficult because the underlying model leaks implementation details. Tangling them is not just easy, it’s the default. Avoiding tangling them means basically developing a UI library with its own opinions and idioms. Which maybe you want that, but most people are building something else.
Untangling them is an enormous task. I’m maintaining an application that began in the era when this was common, and picked up some notion of components along the way. Even just understanding how things get invoked can take hours or days tracing app code and its interaction with implicit state in the view, and that’s with two years of familiarity with the code.
I don’t even like React or several of its idioms. But stuff that takes me hours or days would take minutes to understand with just the basic assumptions React or any other component library would afford. I can’t speak for any specific commenter, but I think this is the kind of “scale” most UI devs mean when they discuss it in those terms.
And granted, the critique that many things don’t need the scale they take on—that they add incidental complexity to fit a library/framework’s model. That can certainly be true, but I think the “vanilla JS” camp really underestimates how steep that cliff is and how quickly many projects can run off it.
Until you get told to implement more reactive features, then it's over. Using Pure JS/JQuery for reactiveness is outright horrible.