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.

Prototype was a great initiative, but I think the community was right when it decided to go the jQuery route, and not append new functions to the prototype. Even though prototype never really caught on, working with websites where it was used partially, or scraping data on websites that used it, has caused me plenty of issues over the years.

You left out 2 frameworks that are important in answering your question, and those are YUI, and jQuery UI. And both of them attempted to answer the same issue. The issue was thus:

In jQuery's hayday, developers wrote code by appending jQuery scripts to events. If you click this button, then the code in $(yourButton).click(function(){}) would run. But at the time, writing OOP, or even well moduled code in javascript was extremely difficult to do, as very few developers invested time into setting up a module system via CommonJS, or AMD modules, with requireJS or Browserify or etc, and almost never did so by default with a normal jQuery page.

The end result is that once your average webpage hit a certain level of complexity, the page itself would have thousands and thousands of lines of JS, each one written as a completely standalone script, triggered off of some jQuery event on the page.

And this is just fundamentally not a good way to program. In what other world would we write code, and say that our architecture is that each user action can trigger a stand-alone script, and that's good enough? Except for JS it was worse, because without a moduling system, there were often conflicts and soft dependencies everywhere between said scripts. Above a certain complexity level, refactoring code from this timeperiod is a complete and utter nightmare. It doesn't help that the inability to program using cleaner architectures resulted in many programmers writing off JS as a "toy" and not a real language, whereupon many of these programmers would then go on to write "toy" level quality of code.

jQuery UI, and YUI both attempted to solve this problem by building a component based approach to organizing your events. Basically enforcing a very simple OOP framework in a world where writing AMD or CommonJS modules was a pain in the neck.

They're both okay. At my company there's still old code from before and after these frameworks came out, and among pages that have thousands of lines of JS, the pages that use these frameworks are miles and miles easier to refactor than the ones that just rely on pure jQuery. We usually take to just completely burning and replacing the pre-Yui/pre-jQuery UI pages, but the Y/jUI pages we can usually refactor or actually debug.

Backbone.js took the lessons learned in YUI and jQuery UI and wrote the first real framework that was any good at building a modern UI architecture that worked in the browser. I could go to a dev who was building a WPF app in MVVM, and explain backbone.js in a few minutes, and they got it. It wasn't perfect, but it was far better than what we had before.

Node.JS standardized how to actually write functional or OOP code in JS.

Angular and React took the lessons learned and failed by backbone, and added in the fact that with the advent of Node, people actually started writing JS as a first-level language.

Angular was an iteration on the problems attempted to be solved by yUI and jQuery widgets. That's to say, Angular's entire approach was to build a heavily boiler-plated framework so that individual developers could write UI scripts in relative isolation from each other, in a very easy to debug manner. It is and was basically what every large development project manager / team lead has been asking for since the early 2000s for JS development. A framework that is so boilerplate heavy, opinionated, and hand-holdy that it becomes easy to debug and review the majority of the code written by your junior JS devs. Its no wonder it was the first framework to heavily enforce static typing and typescript, or that it was pushed by Google. Though Angular has iterated many times over the years, its initial versions were explicitly written with the intent to be used by project managers writing JS who weren't programmers, and to me, it often feels like it is inspired by enterprise JAVA type decision making. You can use Angular for anything, but to me where it really, truly shines is if you have a webpage with a well defined layout, need specific parts of that page to have heavy but isolated user interaction, and your team is not a JS-first shop. This isn't the only place where Angular shines, but my god does it shine in that particular combination.

React took the opposite approach. It also iterated on the successes and failures of backbone. But it attempted to do so with an approach that provided the bare minimum for front end developers to write modern web apps, and give developers an opt-in approach to included what parts of the library they would like to use, and make it easy for developers to write their own packages to be used with the library. Where angular attempted to provide its own core libraries (and correct way to use them) for every possible need a developer could have when building a web page, react trusted the community to develop JS on its own.

Vue, mithril, etc all iterate on react's decisions.

UI wise i need to add an envelope editor instead of entering numbers manually, the player code already has support for envelopes although it needs a bit fixing with how sustain is handled.

Would be fun to "put up" the project for public consumption, took the opportunity to try out a serverless backend (since this isn't something i plan to manage myself or think will pull or cost in any real money) and that was fairly easy for what i have in mind (adding the possibility to share tunes and some 3rd party login for saving stuff maybe)