Bongo Cat

You're welcome ^_^

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.

backtick code comments/snippets from source text are. really not widely standardized, I don't think it makes sense to encourage them without an accompanying web standard, or at least some kind of standard