People have this odd view that Flash had horrific performance, largely because their encounters with it as users were mostly with ads and graphics on the web that were terribly written and soaked up a lot of CPU. The same is true for tons of Javascript junk that pollutes the web now, but no one blames the language or the interpreter for that. AS3 ran inside a VM, so garbage collection wasn't linked to the browser's needs the way an embedded JS engine's would be (although it could take hints from the browser, as I recall). But the GC was excellent if code was properly written, and that meant a lot of good practices like ensuring weak references in event listeners and destroying / tearing down instances. You had to write code in a way that the GC would know to mark and sweep. Having said that, I tested a 500,000 line, single bullet Flash gaming site running on a beta version of the Flash plugin for iOS/Safari in 2012, on an iPhone 5, that was running particle systems and multiple game animations on screen with performance that would almost rival a javascript-based game now on phones that are 15 generations improved. If written well, and with a good understanding of how it managed memory, and keeping in mind what you had up on the GPU, from about 2012-2015 you could make the AS3 VM perform about as well or better than a reasonable graphics stack like PixiJS performs in 2026, on much lesser hardware. And you could definitely avoid memory leaks if you took care to.
Flash had horrific security and accessibility, along with Adobe just being a suck company in general. When you couple that with browser integration issues it just becomes a stack of issues that people became tired with in general.
I definitely blame JS whenever I have to interact with some websites or Electron applications :) Even coding agents. I made my own agent in d-lang just because I'm alergic to installing anything that requires node.js.
It's interesting to me whenever developers say "actually this framework/language/library/platform that's popular and lauded for how accessible it makes development has great performance as long as you dig into the architecture and write code skillfully" because the broad consensus among users is that they will not.
As a user, comparitive "performance" is about the code people actually write, and even more on the code that I'm most likely to interact with. I don't actually care whether or not the code could be faster if it was written better, because it always could, and it never is. When people say "Electron is slow and bloated" they don't mean that exhaustively written Electron apps could never" be performant, they mean that apps that use Electron tend to be slow and bloated. The way to change that reputation is not to argue that Electron could* be fast if people held it right, but to make it easier and more natural for Electron apps to be faster than they currently are.