The Browser Is Eating Software Again

The App You Downloaded Is Probably Worse

There is a version of this story where the desktop app wins. It has direct hardware access, no sandbox restrictions, offline capability baked in from day one, and decades of platform-specific polish. The browser, by contrast, was designed to display documents. It was never supposed to run your video editor.

And yet here we are. Figma replaced Sketch for most design teams without anyone really deciding to switch. VS Code — technically an Electron app, but built entirely on web technology — became the dominant code editor on the planet. Notion displaced dedicated note-taking apps that had years of head start. The browser did not storm the gates. It just kept showing up, and eventually people stopped locking the door.

What Actually Changed

The honest answer is: a lot of small things, compounding over a long time. WebAssembly arrived in 2017 and gave browsers a way to run near-native code without JavaScript's performance ceiling. The Web Audio API matured. WebGL became reliable enough for serious 3D work. IndexedDB, while still unpleasant to use directly, gave developers a real local storage layer. Service Workers made offline-first web apps possible rather than theoretical.

None of these were announced as turning points. There was no single release where browsers became capable of serious software. It happened the way most infrastructure shifts happen: gradually, then suddenly, and mostly noticed in retrospect.

The real unlock was not any single API. It was the combination of better tooling, faster JavaScript engines, and the fact that developers stopped apologizing for building on the web. When the people writing the software stopped treating the browser as a compromise, the software stopped feeling like one.

The Electron Problem Nobody Wants to Solve

Electron deserves its own paragraph because it is both the best and worst thing that happened to web-based desktop software. It let web developers ship native-feeling apps without learning Swift or C++. It also shipped a full copy of Chromium with every application, which is why opening Slack on a 2019 MacBook felt like starting a small server farm.

The criticism is fair. But the criticism also missed the point. Electron was not a technical solution — it was a distribution solution. It let teams with web skills ship to the desktop without splitting their engineering effort. The memory overhead was a tax, and most companies decided the tax was worth paying.

What has changed since is that the tax is getting smaller. Tauri, which uses the system's native WebView instead of bundling Chromium, produces apps that are a fraction of the size. The tradeoff is less rendering consistency across platforms, but for most applications that is an acceptable deal. The tooling around it is still maturing, but the direction is clear: web-based desktop apps are going to get lighter, not heavier.

Where Native Still Wins, and Why It Matters

This is not a eulogy for native software. There are categories where the browser genuinely cannot compete, and pretending otherwise would be dishonest.

Professional video editing is one. Final Cut Pro and DaVinci Resolve do things with GPU memory and real-time rendering pipelines that no browser-based tool can match today. The same is true for high-end audio production, where latency requirements are measured in single-digit milliseconds and the Web Audio API's scheduling model introduces overhead that professional engineers will not accept.

Games are another obvious case, though WebGL and WebGPU have pushed the ceiling higher than most people expect. The gap is real but narrowing, and for casual and mid-tier games it has already closed.

The more interesting category is operating system integration. Apps that need to sit in your menu bar, respond to system events, manage files across the filesystem, or interact with hardware peripherals still have a meaningful advantage as native software. The browser's security model — which is genuinely good and worth preserving — is also a ceiling on what web apps can do without explicit user permission at every step.

The Business Logic Nobody Talks About

Here is the part of this story that gets less attention than the technical details: the browser won, in large part, because it made software easier to sell.

A web app does not need to pass App Store review. It does not pay a 30 percent platform tax. It can update itself silently without asking the user to approve anything. It can run A/B tests on the interface without shipping a new binary. It can collect usage data — with appropriate consent, theoretically — in ways that native apps make harder. From a product and business perspective, the browser is not a compromise. It is a competitive advantage.

This is why enterprise software moved to the browser so completely and so fast. It was not because IT departments fell in love with web technology. It was because web-based software is dramatically easier to deploy, update, and manage at scale. No version fragmentation. No installation failures. No compatibility matrix across operating system versions. You push a change and everyone gets it.

What Comes Next, Probably

Prediction, clearly labeled as such: the next five years will see the browser's capabilities expand into the remaining gaps, not through dramatic announcements but through the same incremental accumulation that got us here. WebGPU is already shipping in major browsers and will matter more as it matures. The File System Access API will get less awkward. Progressive Web Apps will get better system integration on desktop platforms, though Apple will continue to drag its feet on this for reasons that are not entirely technical.

The more interesting question is what happens to the platforms themselves. If the browser becomes capable enough for nearly everything, the leverage that Apple and Google hold over software distribution weakens. That is not a small thing. Both companies have built significant revenue streams on the assumption that developers need their stores. The browser is, among other things, a slow-moving argument against that assumption.

Native apps will not disappear. The professional tools that need raw hardware access will stay native, and they will be very good at what they do. But the center of gravity in software development has already shifted. Most new applications are being built for the browser first, and the question of whether to also ship a native version is increasingly answered with: probably not.

The browser was supposed to display documents. It ended up running the world's software instead. That is either a triumph of open standards or a cautionary tale about underestimating what a good enough platform can become. Possibly both.