🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Why didnt flash just compile to javascript/webgl?

Started by
15 comments, last by kop0113 3 years, 5 months ago

I used to love Flash, but it is dead. Both as a technology and a brand. What you are proposing is certainly possible (for example, Adobe was able to export to iOS native before Apple banned transpiling, clearly to kill Flash). And ActionScript is not so different from JavaScript (both are derived from ECMAScript) so that would have made it even easier. But it would be some amount of work (I think not hard, though, given Adobe's resources) but the issue is that the ship has sailed. It's more of a business decision than a technical one.

Advertisement

Flash, if written completely in c/c++, can be compiled to WebAssembly and deployed to web. But that is unlikely, it probably uses a lot native code such as dedicated Intel instruction set, to accelerate rendering. I'd imaging its code base uses a lot of #ifdef macos, #ifdef windows, and #ifdef linux. It is not only OS dependent but also CPU dependent and even GPU dependent.

I think there is a very simple reason why Adobe never built a transparent HTML5 runtime for Flash: at the time, the client-side web stack wasn't sufficiently advanced to emulate all of Flash with any degree of fidelity/performance. The iPhone started taking a chunk out of Flash's user-base in 2008, but Asm.js (the precursor to WebAssembly, and most likely replacement runtime) doesn't show up till 2013, and WebGL isn't supported until iOS 8, in 2014.

In the intervening 5 years, Adobe hadn't been standing still. Many of their content authoring tools had been augmented to support direct export as both HTML5 and native iOS app. I don't imagine there was a lot of business value to providing a migration path for the masses of legacy flash games out there, especially given that as long as the authors still had the source data, they could re-export into a modern runtime if they should so choose.

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

Yes. Those who are active can press a button and generate a new output. Some pieces of functionality were cut, but most features have either exact replacements or suitable substitutes.

Both Javascript and Flash's ActionScript share the same origin, both stemmed from ECMAScript. The code itself is not the difficulty.

The bigger issue was emulating the library of behaviors outside the language. Even though they share the same programming language roots, it is like taking a Windows program and porting to Linux or an iPhone: the system's libraries are so different the work to port is often difficult even if the core logic is unchanged and completely portable. As others mentioned, the Flash core library has many security problems that were solved by modern design. Some were merely bugs, most were core design features that did not consider system security when written, so maintainers played a cat and mouse game against those who wrote exploits. The library design could never be completely overcome so it's days were always numbered. I remember more than a full decade ago discussing how it was only a matter of when, not if, the tools would be dumped for security reasons.

I worked as a senior dev, and later as the tech lead for Mozilla Games Initiative back in that time, between 2013-2018. Our team is the team that invented asm.js and brought companies later together to standardize it as WebAssembly. Back in that era, we talked widely across the industry with different vendors to make sure asm.js would shape up being useful, and to charter WebAssembly.

The reason that Adobe did not hop on board was (my impression) primarily a business decision. Already well by 2013 it was so popular on the internet to hate on Flash, and companies wanted it dead. That is one of the reasons that Mozilla had started compile-to-web and asm.js: to supplant Flash based games use case on the web with a web-first standardized alternative. Flash crashes were topping Mozilla Crash Stats several years by then.

After the image of Flash was so tarnished, it would have likely taken a lot of marketing effort from Adobe, even if they had had the tech done, to “build up” Flash's image again to make it a sensible business decision. After their earlier Stage3D/AGAL and Alchemy/Flascc dead ends, they had already announced in their 2012 roadmap to the public that Flash had gone to maintenance mode, focusing solely on the use cases that cannot be solved on the web otherwise (where Flash “shines best"). I cannot find the 2012 roadmap on the net anymore, but I did find a blog that cites the exact wording that I remember as well:

“Looking forward, Adobe believes that Flash is particularly suited for addressing the gaming and premium video markets, and will focus its development efforts in those areas. At the same time, Adobe will make architectural and language changes to the runtimes in order to ensure that the Flash runtimes are well placed to enable the richest experiences on the web and across mobile devices for another decade."

That was a soft way of saying “we don't really care about any other use cases any more, it will fade away".

While it is true that technically they could have well ported their Flash VM over to asm.js and later WebAssembly, they likely just did not see it to be able to bring in any dollars. (in fact, they did have internal prototype builds of the VM over to Wasm)

I did stumble on to two different Wasm Flash player protos back in the time. The AutoDesk ScaleForm GFx engine had been ported over to Wasm, but was discontinued. I don't remember the name of the other (that could have been Adobe's own VM actually).

Technically it could all work, but there is one fundamental technical challenge that shipping the Flash VM over as Wasm would have, that the Flash plugin download did not: online vs offline installation. Whereas the Flash plugin is installed ahead of time and could deal with large plugin download sizes (an online page suggests the plugin installation size could have been around 57MB - it has a large runtime library), all Wasm content is delivered right at online site visit time. If we very naively assume that a straightforward port of Flash VM would have produced an order of 57 MB .wasm build file, this would definitely not fly on a live site. Hence either a really smart DCE and well size optimized builds, or really good central distribution mechanism would be needed (though page first time visit experience would be pretty bad with that). With Wasm there is no offline download possible ("installing your page, please wait")

Kongregate and other Flash gaming portal sites were bit really hard by the “Flashpocalypse”. Adobe could have saved a lot of sites and content from Flashpocalypse by developing that asm.js/Wasm bridge VM even as late as 2017, but they are not a charity, and all likely it would have been just a temporary transitional technology to help devs migrate away from Flash to web technologies, unless Adobe would have had a big business plan vision to somehow really rebirth the Flash technology over to Wasm - which we now know they didn't.

Finally in 2017 Adobe announced that developers should by now have moved on to WebAssembly. So that is an end of an era.

There is this project that looks to be making substantial progress at preserving Flash games: https://ruffle.rs/

As much as Adobe wants to take Flash to the grave with it, it seems that some guys aren't ready to let it go. Hopefully the same will happen to other companies such as Unity / Valve when they finally drop interest in their monetisation platforms.

http://tinyurl.com/shewonyay - Thanks so much for those who voted on my GF's Competition Cosplay Entry for Cosplayzine. She won! I owe you all beers :)

Mutiny - Open-source C++ Unity re-implementation.
Defile of Eden 2 - FreeBSD and OpenBSD binaries of our latest game.

This topic is closed to new replies.

Advertisement