[Shorel]

Better garbage collection than current runtimes? Now this is surely rose tinted glasses, probably based on nostalgia. It had horrific performance all around. Even the now obsolete Opera browser Kestrel runtime had better JS performance, and it is obsolete because Chrome crushed it in benchmarks consistently for several years. No, there's no way Flash had the performance characteristics you mention, even less in a critical component like the garbage collector.

[noduerme]

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.

[BobaFloutist]

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.

[noduerme]

Actually, Electron is bloated, period. You can do your best with it, but there's a level of fundamental bloat and slow performance that's inherent to how it works. And bad code is bad code. Any platform can be used to write bad code, but the more accessible the development process is for newbie coders or non-coders, the more likely you are to get a lot of poorly performing apps, which is why there were a lot of those in Flash.

So I do understand why it got that reputation. But I'm using Javascript's raw performance in 2012 as an objective point of comparison. Consider a browser game. Given well-written JS coded with a competent understanding of the engine architecture versus well-written Flash, rendering the exact same animations, effects and interactions, you would find that the framerate in Flash could stay 25-30 fps on an iPhone 5, and be < 10 fps in Javascript. And that was with an alpha version of the Flash plugin. Similarly for JS bundled in Electron versus AS3 in the AIR engine as a "native" app. I know, because I wrote one of the first game engines for Javascript that attempted to do a subset of what could be done in Flash at the time.

What did make the dev process in Flash truly accessible was that it allowed the artists' pipeline to work in the same environment as the coders'. That did sometimes give rise to poorly written apps, but the fact is that the same thing in JS would have been even slower and more battery-draining, in an apples-to-apples comparison.

[BobbyTables2]

Also seems crazy to bundle a whole browser for a single app when every computing device has at least 1 of only 3 browsers (WebKit, Mozilla, Chromium).

There are fewer browsers than native GUI environments but we still couldn’t make that work…

[6510]

asmjs reminded me of an 80's thought: Why would you not include all the opcodes in higher languages?

[pixl97]

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.

[Shorel]

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.