When a game runs entirely inside a browser tab, with no install step and no app store listing, something specific is happening under the hood that's worth understanding, especially if you've ever wondered why one 3D game asks you to wait through a multi-hundred-megabyte download while another is playable within a couple of seconds of opening a link.
The technology making this possible is called WebGL, short for Web Graphics Library. Mozilla's own developer documentation describes it plainly: it's a JavaScript API that lets a browser render interactive 2D and 3D graphics using a device's graphics hardware directly, without needing any plugin or separate software installed. It's been built into essentially every modern browser for years, which is part of why a WebGL-based game can simply run the moment a page loads, the same way an image or a block of text does.
Writing raw WebGL by hand is notoriously verbose — genuinely useful 3D scenes can take hundreds of lines of fairly low-level code before anything appears on screen. This is where a library like Three.js comes in. As MDN's own game development documentation puts it, a library like this "gives you a huge advantage: instead of writing hundreds of lines of WebGL code to build anything interesting you can use built-in helper functions to do it a lot faster." Three.js doesn't replace WebGL, it sits on top of it, handling the repetitive, error-prone parts so a developer can focus on describing a scene — a shape, a light, a camera — rather than the underlying graphics pipeline.
It's worth being honest about what browser games give up in exchange for this convenience, rather than pretending there's no trade-off at all. Industry comparisons of the two approaches consistently point to a similar pattern: browser-based engines like Three.js tend to produce dramatically smaller downloads — often in the low single-digit megabytes, compared to twenty to fifty megabytes or more for an equivalent WebGL export from a general-purpose engine like Unity — and they start up faster because there's no large runtime to initialize first. What they trade away is some of the more advanced tooling: a visual scene editor, a mature built-in physics engine, and the kind of large asset marketplace that comes with an established general-purpose engine.
For a small, focused game built around one mechanic, that trade generally favors the browser-first approach. The things a general engine is good at — managing sprawling asset libraries, complex physics interactions, large open worlds — aren't what a tightly scoped game actually needs, while the things a lightweight browser engine is good at — instant load, no install friction, one URL that works on a phone, a laptop, or a tablet identically — are precisely the qualities that matter most for something meant to be picked up and played in a spare thirty seconds.
The deeper reason this distinction matters isn't really about file sizes at all — it's about what kind of moment a game is built for. An app-store game generally assumes a player willing to commit to a download, an account, maybe a review of permissions, before ever seeing a single frame of gameplay. A browser game assumes the opposite: someone with ten idle seconds and a link. Those are different products built for different attention spans, and a game's underlying technology tends to follow from which one it's actually trying to be.