1. 22
  1.  

  2. 5

    One of the reasons that Flash was not adopted on iOS, was that it drained the battery. Today, my browser eats up more than 50% of my CPU time while I’m using it, due to JavaScript heavy web applications.

    It was good advice disabling Flash on sites where you didn’t need it, as it made your browser faster and nearly all sites were implemented very well with graceful degradation. Today, people look at you weird for wanting to disable JavaScript.

    I have immensely enjoyed Flash games, I still have a small collection of swf files and a standalone Flash runtime. Good times!

    1. 2

      One of the reasons that Flash was not adopted on iOS, was that it drained the battery

      Flash did all of its compositing in software. This meant that it couldn’t easily take advantage of hardware acceleration for video decoding. Apple actually added some APIs specifically for Flash to allow you to send a video to the GPU to decide and then pull the decoded frames back across the bus but it wasn’t a massive win because you were pulling large images back across the bus, compositing in software, and then sending them back. At the same time, OS X did vector rendering in software (2D vector rendering is still typically faster on the CPU than GPU because the setup costs dominate for the GPU even though the actual render is an order of magnitude faster) but then sent individual views to the GPU as textures and did all of the compositing there. A lot of animations with CoreAnimation were just short sequences of GPU commands, whereas the Flash equivalent did a load of work on the CPU.

      Playing back a video in a <video> tag in Safari was about half the system load of playing exactly the same video in a Flash thingy on the same Mac. Given how important video was to Apple, if YouTube on iOS had had the same problem I think it would have changed the outcome for these devices.

      It would have been possible to implement Flash in an efficient way but it would have been almost a complete rewrite of the graphics engine and Adobe was unwilling to do this.

      Flash was also going through a very bad period for security. Every month there was a new sandbox escape and the existing browser plugin model ran plugins like Flash in the same process as the rest of the browser. You could (on *NIX, at least) run Flash in a separate process and sandbox it but that made things even slower / power intensive.

      Today, my browser eats up more than 50% of my CPU time while I’m using it, due to JavaScript heavy web applications.

      Try disabling GPU acceleration and see how much slower it gets. That’s roughly the ballpark for where Flash would be on the same hardware.

      It was good advice disabling Flash on sites where you didn’t need it, as it made your browser faster and nearly all sites were implemented very well with graceful degradation. Today, people look at you weird for wanting to disable JavaScript.

      This mostly worked for Flash because Flash was quite siloed. Flash widgets didn’t (usually) tightly bind to the DOM and modify the rest of the page, they were little self-contained views. That made fallback quite easy (though quite a few sites just did ‘this page requires Adobe Flash’ as their fallback). In contrast, JavaScript is closely interwoven with the rest of the site, so fallback typically means a complete fallback implementation of the site, not a fallback implementation of a single view.

      I think the biggest thing that we lost with HTML5 versus Flash was that component separation. You can do quite strong separation with iframes that contain a canvas and a load of JavaScript, but then it’s hard for them to communicate with the rest of the page. Flash let you have little separately packaged things that could be enabled individually and integrate with the page.

    2. 5

      The points about the centralization of control (app stores) stifling creativity rings pretty true. RIP Flash