3 ms·

Yeah Flash was slow, but the common alternatives for in-browser animation/games were (and still are) far slower. H.264/5 maybe did video better than Flash, even

Yeah Flash was slow, but the common alternatives for in-browser animation/games were (and still are) far slower. H.264/5 maybe did video better than Flash, even then idk, Flash YouTube was always way faster on my old iMac than HTML5 YT. Google Hangouts/Meet will lag a high-end Intel MBP thanks to the unaccelerated VP8/9 video, but AIM Flash-based video calls ran fine on an iMac G4. On top of that, there was never a real replacement to the Flash creation software. All those Flash games that people made without really understanding how to code, no longer doable. I guess Flash had to die because of how outdated, insecure, and proprietary it was. It did seem like a nightmare to support well on mobile. Just wish someone made something strictly better.

sheepscreek 3y ago
Perhaps it was fast due to lack of tight security policies etc. These days, everything has to be containerized or be in a sandbox. That adds layers of overhead. Probably also why Google killed NaCl (Native Clients for Google Chrome). It was loosely in the same space as Flash and ActiveX - anyone remember that?
- hot_gril 3y ago
  I've thought about that too. Can only guess about it myself. Old software tends to be faster just because it has to be, and there isn't always a compromise other than time-to-implement. Not sure how ActiveX's sandboxing worked, but I'll bet it was even less than Flash, since it was running actual x86 code.
  - londons_explore 3y ago
    ActiveX required that the ActiveX code you wanted to run be already installed on your computer. The security mechanism was that users obviously wouldn't install insecure stuff... Turns out nearly every extension had gaping security holes.
    - nvm0n2 3y ago
      Not quite. ActiveX would download and run unsandboxed native code direct from the web, even if it wasn't installed. The security mechanism was a popup dialog that contained the publisher name as verified by a code signing certificate.
      - hot_gril 3y ago
        This is how I remember it. I was dealing with early 2000s smart home software that used ActiveX. I'd visit a website in IE, press ok, and run their "web app" that had raw access to my serial and ethernet ports. It was bizarre even for back then.

sheepscreek 3y ago

Perhaps it was fast due to lack of tight security policies etc. These days, everything has to be containerized or be in a sandbox. That adds layers of overhead. Probably also why Google killed NaCl (Native Clients for Google Chrome). It was loosely in the same space as Flash and ActiveX - anyone remember that?

hot_gril 3y ago
I've thought about that too. Can only guess about it myself. Old software tends to be faster just because it has to be, and there isn't always a compromise other than time-to-implement. Not sure how ActiveX's sandboxing worked, but I'll bet it was even less than Flash, since it was running actual x86 code.
- londons_explore 3y ago
  ActiveX required that the ActiveX code you wanted to run be already installed on your computer. The security mechanism was that users obviously wouldn't install insecure stuff... Turns out nearly every extension had gaping security holes.
  - nvm0n2 3y ago
    Not quite. ActiveX would download and run unsandboxed native code direct from the web, even if it wasn't installed. The security mechanism was a popup dialog that contained the publisher name as verified by a code signing certificate.
    - hot_gril 3y ago
      This is how I remember it. I was dealing with early 2000s smart home software that used ActiveX. I'd visit a website in IE, press ok, and run their "web app" that had raw access to my serial and ethernet ports. It was bizarre even for back then.