The Browser Is Eating the Operating System Again

Open Adobe's web version of Photoshop, drag in a large layered file, and start working. The liquify brush drags pixels in real time, adjustment layers composite, filters resolve without a visible stall. None of this touches a native install. The application is a C++ codebase compiled to WebAssembly, the canvas is painted by the GPU through the browser, and the whole thing runs inside the same tab you left an email draft open in. A decade ago this was the kind of demo that impressed a conference room and then quietly buckled the moment someone loaded a real project. It does not buckle now, and that change is worth taking seriously rather than treating as another round of browser triumphalism.

The stack that made it plausible

Two pieces of plumbing did the heavy lifting. WebAssembly gave the browser a compilation target that runs near-native speed, so existing C, C++ and Rust code could be ported instead of rewritten in JavaScript. That alone brought codecs, physics engines and image libraries into the tab. The second piece, WebGPU, matters more than its dull name suggests. Its predecessor, WebGL, was built around drawing triangles: excellent for rendering, awkward for anything else. WebGPU exposes compute shaders, which means the graphics card can be pointed at arbitrary parallel maths. That is precisely the shape of work a neural network needs, and it is the reason the browser stopped being merely a display surface and became a place computation actually happens.

Small models, running where you are

The clearest signal is that language and vision models now run in-tab with no server round trip. Projects like Transformers.js, ONNX Runtime Web and the MLC team's WebLLM load quantised models and execute them against WebGPU. The catch, and it is a real one, is size. You are not running a frontier model in a tab. You are running the small end: Whisper for speech-to-text, sentence-embedding models for local search, and compact instruct models in the low billions of parameters such as the smaller Gemma and Phi variants. Those are enough for transcription, semantic search over your own notes, classification, redaction and autocomplete, all without a single byte leaving the machine.

The appeal is not novelty. It is the removal of three costs at once. There is no inference bill, because the user's own hardware does the work. There is no network latency, because nothing is sent. And there is a genuine privacy story, because sensitive text or audio never reaches a third party. For a class of features that were previously impossible to ship without a backend and a data-handling policy, the browser now offers a route that is cheaper and, on the privacy axis, straightforwardly better.

What has actually moved back

Look past the demos and a pattern emerges of specific native jobs quietly relocating. Video call background blur and noise suppression, the sort Google Meet performs, lean on WebAssembly and GPU segmentation rather than a native client. Figma made professional design a browser default years ago on the strength of a WebAssembly rendering core. Full digital audio workstations, CAD tools, PDF editors and console-grade game ports now run in-tab. Add local transcription and embedding search to that list and the browser starts to cover a meaningful slice of what people used to open a dedicated application for. This is not everything. It is a growing, well-defined middle.

The limits worth naming honestly

Scepticism is earned here, because we have heard this song before. Netscape declared the browser would reduce Windows to a set of poorly debugged device drivers. ChromeOS bet the desktop on the web. Electron delivered the web to the desktop and a reputation for eating memory along with it. So the constraints deserve the same billing as the wins. WebAssembly's memory ceiling and the practicalities of a multi-hundred-megabyte model download over a home connection are real friction. GPU access is uneven: Safari shipped WebGPU later and more cautiously than Chrome, so a feature that flies in one browser may be absent in another. Sustained compute drains batteries and heats laptops. And the browser's sandbox, the very thing that makes running untrusted code safe, still denies the deep filesystem and hardware access that some native work genuinely requires.

None of that is fatal, but it does define the boundary. The browser is not eating the operating system whole. It is annexing the tasks where portability and safety outweigh raw access, and leaving the rest, for now, to native code. The honest claim is narrower and more durable than the slogan: a large and expanding category of serious computing no longer needs an install.

What that points towards is a shift in what the operating system is for. If the demanding work, editing, rendering, inference, can happen inside a sandboxed, cross-platform runtime that updates itself and asks permission before it touches anything, then the layer beneath it starts to look less like a platform you build for and more like a launcher you pass through. The interesting question is no longer whether the browser can do this. It plainly can. The question is which native applications still justify their own icon once the tab does the job, and that answer is going to keep shrinking.