EmulatorJS: RetroArch's cores, running in a browser tab you host yourself

RetroArch's cores, in a browser tab

EmulatorJS is a web-based frontend for RetroArch, described in its own package metadata as a frontend for RetroArch in the web browser, providing self-hosted JavaScript emulation for various systems. The supported target is a wide variety of legacy consoles and arcade machines, with the complete list of supported cores maintained in the project's cores documentation rather than frozen into the README. The relationship matters for expectations, EmulatorJS is not a new emulator written from scratch, it is the familiar RetroArch core ecosystem wrapped for the browser, so the emulation quality and system coverage track the cores it packages. The license is GPL-3.0, the language is JavaScript, and the project runs a website at emulatorjs.org with separate pages for usage docs, a configurator, and a live demo.

Stable, Latest, Nightly, with honest warnings

The versioning guide defines three tracks and does not flatter two of them. Stable is the most current release, with both code and cores tested before release, updated when new versions land on GitHub, and it is the default on the demo. Latest contains the latest code but uses stable cores, updating whenever the main branch changes, and the guide's own emphasis is blunt, this version will often be more broken than nightly. Nightly contains the latest code and the latest cores, with cores updated daily, and is not recommended for production use as it is the main development branch. The inversion is the interesting part, mixing fresh code with stable cores produces a less predictable combination than the everything-fresh track, and the project says so in print rather than letting users discover it.

One CDN line, or your own copy

Integration starts with a public CDN at https://cdn.emulatorjs.org/, where any version is reachable by setting the data path and loader.js accordingly:

const EJS_pathToData = 'https://cdn.emulatorjs.org/<version>/data/';

with the version slot taking stable, latest, nightly and so on. Local development runs from the repository with three steps, npm i to install dependencies, npm run start to launch the server and minification, and then http://localhost:8080/ for the demo. The local server and the minifier are the same npm script, which hints at the deployment shape, what you serve is generated, minified output rather than raw sources, and the README's note says to minify script files before deploying to production to optimize load times and bandwidth, pointing at the dedicated minification docs in the minify directory.

A library, deliberately not a website

The README draws one boundary explicitly, EmulatorJS is built as a library and plugin, not a standalone website, therefore no Docker container. That parenthetical answers the most common self-hoster question before it is asked, the many Docker-based retro gaming stacks that appear in searches are third party projects wrapping this library, not the library itself, and the project keeps a third party integration list on its docs site for exactly that ecosystem. The configurator at emulatorjs.org/editor exists so integrators can build their configuration visually instead of hand writing the options object, and the live demo at demo.emulatorjs.org runs on the Stable track by default, giving a reference behavior to compare an embedded deployment against.

node-7z, nipplejs and socket.io in the manifest

The package manifest reads like a map of the runtime problems the project solves. node-7z handles 7z archives, the format compressed emulation data arrives in. nipplejs is the on-screen touch joystick library, the control problem for phones and tablets. socket.io appears in devDependencies, the realtime channel multiplayer and room features need. The build tooling is rollup with the terser plugin for bundling and minification, jsdoc generates API documentation from data/src, and eslint keeps the style. The runtime dependencies are four, the node-minify pair, http-server for serving, and node-7z, with @emulatorjs/cores as an optional dependency pinned to latest, the package that delivers the actual emulation cores as a separable, independently updated unit.

Bug reports must name their track

The issue reporting instructions encode the three-track reality, when reporting bugs, specify the version you are using, Stable, Latest or Nightly, and include as many details as possible including browser console logs. That request follows directly from the versioning guide, an error on Nightly may be same-day core churn while the same symptom on Stable is a real regression, and no maintainer can triage without knowing which world the report came from. The surrounding support structure is a Discord server for discussion and GitHub issues for tracking. The project describes itself as free and ad-free, with the caveat that the demo page may show occasional ads to help with hosting costs, and direct support runs through Patreon for anyone who wants development funded without the ads.

4.2.4 on npm, 4.3.0-pre in flight

The published package is @emulatorjs/emulatorjs at version 4.2.4, an ES module with sideEffects declared true, while the GitHub release line shows v4.2.2 in June 2025, v4.2.3 in July 2025 and v4.3.0-pre on 2026-05-17, a prerelease sitting open for months as main branch work continues, with the last push on 2026-09-20. Changes are recorded in CHANGES.md at the repository root, and contribution rules live in CONTRIBUTING.md beside a code of conduct. The repository itself is compact for what it does, a data directory holding the application and its source under data/src, index.html as the demo entry, build.js and update.js for generation and core refresh, and a serve.py for environments that prefer Python's server over the npm one.

Editorial conclusion

Use EmulatorJS when emulation belongs inside your own web application, a retro gaming section of a site, a self-hosted portal, or a custom frontend, since it is built as a library and plugin with a CDN and configurator for exactly that integration. Do not expect a turnkey server, there is no Docker container because there is no website to containerize, and the integration list is where the third party projects live. Before deploying, pick the Stable track unless you enjoy breakage, the project's own guide warns Latest is often more broken than Nightly, minify the scripts before serving production traffic, and name your track in any bug report since behavior differs across all three.

Frequently asked questions

Official sources

1. EmulatorJS/EmulatorJS on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases