You forgot Dojo, which was the first big javascript framework.
We have a different recollection of the order of events. I was doing web dev professionally as of 2004, and how I recall it is this:
Originally people had utilities files with a bunch of javascript convenience functions copied from random blogs that they would use to enrich server-side generated pages. This is how I wrote web apps in 2004-2006: php-generated html with hand-rolled js to enrich it.
Out of those grew the first generation of libraries (not frameworks) like prototype, mootools and finally jquery (which was so good at being a web swiss army knife that it replaced every other library).
The libraries were ok to add a bit of interaction but not at building entire UI. The “write your whole UI in JS” approach I remember being popularized by dojo and yui / yui-ext / extjs. GWT was a big hype but indeed not used by many. Lots of people used dojo and extjs though. I switched to ExtJS as soon as it arrived on the scene in 2007.
Those early frameworks only solved the UI problem, they were not great at page lifecycle and backend interaction, so they relatively quickly got replaced by application frameworks that did, like backbone and angularjs. Their mistakes became the inspiration for the second generation of SPA frameworks that we are still using today.
My impression of the era was that visual pizzazz was all the rage, and Scriptaculous really delivered on that front (Flash was also huge back then). Whereas full blown web apps were relatively rare and a lot of library consumers just didn't see the point of things like modularization (despite the interest in "proper" engineering from library authors like Dean Edwards et al)
And even then, once interest in thick clients grew, Ext.js had a lot more fanfare among the heavier frameworks than the Dojos and MooTools, due to its focus on enterprise.
It worked. It let me use my existing desktop app experience (Java, C#, C++) to write code that had a familiar style ( `myButton.setText("Click Me")` ), and build very desktop-style apps that ran in a browser.
But after having learned JS and Backbone, and then React + Redux, it was clear this was a much better way to build apps in general. (Obviously I became biased towards React and Redux personally as shown by my involvement with those tools, but it truly was a big mental shift in how I approached writing code in the first place.)
It took MONTHS to become proficient at early-ish frameworks like GWT, Dojo, Marionette, Angular, Knockout, Ember, Enyo, etc.
Getting up and running on React in a couple hours and almost completely understanding the entire API inside a couple days was incredible. The fact that the code was faster and had fewer bugs too was almost too much to believe.
Nah.. I don't know about the others but Knockout was super simple to learn and get going with. React was way harder IMHO.
ReactJS of the time was pretty simple.
https://web.archive.org/web/20131105184444/http://facebook.g...
You could read every scrap of documentation in around an hour or so. There were only around a dozen-ish APIs to learn along with only a couple "unique" concepts like controlled inputs, refs, and JSX.
Meanwhile, there was never a need to step into React code unless you believed React itself was buggy (I only came across this one time and the bug had already been reported and was being worked on). Even better, React code was usually faster than Knockout before optimizing stuff and the ways to improve performance were generally pretty obvious.
Though, I’ll note that I do really miss VB6 and C# Winforms for RAD.
I'll add that looking back, EXT seemed to be a bit ahead of its time. Its data/table view rivals AG Grid [0] of today. If we could've just standardized on a table view by now, but alas.
AG Grid - [Ag Grid, agnostic JS table framework](https://www.ag-grid.com/)
A bunch of people messed with Rhino (IIRC Jaxer was one of the bigger ones), but Rhino had a bunch of quirks. For example, strings were Java strings, meaning that length is obtained via `"foo".length()` instead of `"foo".length`. Perhaps the biggest showstopper was the JVM variable limit per class file. Compiling large enough Rhino JS code would yield class files that crashed due to that limitation. And since JS didn't have modules back then, big balls of code were the norm.
Back then, the divide between frontend and backend was also wider. "Full stack" and the uplevelling of frontend folks towards backend skillsets wasn't really as popular as it is today. Node was also seen as revolutionary due to its async I/O first philosophy, whereas Rhino was more or less just a worse Java.