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.
In Adobe's defense, they kinda did try that: AS3 was supposed to become JS2/ES4 and they also released a bunch of somewhat-useful documentation on the SWF file format. They even released AVM2 as free software (called "Tamarin") with the idea that Firefox would replace SpiderMonkey with it. The web community stuck it's nose up at ES4 and the SWF documentation was kind of half-assed.
Adobe's idea at the time of the HTML5 transition was that they were going to completely replace Flash with the Edge Suite, while Flash Player became an expensive-to-license compilation target for Unity. Hence, the whole "premium licensing" debacle that smacked of "we don't know who our customers are, but some of them aren't using Creative Suite, so let's try and charge them lots of money for things the web can already do".
The problem is ActionScript is pretty far from the EMCAScript you get in browsers - ActionScript was based on a proposed standard for ECMAScript which was later abandoned, so it's pretty much a different language now.
There's many reasons this didn't happen. Some of them Adobe's fault, some not.
The main thing to realize is that Adobe based AS3 on many leading proposals for Ecmascript 4. Ecmascript 4 would lay the groundwork for future versions of javascript, etc. Flash would still be closed source, but the language would be useful elsewhere in the browser. Several people have described the political issues surrounding this ES4 situation in far more detail, and how we arguably ended up the worse for it:
So, why didn't Adobe just open source the flash plugin? One main reason not to was Microsoft:
http://en.wikipedia.org/wiki/Microsoft_Java_Virtual_Machine#...
Another reason was, naturally, control. Both for Adobe and for user development. The Flash player was quirky, but incredibly consistent with decent performance. There really was no other option... js, java applets, activeX, they all had significant weaknesses due to differing availability and performance.
If you wait around long enough in web development, you will have seen this type of situation many times. Haxe is a "free agent" that can break this cycle imho. It is not tied to a company like Typescript or Dart, nor is it tied to corporate controlled committees like ES4. It has an incredibly gifted language author, and a great team of developers. It's also very mature at this point (> 5 years old).
I've used Haxe professionally for just under 5 years now.
AS3 was based in ES4 specification,"superseeded" by ES5.So ActionScript was in fact pretty opened and could have been today's javascript.
I dont think one can compare AS3 and Swift. In fact Microsoft had it's own implementation of ES4, Jscript.net.
> Flash is now relegated to a "second-choice" technology for web applications,
"Thanks to" Steve Jobs,that didnt want anyhting on his plateform he couldnt control.
IOs is a closed ecosystem,IOs has more developpers and apps than ever.There is nothing to learn here but the fact that they control their plateform,from end 2 end,and users keep on coming.
ActionScript 2.0 was very much like JavaScript, as it specifically attempted to be ECMAScript compatible. There were some dialect differences, but they were essentially the same language with different APIs (Flash API vs browser DOM).
ActionScript 3.0 added optional static typing and classes and efficient binary blob handling and other features and at one point was going to serve as the basis for ECMAScript 4.0 via the Mozilla Tamrin project (so ActionScript would have actually been modern JavaScript) but this was killed (primarily by Microsoft and Yahoo) for political reasons.
AS3.0 was actually a pretty nice language and I would have loved to see it replace JavaScript back then as the usable set of JavaScript features is still quite a bit behind where ECMAScript4 would have brought it years ago.
You can check out Adobe AIR; it uses Actionscript 3 and it deploys to web, desktop, Android, and iOS. In practice you can straight up copy-paste an AS3 codebase into an AIR project and have it work 99%. And I like to think that Adobe is more committed to supporting AIR since it's available for mobile.
Few remember, but Adobe tried to submit a variant of ActionScript 3 as an ECMAScript candidate but the open web folks were dubious and it went nowhere.
That's not the same thing as open-sourcing the Flash authoring tool, but they still sell the modern variant Animate.
They could open source the player, but why bother -- the browser vendors have basically shut the gates. The swf file spec is pretty well documented but the player architecture doesn't map well to 2d canvas performance wise and is nearly a complete impedance mismatch for webgl.
Your timing is off, ActionScript 3 was based off the doomed ES4 which had classes etc. Adobe was even a main participent in the standardization process iirc.
I agree. I had to go back from AS3 to AS2 for a project and it felt like a step backwards, and AS2 is more like Javascript. Adobe has also open sourced the AS3 runtime. But of course the practicality is that we have Javascript in browsers, and there's a big get-the-job-done benefit to using a common language.
I wrote AS3 and mxml for adobe flex for several years. AS3 was in many ways ecmascript 4, and was IMO pretty far ahead of its time. Lots of things we get excited for today feels like stuff we took for granted on the web in the flash player ecosystem years ago. Don't get me wrong, there were times where it was a nightmare, but back when cross browser javascript was a struggle if it was even possible, we were able to ship a lot of great stuff.
Yeah, that's what I thought. I remember hearing that you couldn't magically export your AS3 into HTML5 like you can with something like GameMaker.
Somewhat ironically, due to something like Ruffle, exporting to an SWF like before might actually be a viable option again, since you'd get all the nice sandboxing of modern browsers while having pretty-ok flash compatibility.
I think it's more down to engrained quirks in the existing implementation. IIRC, adobe gave mozilla an open-source implementation of actionscript 3 back in the day to try and help legitimize it as an ECMAscript implementation.
The situation is not quite so cut and dry, I think. AS3 was supposedly intended to be an implementation of ECMAScript 4, which was derailed by the (ECMAScript 3.1) Harmony project.
Also, I believe the Tamarin AS3 compiler used by Adobe is a collaboration with Mozilla, and both the Adobe Flash Player and Mozilla TraceMonkey engine use the same JIT compiler.
As a former Flash/Air/Flex dev way back in the day I agree, AS3 was a great language that JavaScript still hasn't fully caught up with in some ways but it was only really viable to author ActionScript within Adobe's endorsed editors and their Eclipse fork abomination. Being confined to the Flash runtime also made life difficult as a general purpose programming language. It was a rough development experience and no amount of language superiority would ever fix that.
I mean, Adobe Animate (the new name for Adobe Flash) still exists, and can target HTML/JS/Canvas/WebGL. It still supports ActionScript 3.0, so the same platform that could be used to create animations and interactive games should still be usable.
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.
reply