I wasn't aware of anyone using GWT outside of Google. Prototype.js + Scriptaculous was what really started the JS craze IMHO, followed by jQuery. Then came the increasingly more complex MooTools and YUI and Ext.js and friends, though nothing really took off nearly as hard as jQuery did. Backbone is probably also noteworthy as the bridge between jQuery spaghetti and the structured frameworks we see today (on the library consumption side). Knockout.js also deserves a shout out on the front of library authors looking for better abstractions.
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.
Prototype.js + Scriptaculous was what really started the JS craze IMHO, followed by jQuery. Then came the increasingly more complex MooTools and YUI and Ext.js and friends, though nothing really took off nearly as hard as jQuery did.
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 recollection was that Prototype.js got a big boost in popularity early on on the back of its inspiration from Ruby on Rails (in the sense that abusing prototype pollution to make DOM elements have useful methods was novel and cool). Dojo and friends were comparatively obscure/niche until much later. I recall only reading about Dojo years later, during the whole Comet hype.
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.
I wrote an app in GWT in 2011-12, and there was an existing sibling app also in GWT.
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.
Knockout was definitely easier to get started with vs other frameworks of the time, but still not easy by any stretch. It took time to master the template DSL, debugging templates would take you all across the guts of Knockout, and complex 2-way bindings could have you spending hours debugging them. Getting good performance was also very tricky.
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.
React and Preact really are nice. I’ve been building native and web apps and services since y2k. Preact, combined with Typescript is probably my favorite tech yet.
Though, I’ll note that I do really miss VB6 and C# Winforms for RAD.
GWT was used pretty widely by "the enterprise" outside of Google. For a long time, it was a large community with heavy traffic on mailing lists and stackoverflow. GWT was featured prominently at Google I/O for several years.
I wandered into the comments to find or write the correct "before times" bit, and I think this covers everything I would've mentioned.
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.
As to frameworks, I know nothing. As to Javascript libraries and their order of appearance it was: YUI in Feb-2006; then JQuery in Aug-2006; and finally Mootools in Mar-2007. Not a developer but my recollection is the same as yours with regard to JQuery -- it roared to dominance seemingly overnight.
I used GWT at one company for a bit. It was a mixed bag sort of like maybe React-Native today, not so much in how the tech works but in the way lots of things work and things feel different or have unexpected seams. I remember at the time thinking it was quite impressive for how much it could actually do.
I work at a ~1200 person company, been using GWT since I think 2012, before I joined. It's a mixed bag - it's clunky as hell sometimes, and we have been iteratively replacing it with React in places. Buuuut at the same time I'm often marveling at how amazing it is what they accomplished getting Java->JS compilation working like that. It's a very productive framework if you know how to actually use it. And that's tough to do
It was pretty heavily used in enterprise on applications from around 2006-2012. I still have nightmares of it, as since it's enterprises the code bases got massive and GWT in my experience had a trend of getting a ton of code smells.
A nitpick, but MooTools is closer to the Prototype.js era than jQuery - we used both extensively at freewebs.com (a large WYSIWYG online website builder) before ultimately moving towards jQuery down the line after it took off.
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.