HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
ruffle-rs
ruffle
Rust2019–2026
ruffle-rs / ruffle

ruffle

A Flash Player emulator written in Rust

48Distinct people
59Mentions
0Explicit recommenders
18.9KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A Flash Player emulator written in Rust

GitHub

Where it is used

  • PHP-Nuke.Titanium.Dev.4 — The Ruffle Web Core (https://github.com/ruffle-rs/ruffle): is what we use to enable flash site wide, you will not need any browser plugins. Source

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year59 dated mentions

Observed mentions: 2019-08-17 14:10:33 UTC to 2026-09-07 08:35:36 UTC.

051015202019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 4 mentions; 2 submissions, 2 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 19 mentions; 2 submissions, 17 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 6 mentions; 1 submissions, 5 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 10 mentions; 0 submissions, 10 comments20222023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 10 mentions; 2 submissions, 8 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC422
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC19217
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC615
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC10010
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC1028
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC303
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC211
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC505

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
website | demo | nightly builds | wiki Ruffle Ruffle is an Adobe Flash Player emulator written in the Rust programming language. Ruffle targets both the desktop and the web using WebAssembly. Table of Contents Project status Using Ruffle Building from source Prerequisites Linux prerequisites Desktop Build macOS Web or Extension Android Scanner Exporter Structure Sponsors License Contributing Project status Ruffle supports ActionScript 1, 2 and 3 pretty well, but it's still not finished by any means. Please report any issues in the Issue Tracker. Using Ruffle The easiest way to try out Ruffle is to visit the web demo page, then click the "Select File" button to load a SWF file of your choice. Nightly builds of Ruffle are available for desktop and web platforms. For more detailed instructions, see our wiki page. Building from source Prerequisites Latest stable channel of Rust Java, available on your PATH as java (required for building the library containing the builtin Flash classes for ActionScript 3) Linux prerequisites The following are typical dependencies for Linux: Ubuntu/Debian: sudo apt install pkg-config libasound2-dev libudev-dev libfontconfig-dev libfreetype6-dev libssl-dev default-jre-headless g++ Fedora/RHEL: sudo dnf install pkgconf-pkg-config alsa-lib-devel systemd-devel fontconfig-devel freetype-devel openssl-devel java-latest-openjdk-headless gcc-c++ Desktop Build Use the following command to build and run the desktop app: cargo run --release --package=ruffle_desktop To run a specific SWF file, pass the SWF path as an argument: cargo run --release --package=ruffle_desktop -- test.swf To build in debug mode, simply omit --release from the command. Desktop has a few optional features which you can specify via --features, comma separated: tracy: Enables profiling to Tracy. You may need to expand the log filter to see everything, e.g. RUST_LOG="warn,ruffle=debug" tracy_images: Enables Tracy frame captures. Implies tracy. tracy_avm: Enables profiling AVM execution with Tracy. Implies tracy. render_debug_labels: Enables debug labels during rendering, useful for debugging graphics with renderdoc or similar. macOS Ruffle desktop can be built from our Homebrew Tap: brew install --HEAD ruffle-rs/ruffle/ruffle Note: because it is HEAD-only, you'll need to run brew upgrade --fetch-HEAD ruffle each time you want to update. Web or Extension Follow the instructions in the web directory for building either the web or browser extension version of Ruffle. This project is tested with BrowserStack. Android Follow the instructions in the ruffle-android project for building the Android application of Ruffle. Scanner If you have a collection of "real world" SWFs to test against, the scanner may be used to benchmark ruffle's parsing capabilities. Provided with a folder and an output filename, it will attempt to read all of the Flash files and report on the success of such a task. cargo run --release --package=ruffle_scanner -- scan folder/with/swfs/ results.csv Exporter If you have a SWF file and would like to capture an image of it, you may use the exporter tool. This currently requires hardware acceleration, but can be run headless (with no window). cargo run --release --package=exporter -- path/to/file.swf cargo run --release --package=exporter -- path/to/file.swf path/to/screenshots --frames 5 Structure core - core emulator and common code swf - SWF and ActionScript parser desktop - desktop client (uses wgpu-rs) web - web client and browser extension (uses wasm-bindgen) render - various rendering backends for both desktop and web video - video decoding backends flv - Flash Video decoder wstr - a Flash-compatible implementation of strings scanner - a utility to bulk parse SWF files exporter - a utility to generate PNG screenshots of a SWF file Sponsors You can support the development of Ruffle via GitHub Sponsors. Your sponsorship will help to ensure the accessibility of Flash content for the future. Thank you! Sincere thanks to the diamond level sponsors of Ruffle: License Ruffle is licensed under either of Apache License, Version 2.0 (http://www.apache.org/licenses/LICENSE-2.0) MIT License (http://opensource.org/licenses/MIT) at your option. Ruffle depends on third-party libraries under compatible licenses. See LICENSE.md for full information. Contributing Ruffle welcomes contribution from everyone. See CONTRIBUTING.md for help getting started. Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you shall be dual licensed as above, without any additional terms or conditions. The entire Ruffle community, including the chat room and GitHub project, is expected to abide by the Code of Conduct that the Rust project itself follows.
Read the full README on GitHub

What Hacker News says

59 sources
> something I was doing with my "strict MVP" build of Anubis' WASM wasn't in fact sticking to just the MVP features of WebAssembly Fun fact, this _used_ to be the case - wasm32-unknown-unknown had extra non-mvp features added later, which in my eyes has been a breaking change on stable. You're not the first person to have been bitten by this, there's [1] and a similar story in Ruffle [2]. Weirdly, the response from the rustc side (IIRC we also talked with one of the devs of wasm component on discord a bit around 2024) has contained a lot of (paraphrasing) "in retrospect we think wasm32-unknown-unknown target was designed badly*, so we'd prefer if you either dealt with it or switched to another wasm target <with its different set of downsides> than us fixing it". (*I acknowledge that the way std was implemented on that target was unusual
Read the rest
and "not clean", but it works _really well_ for a lot of people.) > I looked into the process involved for rebuilding the standard library twice: once with only MVP wasm features enabled and once with an "all yes config" like usual. Based on some research I did this seemed like a massive pain. That's what Ruffle does [3], it's a bit unfortunate but wouldn't call it a massive pain. [1] https://internals.rust-lang.org/t/can-we-have-either-a-new-t... [2] https://github.com/ruffle-rs/ruffle/pull/18397 [3] See lines 55 and 117-127 in https://github.com/ruffle-rs/ruffle/blob/6890c618daab3153343...
In It took a year to ship WebAssembly in Anubis
That documentation, for stubs, can be somewhat misleading. It just looks for the presence of an avm2_stub_method function call anywhere in the method, which may mean a method that's entirely a stub, or as is the case for NetConnection.connect, a method that is stubbed under specific conditions. NetConnection.connect is stubbed for specifically non-null, non-http commands (generally this is RMTP/RTMFP). See https://github.com/ruffle-rs/ruffle/blob/df11c2206bc6be0a329...
In Flashpoint Archive – Over 200k web games and animations preserved
Rust only supports & and &mut references. This was a deliberate choice early in the development of the language. &own, &pin, and &uninit are proposals for additional pointer types. They don't actually exist in the type system right now, but other parts of the compiler do have to care about them. Another blog post that floated around here about a month ago called these "inconceivable types"[0]; adding them to the type system would allow formally extending these behaviors across function boundaries. Like, right now, implementers of Drop can't actually move anything out of the value that's about to be destroyed. The Drop trait gets a &mut, but what we really want is to say "destroy this value over there". Rust's type system cannot understand that you own the value but not the place it lives in. What you need is an "owned reference" - i.e. &o
Read the rest
wn, where the borrow checker knows that you can safely move out of it because it's going to get destroyed anyway. Rust also can't support constructors, for the same reason. What we really have are factory functions: you call them, they return a value, you put it somewhere. This is good enough that Rust users just treat factory functions as if they were constructors, but we can't do "placement new" type construction with them, or partial initialization. At least not in a way the type system can actually check. &pin is a first-class version of Pin<T>. Rust was originally designed under the assumption that any type can be memcpy'd at any time; but it turns out not being able to move types is actually super useful. Fortunately, it also turned out you could use smart pointers to pin types, which was 'good enough' for what it was being used for - async code. Actually, the blog post that coined "inconceivable types" was specifically talking about writing async functions without async. It turns out Future impls encode a lot of details Rust's type system can't handle - notably, self-borrows. If a value is borrowed across an await, what's the type of the variable that got borrowed from? It's really a negative type: borrowing T to get &T also turns T into !'a T that you can't access until 'a ends. Each borrowed reference is paired to a debt that needs to be paid back, and to do that you need lifetime variables and syntax to explicitly say "pay back this debt by ending this borrow's lifetime". How much of this complexity is actually needed is another question. There's a problem that each and every one of these reference types (or, anti-types) is intended to solve. Obviously if we added all of them, we'd overcomplicate the type system. But at the same time, the current Rust type system is already known to be oversimplified, to the point where we had to hack in pinning for async. And it's already kind of ridiculous to say "Well, async is all special compiler magic" because it prevents even reasonable-sounding tweaks to the system[1]. [0] https://blog.polybdenum.com/2024/06/07/the-inconceivable-typ... [1] For example, async does not currently have a way to represent "ambient context" - i.e. things we want the function to be able to access but NOT hold onto across yields. That would require a new Future trait with a different poll method signature, which the current Rust compiler doesn't know how to fill or desugar to. So you have to use the core Future trait and signature which doesn't support this kind of context borrow. To work around this limiation involves a lot of unnecessarily verbose code to drop and regain context between awaits, i.e. https://github.com/ruffle-rs/ruffle/blob/b5732b9783dce5d2311...
In The Algebra of Loans in Rust
Out of curiosity a couple months ago I wondered if I could play my old Proximity flash game on Newgrounds from the browser within the Quest 3 VR headset, and it worked great! That led me to do a little searching, and I discovered that originally the game didn't work in Ruffle, as I apparently did something with the play game button that wasn't normal. But someone put a fix in it back in 2020[1] in order to get my game working again. That was pretty neat. Felt kind of nice that people still cared enough about my old game to make sure it still works in an emulator. I'm glad these people are out there, getting these things working again. There's so many great animations and games that didn't deserve to disappear because Adobe decided it was a prudent business move to just drop all Flash support. Still working on a more in-depth sequel (using
Read the rest
Monogame), and I'm way overdue to make a new web version of the original. Might knock that out once I get closer to getting the sequel out there. EDIT: Just realized Proximity is 20 years old this year. Huh. Probably needs a 20 year anniversary edition. [1]: https://github.com/ruffle-rs/ruffle/pull/1024
In New York Times Flash-based visualizations work again

Showing the 15 most recent of 59 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.