Flash rebirth with Ruffle WASM!

Ruffle open source project has the goal to keep any SWF version intact in webassembly

Join the growing community, it’s an amazing project that can let you continue to use As1/2/3 and your Flash development habits!

2 Likes

Looks good and the performance of the samples on the demo page is actually quite amazing!

yeah … curb your enthusiasm here

already mentioned about 1 year ago here
Ruffle - an Adobe Flash Player written in Rust

and that’s the problem

see also those 2 posts
Archive: A Review of Flash Killers
Some Thoughts on the HTML Target for AIR

every single time some projects or even OSS projects try to replicate Flash
the following happen

  • early euphoria “it works!”
  • but it only supports early SWF format
  • everyone rejoice
  • supporting the latest SWF format,
    supporting AS3/AVM2 etc.
    are just seen as some tasks on a todo list
  • nobody think about supporting the Flash API

and then nothing happen anymore

people realise that the SWF format is a bit more complicated than the early tests
people realise that supporting AS2/AVM1 might be possible but still a big effort
people realise that supporting AS3/AVM2 is a fucking ginormous effort
and almost nobody realise that the Flash Platform API supports will be extremely limited

WebAssembly (WASM) is not magic to the point where it will allow a web browser to connect to TCP sockets or UDP sockets, the browser is still limited by what support the Web API

and it is even worst because now the browser does not allow anything to extend its capabilities, you can not write an “extension” that supports what is missing

let me quote in case of tweet vanishing

WebKit will not implement:

Web Bluetooth
Web MIDI
Magnetometer
Web NFC
Device Memory
Network Information
Battery Status
Ambient Light Sensor
Proximity Sensor
WebHID
Serial API
Web USB
Geolocation Sensor (background geolocation)
User Idle Detection

WebKit took the lazy way

and this is justified to protect web users from fingerprinting

and that’s quite ironic, the very same reason that will push everyone to publish their app on the web with browser tech: “hey everyone can use it they just need a web browser” is also the reason why the Web API will always be limited, eg. security aka “we can not run any fucking shit in the browser disregarding user security”

in summary, something like AIR can be extended with ActionScript Native Extension (ANE) and there is almost no limit, so if something is missing and you badly need it you can add it

but the browser, seen as a runtime, even if you can consider it as a “universal runtime” (everyone can run it), can not be extended at all

and for Ruffle or any other similar project that try to emulate the Flash player with browser tech,
they will all fatally hit this wall: shit we can not implement that particular Flash API because we can not extend the browser runtime and there is no Web API to implement that particular feature.

so when you say

I’m not here to diss a project, especially when this one is open source, but people should know what they should expect from such a project

and for that matter I do think another OSS project has more chances of producing something useful (as something that an AS3 dev can actually use to build browser apps)

and web site: https://royale.apache.org/


Now that the Flash player as a plugin has just few months left, if your goal is to continue to use ActionScript to program web apps, I do think Royale is the best bet and for one single reason only: Progressive Enhancement.

The same way JS dev argues with “vanilla JS” vs “JS using frameworks” (see Progressive Enhancement with JavaScript), we already had the very same thing happening in the Flash API

From Building Adobe AIR Applications / Device profiles
and from AIR capabilities for TVs

in short, test with isSupported if the feature is supported on that particular profile, platform, device, etc.

if the feature is supported you can progressively enhance your AIR app,
if not then it is one less feature but the general app is still working even if limited

and that should be the very same approach for web apps
because of the browser runtime there are many capabilities that will check the “no” case,
DatagramSocket.isSupported for example.

Many JS dev already use things like babel and TypeScript

babel claim “Use next generation JavaScript, today.”
TypeScript claim “JavaScript that scales.”

You can see Apache Royale as both “Use ActionScript 3, today” (as use it in the browser)
and “ActionScript 3 that scales”.

Cross-compiling from AS3 to JS or from TS to JS, is pretty similar.

That will not solve the limitations of the browser runtime but with progressive enhancement you can add bits this and there, replicating the Flash API, for ex: implementing the flash.media.Sound class with what is available in the Web API.

My point is you will get results faster with that vs waiting for a project like Ruffle to implements AS3/AVM2, if they implement it one day.