The Browser as Operating System: How We Got Here

There's a useful thought experiment: describe a browser to someone from 2005. Tell them it runs full-featured word processors, video editors, music production software, and code environments capable of compiling and running programs in the browser itself. Tell them it does this without installing anything, on hardware the user doesn't administer, with files synced across every device automatically.

They would assume you were describing an operating system. In every meaningful functional sense, they'd be right.

The Architecture That Made It Possible

The browser-as-OS story is really a story about three converging technologies: JavaScript engines, WebAssembly, and APIs that expose hardware capabilities to the web.

JavaScript engines are radically different than they were fifteen years ago. V8, SpiderMonkey, and JavaScriptCore are now sophisticated just-in-time compilers that can achieve performance within a small multiple of native code for compute-intensive workloads. The naive scripting language of the early web became a platform for running production software.

WebAssembly completed the picture. WASM is a binary instruction format that runs in the browser at near-native speeds. It's the compilation target for C, C++, Rust, Go, and a growing list of other languages. Software that was previously impossible to port to the web — games with physics engines, digital audio workstations, image processing pipelines — is now routine.

Platform APIs filled in the gaps. File System Access API lets web apps read and write to local directories with user permission. Web Serial lets browsers talk to hardware over serial connections. WebUSB, WebBluetooth, and WebHID extend this further. The browser is no longer sandboxed from the system in the way it once was.

The Practical Consequences

The implications are genuinely strange if you stop to think about them:

• Figma runs a complete vector graphics editor in the browser, with real-time collaboration, that outperforms many native apps in raw usability.
• VS Code's browser variant runs a full development environment including terminal emulation, language server protocols, and Git integration.
• Photopea replicates large swaths of Photoshop's feature set using pure web technologies.
• Google Earth streams and renders 3D planetary geometry in a browser tab.

None of these are simplified versions. They're production tools used by professionals.

The Platform War That Isn't

The old framing of "web apps vs. native apps" has largely dissolved. The real axis now is whether an application prioritizes offline capability and hardware integration (still advantages of native) or distribution, cross-device sync, and zero installation friction (advantages of web).

For the majority of business software and a growing share of creative tools, the web's advantages have won. For games, system utilities, and anything requiring consistent low-latency hardware access, native remains the right answer.

What's interesting is that the boundary keeps shifting. Capabilities that required native code five years ago run in browsers today. The trajectory has been one-directional for twenty years. There's little reason to expect it to reverse.