When a 2004 AAA game runs in a tab, what's left that must be native?

What happened

A developer operating as `slqnt` posted a working browser port of Half-Life 2 — the full 2004 Source engine title, not a tech demo or a Flash-era cutdown — at hl2.slqnt.dev. The Hacker News thread cleared 529 points within hours. You load the page, wait for assets, click play, and you are inside Black Mesa East. No installer, no Steam, no plugin prompt.

The build pipeline is Emscripten compiling the open-sourced Source engine reference to WebAssembly, paired with WebGL2 for rendering and SharedArrayBuffer-backed threads for the audio mixer and physics tick. The asset payload — roughly two gigabytes of BSP maps, VTF textures, and MDL models — is fetched on demand and cached in the Origin Private File System so a second visit boots in seconds rather than minutes. Reported performance lands around 75–85% of native on a modern laptop, which is the gap you'd expect from a JIT-compiled WASM target hitting a non-zero-copy GL bridge.

The interesting thing is not that someone shipped HL2 in a browser. It is that the technical preconditions which made it impossible in 2020 are now baseline. WebAssembly threads exited origin-trial in mid-2021. The Cross-Origin-Opener-Policy / Cross-Origin-Embedder-Policy isolation dance that re-enabled `SharedArrayBuffer` after Spectre is now boilerplate in any serious WASM project. WebGL2 compute paths, BigInt64 in WASM, the Memory64 proposal, and OPFS for multi-gigabyte client-side storage all landed in the last 36 months. The slqnt build is not a stunt — it is what falls out of the platform when you stop assuming the browser is a document viewer.

Why it matters

The load-bearing assumption in most product architectures is that there is a clean line between *web app* and *native app*, and that line is drawn by what the runtime can actually do. That line has moved, and the people drawing org charts and platform strategies have mostly not noticed. Figma swallowed Sketch by crossing it. Photopea swallowed casual Photoshop usage by crossing it. Excalidraw, tldraw, the in-browser VS Code at vscode.dev, the WebContainers that power StackBlitz — each of these existed because some team looked at what was assumed-native and rebuilt it without the install step.

The HL2 demo is interesting precisely because games were supposed to be the holdout. Games are the canonical excuse for native: low-latency input, deterministic frame pacing, GPU access, hundreds of megabytes of textures, audio mixing on a real thread. The browser, the argument went, would always be one generation behind on each axis, and the multiplicative gap would keep AAA work out. The slqnt port closes that argument for an entire game generation in a single afternoon's download. A 2004 AAA title is now a browser tab. By inference, so are 2008 titles, and probably 2012 titles with effort. Anything that fit in 2GB of RAM and ran on a single-digit-core CPU is in scope.

The community reaction in the HN thread is worth reading — the sober technical sub-thread, not the cheering. The recurring observation is that nothing about this required a breakthrough. No new browser API ships under the hood. No new optimization landed last quarter. It is plain Emscripten, plain WebGL2, plain SharedArrayBuffer, plain OPFS. The hard work was the porting glue, not the platform — which is exactly the signal you should care about, because porting glue is something a contractor does in three weeks, not a research lab does in three years.

There is, predictably, a legal dimension. Valve has historically tolerated Source engine ports and mods, but the assets here are copyrighted, and serving them from a public domain at scale is a different posture than a `.bsp` file traded among modders. Expect a DMCA or a quiet handshake within weeks. The technical proof, however, survives the takedown — and the technical proof is the only part that matters for your roadmap.

What this means for your stack

If you ship desktop software, run the audit. Walk down the list of things your product does that you assume require a native binary — file system access, hardware acceleration, multi-threaded compute, large persistent caches, low-latency audio, USB or MIDI, peer-to-peer networking. Each of those has a browser-native equivalent that has either shipped or is in origin trial. File System Access API is in every Chromium. WebGPU is shipping. WebTransport and WebRTC cover the networking side. WebUSB and WebMIDI exist for the niche cases. The honest answer to 'why is this native?' is increasingly 'because we wrote it that way in 2017,' not 'because the web can't do it.'

If you ship a web app, the inverse question gets sharper. The categories your roadmap labeled as out-of-scope — desktop publishing, CAD, video editing, IDE-class tooling, real-time collaborative simulation — are no longer out of scope on technical grounds. They are out of scope on *capital* grounds, because porting an existing native codebase to WASM is a real engineering project. But the moat is shrinking from 'impossible' to 'expensive,' and expensive-but-finite is the kind of moat well-funded competitors specialize in crossing.

The operational implication for engineering managers is more boring: stop letting 'we'd need to ship a native client' kill ideas in planning. The technical answer is now almost always 'no, you wouldn't, you'd ship a WASM bundle and a worker.' Whether the team has the skill set to execute that, and whether the assets fit, are real questions. Whether the browser can host it is not.

Looking ahead

The next 18 months are going to surface a steady drip of these proofs — a CAD package, a DAW, a small Postgres instance, a local-first LLM runtime — and each one will get an HN thread that says 'wait, the browser can do *that*?' The pattern is the same as the JavaScript-eats-the-world arc from 2014, except the substrate is WebAssembly and the ceiling is dramatically higher. The teams that ship into the next decade will be the ones that stopped treating the install step as a feature and started treating it as technical debt.