Hi there, gonna start with the basic disclaimer stuff
I'm just a dev who like to work with ActionScript 3.0, I got nothing to do with Adobe (eg. no special insider knowledge, connection or anything), in fact I would assume that I'm more a pain in the ass than anything else to some people .
At a personal level I work mainly with ActionScript 3.0, Redtamarin and Adobe AIR,
and I keep an eye around for different stuff and trying to figure out what may happen or not
in this fast paced technology world.
Such disclaimer is necessary so you would not misinterpret the following guesses, OK let unravel this thing.
Right now I see a lot of people being excited by this
Adobe AIR 23.0 - Feature 4178275 - HTML Target for Air (WebGL / WebAssembly)
On different forums you may have seem some message to votre for the above.
Based on that, which we can consider "public record", and other little things, let's try to form an educated guess.
This thing "convert magically AS3/Flash/AIR to HTML/JS" seems to to be the wet dream of many developers, but is it really ?
First, this is not the first time that some ppl experiment with this
Adobe Blog Convert Flash to HTML Files with Wallaby onLabs Now! (2011-03-08)
“Wallaby” is the codename for an experimental technology that converts the artwork and animation contained in Adobe® Flash® Professional (FLA) files into HTML. This allows you to reuse and extend the reach of your content to devices that do not support the Flash runtimes. Once these files are converted to HTML, you can edit them with an HTML editing tool, such as Adobe Dreamweaver®, or by hand if desired. You can view the output in one of the supported browsers or on an iOS device.
Adobe Labs Wallaby (2011-03-08)
"Wallaby" is the codename for an experimental technology that converts the artwork and animation contained in Adobe® Flash® Professional (FLA) files into HTML. Wallaby is not a final product and is still in the testing and validation phase. We are not yet able to commit to a roadmap for this experimental technology.
Google Code Blog Swiffy: convert SWF files to HTML5 (2011-06-28)
Some Google projects really do start from one person hacking around. Last summer, an engineering intern named Pieter Senster joined the mobile advertising team to explore how we could display Flash animations on devices that don’t support Adobe Flash player. Pieter made such great progress that Google hired him full time and formed a team to work on the project. Swiffy was born!
Today we’re making the first version of Swiffy available on Google Labs. You can upload a SWF file, and Swiffy will produce an HTML5 version which will run in modern browsers with a high level of SVG support such as Chrome and Safari. It’s still an early version, so it won’t convert all Flash content, but it already works well on ads and animations. We have some examples of converted SWF files if you want to see it in action.
Adobe Labs HTML5 Converter for Adobe Captivate 5.5 (2011-11-09)
The HTML5 Converter for Adobe® Captivate® 5.5 is an experimental technology that converts SWFs generated by Adobe Captivate 5.5, the industry-leading e-learning authoring software for rapidly creating and maintaining interactive e-learning content, into HTML5 format. Reuse and extend the reach of your content to devices that do not support the Adobe Flash® runtimes.
TechCrunch Shumway, Mozilla’s HTML5-Based Flash Player Replacement, Lands In Firefox Nightly (2013-10-03)
BugZilla Bug 1243870 - Firefox Component Shumway is defunct. Move to Graveyard:Firefox Graveyard and close bugs in component (2016-01-28)
Firefox::Shumway component can be moved to the Firefox Graveyard component. People can report Shumway bugs on GitHub: https://github.com/mozilla/shumway/
Google Ads Developer Blog Sunset of Google’s Swiffy tool (2016-06-15)
TL;DR: Swiffy will stop converting SWF files from 1st July, 2016.
Recently, we announced that we're transitioning all of our display ads to HTML5. As part of this transition, we're sunsetting our Swiffy Flash conversion service and support for the Swiffy Flash extension on July 1st 2016. After this date, you will no longer be able to use either to convert SWF files to HTML5. We will continue to serve the Swiffy runtimes, so any file you convert before the sunset date will continue to play.
Today more consumers are using the web in HTML5-compatible environments than Flash-compatible environments. In order to reach as large an audience as possible, we encourage everyone to transition to HTML5 authoring.
Developers who currently create Flash SWF files have several ways to switch to HTML5, including Adobe Animate and Google Web Designer. If you need to play an existing Flash SWF file in your browser alone, you may be able to use Mozilla's Shumway.
Let's say those are the principal projects, we could also mention many other projects
For Falcon/FlexJS, it seems that FlaconJS went renamed to FalconJX, then FlexJS got developed on top it.
In short, Falcon was supposed to be the next "Flex compiler", Falcon was compiling to SWF,
but after Adobe donated the project to Apache, then FalconJS surfaced and added a new target "HTML/JS", but then 2 problem surfaced
- how to convert the Flash API (AVMGlue) ?
- how to convert the Flex framework based on the Flash API ?
So FlexJS is updated, probably gonna improve over time, but still it is not an effort fully backed up by Adobe (as far as I understand).
Here my point, converting AS3 or SWF or Flash/AIR to HTML/5 and/or JS etc. have been already attempted many times, from many different angles, from many different people and/or big corporation.
We never heard back from the Adobe Wallaby project, projects by both Google (Swiffy) and Mozilla (Shumway) got killed, and other surviving projects like FalconJX/FlexJS are not dead but do not benefit from the engineering power of a big company like Adobe.
So voila converting AS3 to JS (or SWF to HTML, or any other way you put it) is something hard to do, it's not a trivial task that anyone could build over few weeks.
Also, from the many different people who had a "try at it", they had different interests
- Google Swiffy was clearly motivated by the advertising
I mean the sunset of the tech been announced by "Google Ads Developer Blog"
- Falcon/FalconJS/FalconJX/FlexJX are motivated by Flex
as maybe big corporations (bank/trader notably) have invested heavily in Flex
but make no mistake the see Flex as a kind of Java that works on the web
it's not the same perspective as using AS3 to build apps, eg. Flex != AS3.
look at the video posted in an earlier post Open Discussion about Falcon and FalconJS
- Shumway right from the start wanted to rewrite Flash in JS
even with TypeScript etc. it failed (as the many other attempt from other ppl before
Gordon, smokescreen, etc.) -- side note the name of ALF is "Gordon Shumway"
That's my other point: drinking the kook-aid of HTML5/JS can bring big disappointments,
repeating that the tech is ready to do anything than Flash can do is imho not true yet.
It is also why I write this little thing about "HTML Target for Air (WebGL / WebAssembly)".
By thinking that HTML/JS can solve all your problem and turning your back on things like AVM2 and/or AS3, or simply considering them as "just a nice syntax" to publish to HTML/JS is a bit insane.
First, WebGL / WebAssembly is not even finalised, it could go in any direction (or could even be killed too), and if WebAssembly exists in the first place it is because people finally realised the limitation of JS runtimes in the browser, as "we made it run faster for many years but it is still slow as shit because those JS dev keep doing stupid shit with it".
But OK, let's try to not be too negative here, let's imagine a WebAssembly completely finalised and working quite well in the major browsers like Chrome, Firefox, IE/Edge, etc.
There is still another problem, "as is" WebAssembly is not following the same structure as a SWF file, you can not just compile SWF bytecode to WebAssembly, add a bit of supports for API (like the Flash API), and expect it to work nicely.
To put it simply, WebAssembly is not bytecode, it is an AST (abstract syntax tree) structure which is faster to parse than to parse JS itself.
What people hope is that (explained clearly on Wikipedia)
The initial implementation of WebAssembly support in browsers will be based on asm.js and PNaCl. After the minimum viable product (MVP) release, there are plans to support garbage collection which would make WebAssembly a compilation target for garbage collected programming languages like Java and C#. The team working on WebAssembly includes people from Mozilla, Microsoft, Google and Apple.
If it work for Java/C# it should works for AS3/SWF right ?
Except that this MVP (Minimum Viable Product) has not been produced yet.
So even if millions of people vote for Adobe to produce a magic converter to produce a WebGL/WebAssembly target for AIR, they (Adobe) can not go faster than what WebAssembly produce.
That said once WebAssembly is in a state where people at Adobe can work with it, with their experience on the Flash Player / Adobe AIR runtime, such other projects like Wallaby, CrossBridge that convert C++ to SWF, and maybe with projects like FalconJX/FlexJS, yeah there is definitively something to do here.
Someone on the JIRA posted that too
Adobe Carreers - Sr. Software Engineer, Web Platform Technologies
Adobe is looking for a senior, experienced web engineer who can drive forward vision on front-end cross-platform application framework design and development as well as imaging architecture in a constrained environment. We’re building a new platform on which to take our world-class media editing products onto new surfaces in order to expand the reach of our products. We want you to play a pivotal role on a small team dedicated to changing the way we develop here at Adobe.
Maybe it is related, maybe not.
If you search a bit in transversal ground you can find also this open source project
adobe/skia Experiments and contributions to Skia project
humm, what is Skia ?
Skia is an open source 2D graphics library which provides common APIs that work across a variety of hardware and software platforms. It serves as the graphics engine for Google Chrome and Chrome OS, Android, Mozilla Firefox and Firefox OS, and many other products.
Other news like the new support for the NPAPI plugin for Linux mentioned earlier,
and the mention from Adobe of willing to publish a CEF (Chromium embedded framework) ANE in the post The Best Move that Adobe Could Do, gives bit of transversal infos.
Again, I have no insider infos, I'm just a guy looking around and trying to make an educated guess, so here my conclusions on all that.
For the WebGL/WebAssembly target for AIR, Adobe is just humouring developers,
they didn't announced a project publicly, in short it cost them nothing to let developers vote for that "issue".
You said "issue" ? yes it is an issue, or at least a problem, but only for the ex-Flash Community but also for the Web community at large.
The problem is the following: a lot of people produced content in Flash and so there are a lot of this content still living on the web as SWF files.
So don't hold your breath, a "WebGL/WebAssembly target for AIR" is unlikely to happen soon ("soon" as in the next 12 months).
But even is such thing happened, it would not be in the best interest of Adobe, they would move from supporting the "Flash Player" to supporting this WebGL/WebAssembly simili-runtime, and imho they want to get out of this "mess" (as they don't seem to want to be seen as a developer company like Google or Microsoft).
Let's be clear, Adobe stopped to promote their tech, and tried to reduce as much as possible their involvement with their (ex-)flash-dev community, but still have to support their tech because users still consume plenty of Flash/SWF online and they have no control over those users (same as the browser vendors).
Adobe have the same problem as the Browser vendors, but from a different point of view.
It is the same issue as mentioned above: there are many SWF files online, but most importantly users keep consuming them, because users don't give a shit if it is Flash or HTML5, they just want to watch video, play games, and other entertaining stuff like that, and those users also don't care if they do that in their desktop browser or their mobile device, they just want it to works, whatever it is.
So for browser vendors, they have to keep supporting "playing Flash/SWF" for their users,
and so for Adobe the have to keep updating Flash, at least for security reasons.
And yeah even if Google publicly announced to "ditch Flash", see this And Here It Goes Again Flash Is Dead, imho it is a bluff, well... you know how it is, if you don't try you don't really know if it can works or not, like a bluff when you have a shitty poker hand.
Users may or may not accept that, but don't get fooled, the final users will decide, the same as when Firefox decided to block completely Flash and many users moved to use another browser.
If you look at it globally, there are a lot of big corporation having some not-equally aligned interests and they do small or big strategy moves.
Google plan to block Flash ? hmm let make the Flash Player plugin not linked so much to Google Chrome and publish a NPAPI/PPAPI Flash Player for Linux on the side.
So it's not really a big battle between Adobe and Google, but more about being in such a position where you can not be pointed as the "bad guy" that pisses off everyone .
Let's come back to Google Swiffy a bit, there, google was not trying to solve the global problem of users trying to consume Flash in the browser, nope, the project was closed source in the first place, it was there only to appease google customers who wanted to keep publishing Flash ads for the browser.
Same for Adobe, following Google with the PPAPI in Chrome was showing as "hey we support a new plugin standard etc." but my guess it was basically saving them to do this kind of work themselves (alone vs in coop with google). But now that Google change its stance, well then Adobe changes theirs too, but really it is "fair game".
In short (here your TL;DR), if Adobe let you vote for an "HTML Target for AIR" it is mainly to not be seen as the "bad guys", imho they have no plan to do that because of all the thing mentioned above: it is hard work, Google and Mozilla already failed to do that, WebAssembly is not ready.