Inside RetroAssembly: Behind the Scenes with the Creator
If you’ve ever dreamed of having a retro game cabinet that fits in your pocket—or more specifically, in your web browser: RetroAssembly might be the closest thing yet. It’s a slick, self-hosted platform that lets you turn your personal collection of ROMs into a neatly organized arcade you can access from anywhere. Upload your games, add some cover art, and suddenly your dusty old (ahem...unorganized!) folders become a polished library that looks like it was ripped straight out of a console’s glory days.
What makes RetroAssembly stand out is just how frictionless it feels. There’s no clunky setup, no endless tinkering with configs, to use the cliche: 'it just works'. Whether you’re on a PC with a controller, or your phone with the on-screen controls, RetroAssembly brings together multiple classic systems under one roof and makes them playable instantly. Add in features like save syncing, rewind, and retro-inspired shaders, and you start to see why this little project is catching attention among retro fans and self-hosters alike.
To dig deeper into how RetroAssembly came together, and where it’s headed, I sat down with its developer, Arian, to talk about the challenges, the ideas, and the experience of building a web-based arcade from scratch.
About the Developer:
How did you first get into programming, and what were your earliest projects or languages?
More than a decade ago, when I was in college, we were taught traditional programming languages like C. I wasn't really good at them and I felt more drawn to some visual things, like JavaScript and PHP — the programming languages for web.At that time, I started building themes for WordPress (the most commonly used blog system) and I felt it's way more interesting than writing C programs to calculate prime numbers within 100 and watching their character-based output.Besides these WordPress themes, as we are talking about retro gaming, I'd like to share a silly 8-bit chiptune music generating program called "Family-Jukebox", which I built around 2015. It's not the earliest project I created but it shows that I started paying attention to retro gaming as a web developer at that time.
When did you become interested in retro gaming and emulation?
I've always liked retro gaming. I was a big fan of the Angry Video Game Nerd. But it was around 2014–2015 that I started paying more attention to playing retro games rather than just watching videos, as I recall. Since I mainly focused on NES at that time, the software I used was VirtuaNES.
Then later, I found RetroArch. As described on its GitHub, it's really sophisticated. Its default configuration file contains more than 1000 lines. Users can tweak a lot of settings to get it working right as expected.
We have to admit that its learning curve is too steep for average users. But I didn't feel frustrated when learning how to tweak it with tons of settings. RetroArch is where I started to become addicted to emulation. I used to configure it on my PCs, laptops, phones, tablets, etc.
Then I got a Raspberry Pi and tried Lakka, the official RetroArch operating system. I also tried other similar projects for other hardware — you might have heard of or used some or even all of them — RetroPie, Recalbox, Batocera.linux, EmuELEC, etc.
Have you worked on open-source or personal web projects before RetroAssembly?
One is a browser extension helping developers quickly look up programming terms within a popup window. I didn't actively promote that product, but it still, luckily, got over 1000 users, most of whom came from organic traffic in Chrome Web Store. However, I didn't have a chance to reach these users. On the one hand, the tool is relatively simple, so it doesn't require much "after-sales service". On the other hand, I didn't realize that I had to organize a community at the time.
BTW, I also occasionally submit patches and raise bug reports for open-source projects. But I didn't spend too much effort on this before, TBH.
What’s your favorite 'era', or generation of retro games? Did that influence in any way which platforms you prioritized for RetroAssembly?
Without a doubt, it is the 3rd generation, and specifically, the NES! Leaving aside its historical status and our childhood memories — these have been discussed by numerous people for countless times — what I like best is its simplicity and its being closer to the essential joy of video games. Pick a game, press start, then it begins. No need to wait for an opening video, no need to read a story, players can just get immersed in another world in seconds.
It takes a few seconds to beat the first enemy after launching Super Contra. Imagine how long would it take in Death Stranding 2? I'm not saying Death Stranding 2 isn't a great game. It's a bit like... we know that The Brothers Karamazov is sometimes considered the supreme summit of all literature (said Albert Einstein), but it is indeed too taxing for most ordinary people to read, especially when one wants to relax and be entertained. Modern AAA titles are going so far on this way.
But I don't prioritize platforms based on my personal bias. In fact, it's basically determined by how easy one platform's emulator can be integrated into the browser lol. For example, I really want to support N64, and quite a few users have also asked for that too. But the reality is, N64 emulation in the browser is still far from mature, so I have to give it up at least for now. For comparison, I never owned a Wonderswan or a Virtual Boy, but they have been supported since RetroAssembly was initially announced.
History and Motivations on RetroAssembly:
How did RetroAssembly get started? What sparked the idea for you to make it?
As I mentioned above, I used to be addicted to setting up RetroArch and other emulators. I loved these. However, I faced some problems with them. Although maybe some of them are not problems with these programs — they may be my own issues.
- The first problem was that I spent a lot of time configuring them. But in comparison, I spent only a little time playing the games. When I updated configurations, things sometimes broke, forcing me to reinstall and causing me to lose save files.
- Another one is, I could not synchronize my progress easily. After saving my game progress on my PC, I was unable to continue it directly on my phone. Maybe copying save files manually would work, but it could be very annoying if I had to do that every time.
Then I began searching for software that might solve these problems, but the results were not ideal.
- Some emulator-related programs only work on a single operating system, like BizHawk for PCs, OpenEmu for macOS (this is a pretty decent application BTW). While some of them, like RetroArch, are cross-platform; however, it was difficult to install them on an iPhone or iPad at that time (now it's available on the App Store). Not to mention synchronizing progress was also a painful problem.
- Then I began searching for some web-based projects other than native programs for their better compatibility for various operating systems. I found some decent projects (I'm gonna talk about them later), but none of them met all my expectations.
Here are some of my expectations:
- It should be web-based. So I can use it on every device with a web browser: phones, tablets, even Chromebooks.
- It should be super easy to use. Give it a ROM, and everything else will function properly. No need for external setup, such as an API key for a metadata scraper service, a PostgreSQL/MySQL/MarioDB database, any environment variables.
- It should show box art instead of plain game titles. But I don't want to download or scrape them manually; they should appear automatically.
- It should help me keep my progress synchronized.
- It should be gamepad-friendly. Navigating through games should be as smooth as on a video game console, while keyboards and mice should be optional. This way, when I exit a game and start another, I can keep my hands on my gamepad.
- It should have touch control support. When I am outside, I can still enjoy the games with my phone using my fingers and the screen. Though it's not very efficient.
With these expectations, I began to look into the possibility of making such a program. Since I used to spend some time learning how to configure RetroArch, I happened to know there was already a RetroArch Web Player that can run within browsers. I believed I could use the technique from that site to create my own project. That's how I got started.
What were you hoping to improve or do differently compared to the web-based emulators that were already out there?
It's a tough question! But as the creator of RetroAssembly, this is also a question I can't avoid.
Let's see "the web-based emulators that were already out there". I've listed some similar open-source projects at the bottom of RetroAssembly's GitHub.
- Some of them are more like prototypes or technical demos. They proved emulation in browsers is possible, but in my view their user experience hasn't been carefully designed.
- Some of them are ROM managers. They have beautifully designed appearances, customizable metadata, embedded emulators, etc. Looks great right? But please allow me to clarify: It's a common misunderstanding that RetroAssembly is a ROM manager like them. That's not how I position RetroAssembly. We don't call the Nintendo Switch a "Nintendo Switch game manager"; instead, we consume games with it. That's the role I suppose RetroAssembly to play for retro games: when users launch RetroAssembly, they are going to actually experience the games, rather than to spend time organizing them and enjoying their box art. For this reason, I put the "start" button in a prominent position on the game detail page, and crafted a subtle animation for launching. The game is not embedded as a part of the page. Instead, it occupies the entire page.
- WebRcade. In fact, I think this one has the most similarities with RetroAssembly. Though its layout is not grid-based, we share a similar goal: not managing ROMs in the browser, but using the browser to play games. We both have first-class support for "spatial navigation", meaning users can navigate between pages with gamepads. Since when users play games they are more likely to use a keyboard or gamepad rather than a mouse, it's more intuitive for users to move their cursor with "↑ ↓ → ←".Apart from the visual parts, the main difference between us is how we manage our content. WebRcade has a "feed-driven" system, which can take some time for a new user to learn, while RetroAssembly is somewhat more straightforward: upload & play, that's all about it.
Conclusion: RetroAssembly focuses on playing, rather than exhibiting.
How long did it take to get a working prototype or MVP running in the browser?
Around a week or so? I don't remember exactly. The most critical part of RetroAssembly is how to integrate an emulator into a browser. So I spent some days understanding how the RetroArch Web Player works, then what I needed to do was to wrap it with an easy-to-use API, like when I write the code launch('Mario Bros.nes'), an emulator running Mario Bros would be shown on the webpage.
Why did you choose Nostalgist.js and RetroArch WASM cores as the foundation? Any notable trade‑offs?
"People who are really serious about software should make their own hardware." This is a quote often referenced by Steve Jobs. For my project, I'd say "People who are really serious about emulation should make their own emulator!" 😂
Just kidding! Nostalgist.js was also created by me but it's not an emulator. It's just a lean wrapper on top of the official RetroArch browser build. I made it while crafting RetroAssembly.
Surprisingly, there aren't any trade‑offs here because of the fact that there are no existing utilities like Nostalgist.js. EmulatorJS is quite popular though; it's used for allowing an emulator to be embedded like a YouTube video, while what I want is to have full control over the emulation. In fact I didn't know about EmulatorJS at the time I was getting started, but looking back, even if I had already heard about it, I wouldn't have chosen it for the reasons mentioned earlier.
Were there any alternative paths (frameworks, libraries) you considered early on?
This part is a bit technical and less relevant to retro gaming, so I'll try to be concise. I initially used a framework called Waku. It's a minimal web framework with some elegant APIs for web developers. As it's not backed by any big companies, its maintenance is quite limited compared to other well-known frameworks like Next.js. I encountered several bugs while working with Waku, and reported some to the team.
The team is quite friendly, but one of the bugs I reported seems to be a very difficult one for them. It's related to adding special characters like spaces or quotes to the URLs can cause the web page to crash. It's important for me as I want the URLs to be easy to understand. For example, if one has a ROM with "Super Mario.nes" as its file name, the URL of the page showing that ROM should also be something like "/library/rom/Super Mario.nes", instead of something like "/library/rom/3248932" containing a random ID number.
It took several months for them to deal with that bug, but I had no time to wait. I switched to another framework called React Router. It's a mature framework and the commercial company behind it is Shopify. React Router is a bit heavier than Waku, but it does the job quite efficiently as well, in general.
Features:
RetroAssembly supports so many systems (NES, SNES, GBA, Genesis, VirtualBoy etc.)….how difficult was orchestrating them all?
Not at all! RetroAssembly is not the first app to do emulation in browsers. It stands on the shoulders of giants who have resolved the really hard problems around emulating in browsers. The maintainers of the emulators and RetroArch are the real heroes behind the scenes.
As far as I know, all mainstream browser-based emulation sites are using this technique under the hood, including the EmulatorJS, the most popular emulation solution for browsers, used by RomM and some other similar projects.
The “rewind gameplay” feature is so nice! Can you tell me how that works ‘under the hood’?
As mentioned in the answer to the previous question, I didn't really spend much effort in this regard. RetroArch provides the ability for rewinding, and I use it. It's that easy.
This is a must-have feature at least for me. Retro games are generally much harder than modern ones: Lives are often limited. The player would often be sent to a start position of the scene after failing. Without rewinding I would never beat a few games lol.
But before I read this question, I didn't even realize that this is a relatively rare feature among emulators for browsers. But I think technically adding this feature shouldn't take too much effort if their maintainers wanted to add it.
What’s your favorite little feature in RetroAssembly that people might not notice right away?
It may not be called a feature, but it is an interesting visual effect: the aspect ratios of default box art placeholder for some platforms are carefully tuned.
The size of the cartridge box art varies from consoles. As the box art images can take a while to be loaded, there's a gray placeholder when the loading process is not finished. However, if we want it looks more natural, the placeholder's size should exactly match the real image being loaded. I spent some time figuring out the aspect ratios for different consoles, like 7/10 for Atari 2600, 25/34 for NES, 7/5 for SNES, etc. So the transition between placeholders and the real pictures are pretty smooth.
How do you decide which features to add next? Do you go by gut, feedback, or a mix of both? Could you maybe let us know what features you’re planning to bring to RA in the future? A ‘sneak peek’?!
As RetroAssembly is in its early stages, user feedback is the most important direction for me. Almost all new features in the recent release come from users' voices: self-hosting, dark mode, full screen... Not to mention we still lack some essential features. Like batch deleting ROMs, updating passwords for self-hosted users, customizing metadata, etc. These are some basic features rather than some exciting ones. At this period, I think feedback is more important.
In the long term, when these basic features and commonly requested features get done, I'd like to think up more innovative stuff with my own instinct.
As a open-source project maintainer, I would like to make things related to RetroAssembly as transparent as possible. There's a board on GitHub listing what we've going to do next for people who are interested in where we would go.
Community & Future Plans:
You’ve got GitHub repo with over 200 stars already, how active is the community and how much do contributions steer the roadmap for what comes next?
As of writing, GitHub stars have reached 280 and Docker pulls have reached 4.4k.
Our Discord server is still relatively small. Truth be told, comparing to writing code, I'm not particularly adept at managing a community and maintaining its vitality. However, I did receive some encouraging feedback and appealing ideas from these members. I'm pleased with all these. At least in current stage, community's feedback plays the most important role on guiding where this project would go.
What feedback or feature requests have been most surprising to you?
I've seen quite a few users asking for support for RetroAchievements. Though I'm not familiar with it, I have heard of it. It's a bit like PlayStation trophies but for retro games. What surprised me most is that so many people are using RetroAchievements to track their progress in retro gaming. Then I started to look at what kind of achievements it contains for some of my favorite titles. It opened a new door for me. I think it provides new perspectives to re-examine the games I thought I already knew well. It reminds me of a game called NES Remix on the Wii U. Maybe I can also try to use it to track my progress in the future and add support for it in RetroAssembly.
Another one is someone asked for allowing multiple users to log in so he can build a library for his kids. That's a quite interesting use case. I didn't expect that children might also be interested in retro games too. I also have a baby born last year, and he's still too young to play video games. But maybe he'll also need a dedicated gaming library in the future too? I'm not sure whether he'll be into this area, but if so, this feature will also be what he's gonna need!
What platforms or console emulators are next on your priority list to support?
We currently don't support uploading BIOS files, so platforms that require a BIOS (like some Atari consoles and Nintendo FDS, etc) are not supported for now. I'm going to work on these soon. I'm pretty sure they can be easily supported once users can upload their own BIOS files since I've tested them with some simple demos.
What’s your vision for RetroAssembly a year from now: feature‑wise or community‑wise?
I think the two aspects in the question are not in conflict, but even mutually reinforcing. Some great features come from the community, and these features will attract more people to our community too.
As I built this project mainly for my own use cases initially, most of the features I personally care about are almost finished. But as our community grows, there must be more commonly requested features I didn't think of. What I'm going to do is distinguish them from the overwhelming user voices. I would be glad to see what other retro gamers care about and I may also learn from these ideas to improve RetroAssembly's user experience and my own gaming experience.
So it's not that clear what RetroAssembly would be like 1 year later, but definitely it's going to be better.
If anyone wants to help your project: financial help, translations, dev work, joining your communities...where can people find out how to help?
I haven't set up a way for financial help yet. As I mentioned, RetroAssembly was initially built for my own use, though I've seen some users get excited about it. But I know financial support is critical for a project if one wants to make it sustainable, though donating is unlikely to make a project maintainer rich overnight. Maybe I'm going to set up a Patreon account when I think RetroAssembly is stable enough.
I did spend some time simplifying the process of setting up a development environment for RetroAssembly: after downloading the source code, with only 3 lines of commands you will be able to see what's actually released for real users. There's also a document about how to contribute on our GitHub. The Discord server is another place where one can talk with me and ask for help about how to contribute.
For translations, I still don't have the related infrastructure set up in the code base. I've noticed our users come from different continents, but until now no one has asked for translations. If someone asked for it and were willing to help, I would also be glad to get started though. I also believe that with help from our community and AI tools, it won't be too difficult to get internationalization done.
Conclusion: GitHub and Discord are the places where people can get involved with the community.
Any last words you’d like to share with everyone?
- For the interviewerThanks for your carefully prepared questions! I can feel your carefulness and professionalism through them. They'll create a great chance for people to know what's happening behind RetroAssembly.
- For those who are using RetroAssemblyThanks for your appreciation of this project! Thanks for sharing your feedback and ideas as well. I believe we'll make RetroAssembly better together in the following days.
- For the restTry RetroAssembly if you are interested in retro gaming! It's super easy to set up with only a few clicks, but incredibly convenient if you are playing on multiple devices.
Thank you for reading — I hope RetroAssembly helps you rediscover and enjoy retro games.
And that's that!
RetroAssembly isn’t just another emulator frontend or ROM manager: it’s a reminder of how simple and joyful retro gaming can be when the barriers are dropped. At its heart, it’s about making those classic titles easy to reach, easy to play, and easy to carry with you no matter where you are. The tech under the hood may be modern, but the philosophy is pure 8-bit: pick a game, press start, and you’re off.
Talking with Arian makes it clear that RetroAssembly is still just getting started. Features are evolving, the growing community is shaping its direction, and there’s plenty of room for it to grow into something even bigger. But what’s refreshing is how personal it all feels. RetroAssembly wasn’t born out of a corporate roadmap, instead it came from one developer scratching their own itch, wanting a smoother way to enjoy old games. That spirit of “built by a fan, for fans” is what makes it resonate so strongly.
So whether you’re loading up NES classics, experimenting with oddities like the Virtual Boy, or simply looking for a hassle-free way to sync saves across devices, RetroAssembly offers a glimpse at how retro gaming can feel both nostalgic and surprisingly modern at the same time.
And after spending some time with Arian, hearing about his inspirations, challenges, and hopes for the project, one thing is clear: RetroAssembly isn’t just keeping retro games alive, it’s making them easier than ever to enjoy!
Of course, one big, special thanks for Arian for chatting to me about all of this, I'm so grateful he took the time and wanted to share all of this with me.
If you're looking for more information in one compiled place: