When Did the Browser Become a Game Runtime?

At what point does the browser stop being a delivery mechanism and start being a runtime? Over the last few years, web technology has shifted in ways that make this question harder to dismiss. With modern rendering via WebGL and WebGPU, performance-critical logic handled through WebAssembly, and real-time communication now commonplace through WebSockets and WebRTC, the browser no longer feels constrained in the obvious ways it once was. It still isn’t a native engine, but the line between the two is no longer as clear as it used to be. What’s notable is that the remaining limitations are less about visuals and more about feel. Timing, latency, scheduling, and long-session responsiveness are often where browser-based games still reveal themselves. Tooling also plays a role; building and debugging real-time systems in a browser works, but it rarely feels as mature or intentional as native workflows. At the same time, the browser offers something native platforms don’t: immediate access, zero installation friction, and a distribution model that favors iteration and experimentation. For certain kinds of games, that tradeoff may be less of a compromise and more of an advantage. So perhaps the more interesting question isn’t whether the browser can replace native engines, but whether it’s becoming a viable starting point for games that value accessibility, rapid iteration, and reach over traditional platform boundaries.