|
I'm not an Adobe engineer, but I am a Ruffle developer, so I can give sort of a valid take on this. Adobe isn't wrong in saying that Apple has a commercial motive to block Flash, but that would only apply to the point in time where Apple was trying to ban all third-party development tools for app developers, not just on the web. That was around the same time as Apple's "Thoughts on Flash" memo - in fact, the memo was written to justify the App Store policy. However, Flash was also cursed by the circumstances of it's birth. You see, in the 90s, the trend was to do everything in software, because CPUs were getting more powerful all the time and most computers were desktops with wall power. Who cares about memory or CPU usage? That's stuff's getting cheaper all the time! Dev hours are more expensive than hardware! The idea of dedicated accelerators and hardware for video decoding, music synthesis, modems, or even 2D graphics drawing was going the way of the dodo, and 3D accelerators were far too bespoke and uncommon to stick into a browser plugin. (For the record, there were no less than 4 or 5 competing 3D APIs Windows developers had to worry about, and 1 or 2 more on Mac OS) The iPhone was designed entirely backwards to this, which is ironic because Apple were the kings of "do it in software" going back to the original Apple ][ disk controller. But that's just how mobile phones worked. CPUs are power-inefficient and burn battery. Ergo, everything the iPhone could do had a hardware accelerator for it. Video and audio decoding were done in dedicated hardware blocks, UI elements were composited by the GPU, and I wouldn't be surprised if they had one of those hardware overlay scanout things, too. Flash Player - or, at least, the full desktop version - was simply not designed to work efficiently and use all of these accelerators. The painfully sad part of this is that Adobe already knew better. Flash Lite came out back in 2003, although you probably would never have known it because it was basically Japan-only until around 2006. None of this was a surprise to them, it just took them until Flash Player 10.2, in 2011, to actually build in support for things like hardware-accelerated video. Oh, and that only applied to new players that used StageVideo, because Adobe hadn't actually done the hard bit of hardware-accelerating actual Stage composition. They even wrote a Stage3D framework for pre-rendering everything as GPU textures, but they didn't build this into the player, so only games built around this framework would get the performance benefit. Meanwhile, web developers were enjoying the benefits of hardware-accelerated everything right out of the gate. You didn't have to add a 10mb+ reimplementation of HTML and CSS in WebGL to your site. The web browser just transparently sliced your content into GPU layers and rendering got faster. Apple figured this out and every other browser vendor eventually did the same thing. Same with video and audio tags: the browser is entirely responsible for playback, so it just hooks into whatever hardware nonsense it needs to run good. And because it's the easiest way to get video and audio onto a page, most sites are power-efficient by default. Why didn't Adobe take this approach? Well, the way they handled Flash updates was that everything was versioned, and they didn't touch the player behavior of old movies. They were betting on Flash developers continually upgrading to newer Flash technologies that would be easier for them to make efficient. Instead of figuring out how to JIT a highly dynamic language like ActionScript, they tried to convince ECMA and Brendan Eich to go along with adding immutable classes into JavaScript. ActionScript 3's class system was specifically designed to make writing JITs easier. Meanwhile, Google was busy writing V8, which could just JIT-compile even your nastiest, most dynamic JavaScript into relatively efficient ASM. It even JIT-compiled the object layouts! So it's sort of a one-two punch: Flash was cursed by being born of a culture of "who cares about performance, the Pentium II is coming", and by the time they had the opportunity to pull themselves out of that, they were too busy worried about keeping old movies from breaking and instead tried to build new platforms inside the old one that were more performant. |
The historical causality runs the other way: I gave Waldemar Horwat keys to the JS kingdom at Netscape and in ECMA TC39 TG1 in late 1997 when I went to cofound mozilla.org. Waldemar then designed "JS2" aka "ur-ES4" (my term) which is still archived:
https://web.archive.org/web/20010119185300/http://www.mozill...
https://web.archive.org/web/20001206082000/http://www.mozill...
Believe it or not, Microsoft on the ASP.NET side got excited about this ur-ES4 work and did their own version, shipped server side as JScript.NET around 2001:
https://www.drdobbs.com/a-talk-with-andrew-clinick-on-micros...
The team at Macromedia I was in touch with after Firefox 1.0, mainly Gary Grossman, Edwin Smith, and Jeff Dyer, were trying to do a successor to Gary's ActionScript work (which was based on JS). They tried to license Sun's small footprint Java VM, for full Flash (not FlashLite) on mobile devices, but when Sun learned it was going to run ActionScript 3, not Java, they denied a license.
So Ed whipped up a proof of concept that the Macromedia folks could do it themselves, and this led to AVM2 (open sourced as Tamarin with Mozilla; alas the team got pulled back to work on a doomed Flash for mobile play, so Tamarin was in practical terms abandoned).
My work with Macromedians was a high point of early Firefox era standards rebooting. Jeff and I went to Geneva in spring 2005 to meet with Ecma and Microsoft folks to restart JS standards work in TC39. When Adobe bought Macromedia, we saw a path to ES4 as a standard. This ended only partly in tears, as AS3 was too static and different (namespaces!), but the good parts got into ES6.
But immutable classes originated with Waldemar's JS2/ur-ES4 work in the very late '90s.