Why didnt flash just compile to javascript/webgl?

Why didnt flash just compile to javascript/webgl?

well that's because javascript/webgl are not binary compiled code, they're human readable programming languages just like flash was;

as u know, compilers convert human readable code to machine code or to virtual environment codes:

• c++ to asm (further steps take place to turn this into the actual targeted cpu instruction sets, x86, x64, amd, sse, avx, etc…)
• java to javabyte code (to run in jvm using a jre)
• scumm to scumm v6 bytecode (to run in scvm .. haxe platform… or whatever Monkey Island was interpreted on ?)
• fla (flash files) to swf (to run on the security plagued interpreter that could easily let one hacker chat with another on your pc while u clicked on hapless white rabbits)….errm… no thank you, sir

EternityZA said:
I transpile into javascript/webgl.

ok leet's be clear here, in simple terms:

• u write yr webgl code in glsl (ogl es v2, v3 or later)
• this code is wrapped up in a javascript script code section
• which is in turned wrapped up in html (so u can still benefit from css as well)
• then when you run the whole thing, your browser loads the html, the js is interpreted which ultimately calls webgl to rasterize;

they key thing is that you're not compiling from one language to another (per-se), your browser is interpreting as usual … of course, u can say that the glsl part is compiled to a shader object that will run on the gpu.. but that's all really;

when u understand this, u should now understand that (fla) Flash code was not designed to be interpreted on the fly like browsers do, it was designed to be compiled into a runnable/executable proprietary format that was executed by a Flash player v1million (goodness sakes!);

But more importantly, Flash & ActionScript code were typed languages with variables such as String, Array, etc… whereas Javascript is weakly typed and often called untyped because it doesn't enforce types. So u see those 2 couldn't really marry well;

in an ideal world, Flash code and the NPAPI could still exist, the code complexity behind NPAPI and security vulnerabilities of the two, were just not helping;

finally, the uptake of HTML5 also means that things are better now than a port of npapi and flash to another language, no need really..

we're supposed to have fun here man, not suffer the consequences of poor programming languages -sorry flashers lol-

have fun ?

You do in a sence “compile to javascript” though, “transpiling” seems to be the most accepted term. For example I compile my entire java application (empirerising.net) to javascript. a java application that could just as easily run on my desktop VM (I use a tool/library called TeaVM). even though java is type safe and completely different from javascript. I know Unity engine also allows for transpiling when targetting the web and I assume it transpiles from C#. So yea javascript is certianly not “binary compiled code” but more and more it gets used as if it is :D (what the transpiler outputs is certianly not human readable anymore even though its “plain text”)

then about webgl, Yea in my case sure I port glsl over to webgl but for flash I was thinking more about using webgl in the background (so the flash developer doesnt actualy use glsl or anything, he just continues programming in flash… the compiler ("transpiler") and runtime libraries would just use webgl in the background for the actual rendering.

It is doeable, even for shock wave format files, but it would mean exposing all IP of Adobe bounded to Flash, as JS is client compiled, Plus, it would take a lot of effort, and, not realy outsmart html5 developers. My opinion.

Ah I guess the IP aspect makes sense, they do after all still sell their other horribly overpriced solutions like illustrator.

EternityZA said:

As I grew up in the golden era of flash content and have fond memories of it it saddens me a little to see it die (even though I 100% agree with the reasons, all NPAPI plugins needed to die) but even though the flash plugin needed to die I don't see why flash itself needs to die with it, why cant it just compile to javascript and use use webgl? keeping all existing tools and projects intact. Simply requiring the flash developer to recompile. Did adobe not find it worth the effort or is there other reasons why that could not work? (ok I'm making it sound easy, There would be alot of work for adobe to do and I'm sure there would be nasty edge cases when compiling existing projects but considering the amount of flash content out there I don't see why adobe didn't go this route)

I don't know how big the community is now, but recently it was recognised as something that wasn't just dying off despite the move to HTML games. I think it might be a little late to do something about it, but yours is a really good idea.

I'm sure it wouldn't be “just” compiling. It would be transpiling the flash project into another project using a specific set of features, solving the flash objects in a particular way. Some assumptions would have to be made, but plain canvas might be the way to go. Using WebGL would be applicable to some project. Determining when to utilise what might be a challenge.

I'm not sure what @ddlox points are exactly. They seem to think that compiling to javascript isn't compiling, then they proceed to comment on why Flash wasn't meant to do this and that javascript should be less fit because it isn't typed, overlooking many other projects that compile to javascript (even strongly typed languages). What "flash is meant to do" is in my opinion is besides the point as long as fla and as3 can be parsed and turned into anything. I'm also at a loss as to why you'd necessarily need to expose any IP. I think that @eternityza's suggestion is something that could be realised.

But it's a lot of work for sure, and it might be difficult to get a result similar to that of the original fla project.

SuperVGA said:
I'm also at a loss as to why you'd necessarily need to expose any IP

At best you can obfuscate javascript instructions, but anything that client can run in html5 browser must be delivered to his js compiler straight. Is there anything you are hiding behind the shelfs?

JohnnyCode said:

SuperVGA said:
I'm also at a loss as to why you'd necessarily need to expose any IP

At best you can obfuscate javascript instructions, but anything that client can run in html5 browser must be delivered to his js compiler straight. Is there anything you are hiding behind the shelfs?

Ah, alright. I thought you were referring to Adobe IP. Still though, it's no different from other clients. The executables are (often) delivered via a secure connection, and the logic contained within the client can be reverse engineered, have its assets extracted etc. Js applications are just as secure as any other, whether delivered to a full browser or within a dedicated wrapper.

SuperVGA said:
I'm not sure what @ddlox points are exactly.

I was coming from the direction of flash and npapi "works" that could not be transpiled to javascript without carrying sins of their past (for the reasons I mentioned and others not mentioned here) - that's in a nutshell what i was saying, sorry if this wasn't clear ?

but yes i do agree that where IP is not an issue such as with C++ then the concept of transpiling a language to another is nowadays slowly becoming common ground (like emscripten, etc…) and flash alone could benefit from this ground too in this direction, but with html5, flash is not really needed. Remember: Flash came about really because HTML at the time was not rich enough to do things Flash did.

Someone at Adobe had a Eureka moment and thought ‘what if we let users/browsers download a player that can run our scripted code’ thus Flash was born. And flash overcame … well for a moment … the limitations of HTML;

but today HTML5 is beefier and it can even play mp4 video with a simple which the old HTML did not do and hence u needed Flash for this…(for example);

so yes i understand the nostalgia, i have also written flash image gallery code that loaded a server-side PHPObject and created an animated login window which i miss -lol- but u have to understand that all this was because of “lack of features” in html back then. This is different today; html5 is alot richer;

if Adobe decides to create a tool that transpiles fla to js to use webgl, fine, great! but it is not necessary for this reason alone;

hope this clarifies my answer ?

ddlox said:
if Adobe decides to create a tool that transpiles fla to js to use webgl, fine, great

I think if someone was to do it, it wouldn't be Adobe. I think those in the flash community might benefit from it, it will make them productive "faster" compared to learning another framework or getting into web development. Adobe though, I doubt they care at this point.

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.

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.

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.