Dev.to WebDev 🛠 Dev Mon, 12 Oct 2026 17:11:36 +0000 👁 0 📖 12 min read

The Browser Is No Longer a Browser

The Browser Is No Longer a Browser By Rafael Calderon Robles GTA V in a tab On October 6, 2026 a website called playgta5.com appeared. You opened the URL in Chrome, waited for about 700 MB to download an

The Browser Is No Longer a Browser

By Rafael Calderon Robles

GTA V in a tab

On October 6, 2026 a website called playgta5.com appeared. You opened the URL in Chrome, waited for about 700 MB to download and, suddenly, you were driving through Los Santos. No installer, no launcher, no cloud streaming: the game was running on your own computer, inside a tab.

In cloud gaming your machine only receives video. In the GTA V port, the code and the assets arrived in the browser and ran on your own hardware.

It lasted a few hours. Take-Two took it down almost immediately and, according to the analysis several curious people did afterwards, everything points to it being built on top of Rockstar's source code, leaked in 2022. So no, it is not an example to follow.

But the video went around the internet for a reason that goes beyond the game. If a AAA title with 20 GB of assets can boot in a tab, the question stops being "what can the web do?" and becomes "what can't it do anymore?". The browser is no longer a browser. It is something else, and that is what this article is about.

From documents to programs

The web was born to link documents. Then it learned to be interactive with JavaScript, and after that it became an application platform with Gmail, Google Maps and Figma. What is happening now is the next jump: the browser is absorbing, one by one, the capabilities that used to be exclusive to an operating system.

CPU at near-native speed, modern GPU access, real threads, a file system, hardware video, low-latency networking and even local AI models. None of these pieces is entirely new. What is new is that in 2025 and 2026 they finished landing in every browser at once:

Each row is a capability that used to require a native application and that today has its standard equivalent on the web.

WebGPU is now supported in Chrome, Edge, Firefox and Safari. Safari 26, in September 2025, closed the last big gap, including iOS.
WebAssembly 3.0 is a standard, with 64-bit memory, a native garbage collector, exceptions and tail calls.
Chrome's Prompt API has been stable since Chrome 148 (May 2026): a language model that ships with the browser.

When all the pieces are everywhere, developers can stop asking "will this work?" and start building. Let's walk through those pieces one by one, along with what people are already doing with them.

WebAssembly: the CPU

WebAssembly (Wasm) is a binary format the browser executes at close to native speed. It lets you compile C, C++, Rust, Go, Zig and, since Wasm 3.0, garbage-collected languages like Kotlin, Dart and Java. It is the piece that made GTA V possible: the game engine, in C++, was compiled into a single 63 MB file.

The Wasm module does the heavy lifting; JavaScript is still the one that talks to the page. Each crossing between the two has a small but real cost.

What Wasm 3.0 brings:

Memory64: breaks the 4 GB memory limit. In the browser the ceiling sits at 16 GB.
WasmGC: the browser manages memory for languages like Kotlin and Dart, so they no longer have to ship their own collector inside the binary.
Native exceptions and tail calls: fewer workarounds and smaller binaries when porting existing code.

Where it is already in use:

Photoshop on the web and Figma, which run their C++ core compiled to Wasm.
Ruffle, a Flash emulator written in Rust that keeps thousands of old games and animations alive.
Godot, Unity and Bevy export complete games to the browser.
Compose Multiplatform and Flutter use WasmGC to bring Kotlin and Dart interfaces to the web.
Extism and similar projects use Wasm as a safe plugin system, inside and outside the browser.

The tools to get started are well known: Emscripten for C and C++, wasm-bindgen and wasm-pack for Rust, and the native support in Go, Kotlin/Wasm and Dart.

That said, Wasm is not magic. Every time JavaScript and WebAssembly talk to each other there is a boundary to cross: Wasm only understands numbers and linear memory, while JS lives on UTF-16 strings, objects and promises. Each crossing costs on the order of 100 ns, which is nothing in a single call and everything in a loop of 10,000 iterations per frame. Tools like wasm-bindgen hide that boundary the same way an ORM hides SQL, which is exactly why it pays to know what is underneath: I covered it in detail in 16 patterns for crossing the WebAssembly boundary, from zero-copy memory views to command buffers, which work exactly as they do on a GPU.

WebGPU: the real GPU

WebGL had been giving access to the GPU since 2011, but it was based on OpenGL ES, an API from two decades ago. WebGPU is its successor, designed on top of the modern APIs (Vulkan, Metal and Direct3D 12). In GTA V, a translation layer mapped the game's Direct3D 11 calls to WebGPU, and around 6,600 shaders were converted to WGSL, its shading language.

You write against a single API; each browser translates it to your system's native graphics API.

The big news is not just graphics: it is compute shaders. They let you use the GPU for general-purpose computation, just like CUDA, but from a web page. That opens the door to physics, simulations, image processing and, above all, artificial intelligence.

Libraries and projects worth knowing:

Three.js and Babylon.js, the two most used 3D engines on the web, already have a WebGPU renderer.
PlayCanvas, a web game engine with a collaborative editor in the browser.
wgpu (Rust) and Dawn (C++), the WebGPU implementations behind Firefox and Chrome, which are also used as a native graphics API outside the browser.
Gaussian splatting, the fashionable technique for photorealistic 3D scenes captured with a phone, with web viewers like Luma AI's or the gsplat.js library.
ONNX Runtime Web and Transformers.js, which use WebGPU to run neural networks (more on this below).

WebGL is not going away any time soon, but new projects are already starting to pick WebGPU by default, with WebGL as the fallback.

Threads, disk and databases on the client

A serious program needs more than CPU and GPU: it needs to run several things at once and to store data. The browser already has that too.

Real threads. Web Workers have been around for years, but combined with SharedArrayBuffer they allow shared memory and genuine threads, like C's pthreads. The GTA V port spread the engine's work across several workers. There is one detail that surprises a lot of people: to enable it, the server has to send the COOP and COEP headers (cross-origin isolation), a measure introduced after the Spectre vulnerabilities.

A file system. OPFS (Origin Private File System) gives every site a private, fast disk, with synchronous access from workers. It is the piece that was missing to put real databases in the browser. GTA V, for its part, read its 20 GB of assets in chunks with HTTP range requests and stored saves in IndexedDB.

And with that, complete databases that run on the client have arrived:

SQLite Wasm, the official SQLite build for the browser, with persistence in OPFS.
PGlite, PostgreSQL compiled to WebAssembly, from ElectricSQL.
DuckDB-Wasm, columnar analytics over Parquet or CSV files with no server.
Local-first tooling such as Yjs and Automerge (CRDTs for real-time collaboration), ElectricSQL, PowerSync, Turso and Zero, which sync a local database with the server.

The result is a new way to build applications: data lives on your device first, the app works offline, and the server becomes a synchronization point.

I have tried this first-hand. In From WAL to WASM I set up SQLite in WebAssembly on top of OPFS inside a Web Worker, synced with PostgreSQL through its replication log (the WAL) using PowerSync. The technical key is FileSystemSyncAccessHandle: a synchronous file access that matches how SQLite expects to talk to a disk. Writing locally and seeing the UI update goes from a network round trip to microseconds.

The interface never waits for the network: it reads and writes to the local database, and synchronization happens in the background.

And for real-time collaboration, CRDTs compiled to Wasm are the other half. In how I built a CRDT engine for a collaborative whiteboard in Rust I explained vectis-crdt: the same Rust code runs on the server and in the browser, takes about 85 KB compressed, and hands the visible strokes to the canvas through a single buffer in Wasm memory, with no copies.

Video, audio and networking

A curious detail: the GTA V port did not play the game's videos, and online mode was disabled. Those two gaps are precisely the territory of other APIs that are maturing.

In each flow, the API in the middle is the one that used to force you out of the browser or into loading heavy libraries.

WebCodecs gives direct access to the hardware's video and audio encoders and decoders. Before, editing video in the browser meant uploading it to a server or dragging in an FFmpeg build compiled to Wasm, slow and heavy. Now:

Mediabunny lets you read, write and convert MP4 and WebM directly with WebCodecs.
Remotion generates videos out of React components.
ffmpeg.wasm is still useful when you need one specific format or filter.
Editors like CapCut and Clipchamp already run, to a large extent, inside the browser.

AudioWorklet runs audio code on its own real-time thread, with the latency music actually needs. GTA V used it for its sound engine. In the music world it powers Tone.js, the audio processing language Faust, and full DAWs in the browser like BandLab.

The usual pattern for feeding that audio thread from Wasm is a ring buffer in shared memory: the Wasm code writes samples and the AudioWorklet consumes them, with no locks and no copies. It is one of the patterns I collected in the Wasm boundary catalogue, and it is the same principle I used for zero-copy IPC with Rust and lock-free ring buffers outside the browser.

WebTransport and WebRTC cover low-latency networking: data without HTTP's overhead, with connections between browsers or to servers over QUIC. That is what makes things like the web port of Halo: Combat Evolved with up to 128-player multiplayer possible, along with video calls, remote desktop and cloud gaming.

AI inside the browser

The viral video claimed GTA V had been ported "using AI", although nobody has been able to prove it. What is real is that AI is moving into the browser itself, and not through a cloud API: the models are downloaded and run on your GPU.

The model is downloaded once and cached; from then on, every inference happens on your machine without sending anything out.

The three most popular options right now:

WebLLM (MLC AI) runs language models with WebGPU and exposes an OpenAI-compatible API. Switching from a cloud service to a local model is almost a one-line change.
Transformers.js (Hugging Face) goes beyond chat: embeddings, speech recognition with Whisper, vision and classification, with WebGPU and a Wasm fallback.
Chrome's Prompt API uses a model that already ships with the browser, with no per-site download. Chrome also exposes narrower APIs to summarize, translate and rewrite text.

Underneath, ONNX Runtime Web and WebNN do the work, the latter a W3C standard so that websites can also use the NPU, the AI chip that already ships in new laptops.

The consequences are large. A website can transcribe audio, search your documents semantically or summarize text without your data leaving the device and with no server cost for whoever offers it. Privacy stops being a promise and becomes a property of the architecture.

Whole systems in a tab

When you put all these pieces together, things happen that looked impossible five years ago. We are no longer talking about web apps, but about complete environments that used to require installing something:

Pyodide and JupyterLite run scientific Python, with NumPy and pandas, with no server. Tools like marimo use it for notebooks shared with a link.
WebContainers (StackBlitz) boots Node.js inside the browser. It is what sits underneath online editors and AI app generators like bolt.new.
v86 and WebVM (CheerpX) emulate an x86 PC and boot Linux, or even old versions of Windows, in a tab.
Ruffle, DOSBox compiled to Wasm and js-dos bring decades-old games and programs back to life, and archives like the Internet Archive use them for digital preservation.
Excalidraw, tldraw and Figma show that professional tools can live entirely in the browser.

And then there is the wave of classic games brought to the web: Vice City, Diablo, Half-Life, Quake and the recent Halo. Some are ports that ask for your own game files; others, like GTA V, clearly cross the legal line. The technique is the same; what changes is where the code and the assets come from.

What still isn't possible

It is not all as pretty as the video suggested. GTA V in the browser was also a good demonstration of today's limits:

Memory. Memory64 lets you go past 4 GB, but the browser caps the ceiling at 16 GB, and Safari still doesn't support it. It is also slower than the 32-bit version. The GTA V port crashed on memory limits in long sessions.
Uneven compatibility. WebGPU is in every browser, but not on every platform: as of September 2026, Firefox only offers it on Windows and Apple Silicon Macs, and on Linux it depends heavily on the GPU.
Downloads and storage. 700 MB before you can start playing is still a lot, and the browser can evict the cache when it runs out of space. Plenty of GTA V users got stuck on the loading screen.
The sandbox. It is the browser's greatest virtue and also a limit. No kernel-level anti-cheat, no direct hardware access, no custom DRM.
The legal side. The technology makes it possible to port almost anything. The GTA V case, and those of Call of Duty and Fallout this same autumn, show that publishers are not going to sit and watch.

None of these limits is permanent, but they are worth keeping in mind before promising "the desktop app, but in the browser".

The question has changed

GTA V in a tab is not the future of video games. It was an experiment that lasted hours, built on code that did not belong to whoever published it. But it made one thing clear: the ceiling of what the web can do has moved much further than most developers think.

CPU, GPU, threads, disk, video, audio, networking and AI. Every piece of an operating system is already inside the browser, with the advantage that it ships with a link and runs inside a sandbox. And what is coming next — bindless WebGPU, WebNN, the evolution of WASI and the Component Model outside the browser — points in the same direction.

Outside the browser, that future is already here. WebAssembly's Component Model lets you compose modules written in different languages with typed interfaces (WIT) and capability-based security, and it is already moving production workloads with Wasmtime, Spin and wasmCloud. I explored it in Wasm microservices: from single binaries to composable components. It hasn't reached any browser yet, but when it does, much of the glue between JavaScript and Wasm that we write by hand today will stop being necessary.

For anyone building software, the question is no longer "can this be done on the web?". The question is "does it make sense to do it anywhere else?".

The browser is no longer a browser.

Sources

If you want to go deeper

Other articles of mine on the pieces that show up here:

📰 Read the original article on Dev.to WebDev

Originally published by Dev.to WebDev. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.

← News 🛠 Dev 🏠 Home