I'm not sure JS being slow was the reason. It's rather lack of trust that JS can and should be used for such things, and the difficulty of mixing client and server logic together. You kinda want to simplify things and relegate JS simply the role of detecting an event and delegating it to the server for processing and injecting the result back.
But JS, from the moment it was introduced, was quite capable of carrying out a great number of interactions. We tend to project our subjective beliefs on the objective world. We don't see potential in JS and so we didn't use it up to its potential.
I recall working on a webshop back in the day that opened in an embedded IE in the app for a popular music company (so I had also full control over the browser engine and could rely on JS), and there was a complex system of discounts as you add plugins to your cart and so on, and I thought: I'll use JS for this. And despite the discounts were verified on the server side, all my coworkers and my boss were intensely worried about me using JS for this, because I'll make the store insecure, and this is a very noob thing to do and I shouldn't be using JS for this. And... it worked fine. The tech was always capable of this, but none of then would've even TRIED, because they "KNEW" it's not supposed to be done.
Eventually the tide turned, but it turned to another extreme, that is even more BS now. Many websites load more JS code than they load images. Why? Because we subjectively believe the server is not capable of all the richness that JS can deliver. Basically we didn't get smarter about any of this.
We're stupid and led by superstitition about the tech we use, we don't really understand it, we don't grok it. We go by fashion and trends. Most do. And that's the danger of starting a stupid trend. It may take years before the bubble pops.
In that time frame I was building very complex applications (semantic graph editors, decision support software for sales teams with 10,000 salespeople, etc.) in frameworks like GWT (Java compilers to Javascript) this wasn't long after the firstversion of Google Docs came out.
Javascript was fast enough back then to make much more complex applications than most people were making back then but the complexity was mind-numbing, particularly considering that you didn't have tools like async/await to help manage asynchronous communications.
I built frameworks for managing the flow of data in that kind of application and didn't feel it was so catastrophic when Microsoft banned synchronous communications in Silverlight... I knew what to do.
Having had that experiment I tend to laugh at today's Javascript frameworks because they work really hard but aren't suitable for the kind of apps I built back then.
Sometimes it seems there is a lot of "lost" technology in software like the production rules systems of the 1980s, CASE systems and Lotus notes from the 1990s, Google docs in the 2000s that are like Stonehenge or the Egyptian Pyramids seen from the state of programming in 2023.
Entropy creeps into everything, unstoppably, masked under the pretense of a sequence of individually logical choices. To recover from this we will have to take a few steps back before we can make more steps forward. But we keep pushing and pushing, until either the tower we're building collapses, or us and what we do simply gradually become more and more complicated, with smaller and smaller gains that we focus on more and more, until it's all indistinguishable from background cosmic noise. Fermi paradox resolved.
Most C#, .Net devs and even VBScript devs had very little desire to learn JS. Not to mention that prior to IE6 becoming dominant there was a lot of very painful variance between browsers. JQuery helped to normalize this a lot. Part of why the ASP.Net (and others) were modeled with a full server postback. It worked fine when the server was in a server room in the corner of the building you were in, over the internet on dialup, not so much.
But JS, from the moment it was introduced, was quite capable of carrying out a great number of interactions. We tend to project our subjective beliefs on the objective world. We don't see potential in JS and so we didn't use it up to its potential.
I recall working on a webshop back in the day that opened in an embedded IE in the app for a popular music company (so I had also full control over the browser engine and could rely on JS), and there was a complex system of discounts as you add plugins to your cart and so on, and I thought: I'll use JS for this. And despite the discounts were verified on the server side, all my coworkers and my boss were intensely worried about me using JS for this, because I'll make the store insecure, and this is a very noob thing to do and I shouldn't be using JS for this. And... it worked fine. The tech was always capable of this, but none of then would've even TRIED, because they "KNEW" it's not supposed to be done.
Eventually the tide turned, but it turned to another extreme, that is even more BS now. Many websites load more JS code than they load images. Why? Because we subjectively believe the server is not capable of all the richness that JS can deliver. Basically we didn't get smarter about any of this.
We're stupid and led by superstitition about the tech we use, we don't really understand it, we don't grok it. We go by fashion and trends. Most do. And that's the danger of starting a stupid trend. It may take years before the bubble pops.