Do you remember back when Unity was preparing an "export to Flash" feature around 2012 or 2013? Yeah, well, that relied on two technologies in Flash Player that together let you port native apps to run inside Flash:
- Domain Memory: WASM, but from the alternate branch of history where ECMAScript 4th Edition became a web standard.
- Stage3D: WebGL, but inside Flash Player
Adobe pooped their pants and decided that people cross-compiling to Flash Player should have to pay for it. So they decided that you couldn't use both features unless you agreed to pay a 10% revshare to Adobe; they would be "premium features" now. This would be enforced with DRM in the Player that checked for a digital signature in your SWF authorizing the use of premium features.
This pissed off a lot of people who were still developing Flash games and, ironically, pushed them to Unity or HTML5 (or both). Adobe saw the writing on the wall and killed premium feature enforcement, but the damage was already done. Bonus points: apparently they planned to pay for ActionScript 4.0 with the revshare money they now weren't getting, and just decided to entirely shitcan AS4 out of spite.
Wow, no kidding! That's fascinating (tangentially I was wondering why they never targeted web, my
guess was it would weaken vendor lock-in and this seems to confirm
that mindset. Though it could also be that web wasn't a very good target in the era when they still cared about Flash.)
>HTML5/JavaScript is here to stay. One cannot not serve the Web! Here it is our task to provide a superior alternative where HTML5/JavaScript is bound to lack.
It was supposed to be a compiled language, in order to solve performance and battery issues on mobile devices.
Being able to say "we fixed one of your biggest complaints / reasons for trying to kill us" sounds like it would have been pretty good marketing, and Adobe with their budget seems like they could have afforded that easily. (I don't know how much it costs to develop a new programming language, but I know it has often been done by a single person in their spare time!)
It sounds like they also had plans to eventually bring AS to the server-side (made largely practical by the same advancements benefiting the client). (Perhaps they could have learned a thing or two from Haxe, with its "compile
everywhere" and CPP transpilation.)
Alas! Now to see if any curious bystanders have bothered to implement it... seems not. (I guess that's not too surprising, we're only halfway* done with AS2/3 implementations as it is!)
Adobe actually was targeting web, or at least trying to: in 2012 they shipped Adobe Wallaby which allowed export of timeline animations to HTML5. Then they replaced it with CreateJS export. Both of these had absolutely zero support for ActionScript and relied on the user to rewrite their app for browser JS. The reason for this is because actually getting ActionScript to work, and work well, is very hard - especially with 2013's mobile web browsers.
The most obvious solution - recompiling ActionScript bytecode or source for the web - would be very difficult, for a number of reasons. While AS2 and AS3 are both ECMAScript derivatives, they differ substantially from the JavaScript we actually ship in browsers. Even basic property look-up deviates significantly from regular JavaScript, either because AS2 has too many compatibility hacks, or because AS3 has too many ES4 features that never actually made into browsers.
If you wanted ActionScript to work, you would need to ship your own AVM implementations, which in 2013 would not be performant on Mobile Safari[0]. Google and Mozilla both did that anyway, shipping interpreters for AVM1 and AVM2 code. For Google's intended use case of porting ads to HTML5, this was fine. Mozilla would eventually abandon Shumway, however, citing performance problems. It was very much ahead-of-its-time. And Google's intended use case stopped making sense as advertisers just used HTML5 tools anyway, so that was shuttered too.
I'm not entirely sure what they meant by AS4 being a compiled language, though. All ActionScript is compiled into bytecodes and can be further recompiled into optimized native code (though AS2 never got this treatment). The language spec PDF seems to hint at ahead-of-time compilation, which absolutely would help iOS, but only to say that such compiled code needs to work the same as the interpreter. Whether that was actually enabled by new language semantics or just intended to be handled with profiling an instrumented AVM4 is something I would like to know.
Implementing AS4 in Ruffle would not be practical without a compiler and player implementation, and as far as I can tell those weren't ever publicly released. The standard library of a language and how events are pumped into it's UI framework are just as important, if not moreso, than how the language describes it's code.
[0] asm.js was a thing in 2013, but it was a Mozilla-specific technology Safari never implemented. WASM would not be standardized until 2017, with Safari support launching that year. At that point Flash Player was already on life support.
- Domain Memory: WASM, but from the alternate branch of history where ECMAScript 4th Edition became a web standard.
- Stage3D: WebGL, but inside Flash Player
Adobe pooped their pants and decided that people cross-compiling to Flash Player should have to pay for it. So they decided that you couldn't use both features unless you agreed to pay a 10% revshare to Adobe; they would be "premium features" now. This would be enforced with DRM in the Player that checked for a digital signature in your SWF authorizing the use of premium features.
This pissed off a lot of people who were still developing Flash games and, ironically, pushed them to Unity or HTML5 (or both). Adobe saw the writing on the wall and killed premium feature enforcement, but the damage was already done. Bonus points: apparently they planned to pay for ActionScript 4.0 with the revshare money they now weren't getting, and just decided to entirely shitcan AS4 out of spite.
reply