Michael Stavridis

Live · Chrome, Edge, Firefox

FreeCAD · Web

FreeCAD, the full parametric CAD suite, cross-compiled to WebAssembly and running in the browser.

Screenshot

• 25+ CAD workbenches in the browser
• 5 native runtimes fused into one binary
• Python 3.13 embedded, numpy included
• Qt 6.9 the real desktop GUI

FreeCAD 1.1.3, the full parametric CAD suite, cross-compiled to 64-bit WebAssembly and running the real Qt desktop in a browser tab, with about twenty-five workbenches, the OpenCASCADE geometry kernel, and an embedded Python. The hard part is the tower: OpenCASCADE, a complete CPython, the Coin3D 3D engine, the Qt GUI, and the PySide bindings that tie them together, native runtimes that normally live in separate libraries and processes, all cross-compiled and fused into a single WebAssembly binary.

• The real CAD suite, not a viewer The actual FreeCAD desktop, the same C++, running in a browser tab: parametric modeling, sketching, the full menu of roughly twenty-five workbenches, and a live 3D view.
• A tower of native runtimes, fused FreeCAD stands on a stack of big native pieces: the OpenCASCADE geometry kernel, an embedded Python, the Coin3D 3D engine, the Qt interface, and the PySide bindings that tie them together. Each was compiled to WebAssembly and linked into one program, which is a large part of the challenge.
• Python that actually runs A complete Python 3.13 is embedded and works, right down to running numpy in the browser, so FreeCAD’s scripting console and its Python-driven tools function as they do on the desktop.
• Two canvases, hand-composited The browser would not let the 3D engine draw onto the page through Qt, so its rendered pixels are read back and painted onto a second canvas layered over the interface, a compositor built from scratch.
• FEM that solves in the tab The CalculiX finite-element solver, a Fortran program, is compiled to WebAssembly through a custom Fortran-to-C pipeline, so meshing and solving both run locally. Results are checked against closed-form answers, not just run to completion.
• Your work stays with you Documents and settings are saved into the browser and restored on the next visit, and nothing is uploaded to a server. Sessions can be shared by link, and an MCP endpoint lets AI tools drive the app.

• C++
• Python 3.13
• Emscripten 3.1.70
• OpenCASCADE 7.8
• Qt 6.9
• Coin3D / pivy
• PySide6
• WebGL2
• pthreads
• NumPy
• IndexedDB
• CalculiX
• wasm64

Playable · Chrome · v1.0

OpenMW · Web

A full 3D game engine, the open-source Morrowind engine, cross-compiled to WebAssembly and playable in the browser.

Screenshot

• 60 FPS 0.61 ms/frame, in-browser
• 1.5 GB growable WASM heap
• 20+ native deps cross-compiled
• 0.52.0 OpenMW, core gameplay intact

The real OpenMW C++ engine, the open-source reimplementation of The Elder Scrolls III: Morrowind, cross-compiled to WebAssembly with Emscripten and run multithreaded on WebGL2. Built on OpenMW 0.52.0, it renders the actual game at a smooth 60 FPS. Not a browser reimplementation and not a streaming service: the engine executes locally, reads game data straight from your disk, and keeps your saves in the browser. Porting it meant re-satisfying every assumption a native game engine makes about threads, a GPU, a filesystem, and codecs, on the web platform.

• The whole engine, not a rewrite The real desktop OpenMW, the same C++, running in a browser tab. It boots the actual 3D world, with combat, magic, saving, and AI all intact.
• Game files that stream from your disk A native engine expects to read gigabytes of game data instantly, the way a desktop app does; browsers do not allow that. A custom streaming filesystem feeds it in on demand, and your own copy of the game stays on your disk and is never uploaded.
• Tuned to boot in a browser Starting an engine this large in a browser took careful low-level tuning of memory, threads, graphics, and a browser-friendly frame loop, each dialed in by hand.
• The renderer, rebuilt for the browser Browser graphics speak a stricter, more modern dialect, so the 3D renderer was patched across fifteen files. One fix alone un-blanked every reflection and preview that had been rendering black.
• Bugs that only exist in the browser Shadows that swam, an intro video that froze, audio that deadlocked: a long tail of problems that worked fine on the desktop and only broke in the browser, each tracked down and fixed.
• Made to link at all The engine expected a Linux desktop windowing system that simply is not there in a browser. Filling in about fifty empty placeholder functions was the only way to get it to even build.

• C++
• Emscripten 6.0.1
• OpenSceneGraph 3.6.5
• WebGL2 / GLES3
• SharedArrayBuffer
• pthreads
• SDL2
• Bullet
• MyGUI
• RecastNavigation
• FFmpeg
• Lua 5.4

Playable · Chrome

JA2 · Web

Jagged Alliance 2, the Stracciatella engine, cross-compiled to WebAssembly, Rust core and all.

Screenshot

• 2 languages in one WASM binary (Rust + C++)
• 8 MB stack, up from a 64 KB default
• 4 GB max heap, 8-thread pool
• 0.22.1 Stracciatella, full engine

The full Jagged Alliance 2 Stracciatella engine, its C++ core and its Rust library both, cross-compiled into a single WebAssembly binary and run in the browser off the original game data. It boots to the main menu and into live turn-based tactical combat, with saves kept in the browser. The hard part is not one language but two: a Rust static library and a C++ engine linked into one module over a C ABI, sharing a single allocator and one thread pool.

• Two languages, one program This engine is written in both C++ and Rust. To run in the browser, both had to be compiled and fused into a single WebAssembly program that shares one block of memory and one set of threads, which is genuinely hard to pull off.
• Rebuilding Rust for the browser Rust’s standard library does not ship in a form that can share memory across threads in the browser, so I rebuilt it from source with the right low-level features enabled, and worked around a compiler bug that was corrupting file paths.
• An 8 MB stack, learned the hard way Loading a battle map quietly overran the browser’s tiny default memory and corrupted the program, showing up as random crashes far from the real cause. The fix was giving it a desktop-sized stack.
• Teaching an old game to share the browser The game wanted to own the whole loop and freeze on animations, which locks up a browser tab. I turned its main loop into something the browser drives frame by frame and removed the parts that would hang.
• Drawing and sound on the web The 2D battlefield renders crisp and full-screen while the menus stay pixel-perfect, and the audio was corrected so it does not play sped-up and pitch-shifted through the browser’s sound system.
• Bring your own game data The original game files stay on your machine; nothing copyrighted ships in the build. Your saves live in the browser and survive a reload.

• C++17
• Rust (nightly)
• Emscripten 6.0.1
• SDL2
• WebAssembly
• pthreads
• SharedArrayBuffer
• Lua 5.1
• cbindgen
• IndexedDB
• miniaudio

Live

Nostalgia Lab

A free, non-profit retro console preservation platform: a quarter-million-ROM archive you can play with friends.

Screenshot

• 238K ROMs auto-matched
• 104K game releases
• 887K media assets
• 20+ console systems

A retro-gaming archive and player I designed, built, and operate end to end. It auto-identifies a quarter-million ROM dumps against a hash database and links them to 104,000 catalogued releases, plays 20+ classic consoles in the browser, syncs encrypted cloud saves, and lets you play multiplayer with friends over WebRTC. Seven services on GCP Cloud Run, fronted by Cloudflare.

• Industrial ROM cataloging Auto-identifies ROMs against 374,000 Redump/No-Intro DAT hash signatures (CRC32/MD5/SHA1), then links them to releases through a four-tier resolver: exact hash, then CRC, then filename, then fuzzy trigram match at 92% similarity. An autonomous daemon reconciles orphans continuously.
• Play in the browser 20+ consoles run client-side on libretro cores compiled to WebAssembly. You bring your own ROMs (they never leave your device), so it stays legal by design.
• Friends & multiplayer Host-authoritative WebRTC netplay: the host runs the emulator and streams video while guests send controller input over a data channel. Live presence, controller-entry friend codes, and Redis pub/sub room state across auto-scaled instances.
• Encrypted cloud saves Save states and SRAM sync to Google Drive or OneDrive, encrypted with per-user AES-256-GCM keys escrowed under a KEK in Secret Manager. Your progress is stored in the cloud; your games stay yours.
• Metadata & media at scale 887,000 media assets (box art, screenshots, marquees) transcoded to WebP/WebM and served from object storage through a Cloudflare CDN. An LLM-assisted enrichment pipeline fills genre, descriptions, and semantic-search embeddings.
• Production-grade platform Single sign-on across seven services with signed JWTs and an instant Redis denylist; Cloudflare-worker origin gating that fails closed; reproducible infrastructure across dev, stage, and prod, shipped through GitHub Actions with Workload Identity Federation and no long-lived keys.

• SvelteKit
• Vue 3
• Express
• GraphQL Yoga
• PostgreSQL
• pgvector
• Redis
• WebRTC
• WebAssembly
• GCP Cloud Run
• Cloudflare Workers