(TL;DR; It's just a different way of working with less manual code)
I never spent much time on webdev in the era where jQuery came into being but as I've understood (and from the jQuery code I've seen since) it solved basic issues in working with manipulating the DOM and gives powerful animation tools,etc. So as you say the upgrade over the browser API DOM manipulation is obvious, clear and direct.
I'd say that my background is mainly from games, where you usually setup your own data structures and then rendered them as it fit.
From time to time I've worked on custom tools on native platforms (win32/GDI/MFC, Java/Swing,etc) and working with these is conceptually similar to using the DOM (manipulating objects like adding buttons, responding to events, reading data from input boxes on events,etc) and there is always relatively lot of work with shipping data in and out of the UI objects (either keep data synchronized between UI and internal model or reading data from the UI continually).
Compared to your game rendering code that usually just needs to iterate internal data this always felt like a lot of manual work to keep UI and internal data in sync.
Considering for example a 3D program where you can drag around an object with some arrows, while those arrows are dragged an input-box is updated with the new values and if you want to align the position you might edit the value manually in the input box and have the 3D view show the new position as you edit it. On top of these 2 sources of value changes you might have an animation system wanting that might change these values while animating (so that they are visible to the user), this kinda stuff is usually a buggy nightmare to maintain once you have it in a few many places.
This is why I like Vue and React (Angular.JS also had this to a degree even if it's implementation was weaker than Vue), with both of them you only need to concern yourself with how your internal data works/looks and operations are simple to do since they only operate on that internal data.
Then the Vue templates (or your React rendering functions) takes care of visualizing it with the associated automatic functionality to adjust the internal values if changed by the user.
Thanks for sharing. I have very little experience with game engines but React/Vue always resembled them to me a bit. Here's the data, render when changed. I just don't think it's needed in most Web cases.
Sure, if you attach behavior code to every interactive element directly, all of which are controlling the same portion of the screen and depending on each other, it's a recipe for a mess.
If, however, you call somewhat generalized functions on those events, with basic DRY strategies in mind, it's all very clear and manageable well into the thousands of lines, with no need of running a gaming engine in JS, creating a templating language that must be transpiled, etc.
edit:
>less manual code
jQuery code if often smaller and clearer, I mean check this classic:
And that was my original point, using React for a small one page thing like this is grossly overkill but Vue is a good smaller alternative at this scale that gives you most benefits.
I looked at the jQuery example above and checked the Vue example in the same repo. That example has about as many lines total but the Vue example is 30% smaller in total due to shorter lines.
I never spent much time on webdev in the era where jQuery came into being but as I've understood (and from the jQuery code I've seen since) it solved basic issues in working with manipulating the DOM and gives powerful animation tools,etc. So as you say the upgrade over the browser API DOM manipulation is obvious, clear and direct.
I'd say that my background is mainly from games, where you usually setup your own data structures and then rendered them as it fit.
From time to time I've worked on custom tools on native platforms (win32/GDI/MFC, Java/Swing,etc) and working with these is conceptually similar to using the DOM (manipulating objects like adding buttons, responding to events, reading data from input boxes on events,etc) and there is always relatively lot of work with shipping data in and out of the UI objects (either keep data synchronized between UI and internal model or reading data from the UI continually).
Compared to your game rendering code that usually just needs to iterate internal data this always felt like a lot of manual work to keep UI and internal data in sync.
Considering for example a 3D program where you can drag around an object with some arrows, while those arrows are dragged an input-box is updated with the new values and if you want to align the position you might edit the value manually in the input box and have the 3D view show the new position as you edit it. On top of these 2 sources of value changes you might have an animation system wanting that might change these values while animating (so that they are visible to the user), this kinda stuff is usually a buggy nightmare to maintain once you have it in a few many places.
This is why I like Vue and React (Angular.JS also had this to a degree even if it's implementation was weaker than Vue), with both of them you only need to concern yourself with how your internal data works/looks and operations are simple to do since they only operate on that internal data.
Then the Vue templates (or your React rendering functions) takes care of visualizing it with the associated automatic functionality to adjust the internal values if changed by the user.