Everything is a web app

There was a time when installing software meant running a setup wizard, watching a progress bar crawl, and maybe rebooting your machine. That era feels ancient now. Today, most of the applications we use daily, from chat tools to music players to even our operating system's own weather widget, are quietly just web pages wearing a native costume. This shift didn't happen overnight, and it wasn't accidental. It was driven by real economic and engineering incentives. But as the web swallowed everything, something started to feel off. Apps got slower. Memory usage ballooned. And a growing number of people started asking: did we lose something important along the way?

How everything became a web app

The story starts with a practical problem: building native apps is expensive. If you want to ship on Windows, macOS, iOS, and Android, you traditionally needed separate codebases, separate teams, and separate skill sets. That's a lot of overhead, especially for startups and smaller teams. The web offered an escape hatch. Write once in HTML, CSS, and JavaScript, and your app runs everywhere there's a browser. Frameworks like React Native and Flutter took this further, letting developers build mobile apps from a single codebase that could target multiple platforms. The promise was irresistible: one team, one language, every platform. Then came Electron, which let developers package web apps as desktop applications by bundling an entire Chromium browser inside the app. Suddenly, companies could ship desktop software using the same web technologies and the same developers who built their websites. Slack, Discord, VS Code, Figma, Notion, Spotify's desktop client, the list of Electron-based apps grew rapidly. The result was a world where most of the software on your computer is, under the hood, a web browser rendering a web page.

The hidden cost of convenience

For developers, this was a win. For users, the trade-offs started piling up. Every Electron app bundles its own copy of Chromium. That means each app carries the memory and CPU overhead of an entire browser instance. Open a few of these at once and you can easily burn through several gigabytes of RAM before you've done any real work. As one frustrated developer put it, "We've collectively forgotten what 'good' feels like" when it comes to application performance. Windows 11 became a lightning rod for this criticism. Microsoft increasingly built core system components, including the Start Menu, Widgets panel, and even the Notification Center's calendar, using WebView2, its Chromium-based web rendering framework. The Weather app, essentially a web page in a window, was found to consume over 700MB of RAM, nearly three times what Apple's native Weather app uses on macOS. Scrolling was laggy. The interface felt cluttered with ads. It didn't feel like part of the operating system; it felt like a browser tab that had wandered out of Chrome. Brendan Eich, the creator of JavaScript, weighed in on the trend, warning against "rushed web UX over native." His point wasn't that web apps are inherently bad, but that doing them well requires time and discipline that many companies aren't willing to invest. The incentive structures, shipping fast, reducing headcount, maintaining a single codebase, push teams toward the quick-and-dirty web approach rather than the careful native one.

The Reddit rant that resonated

A post on Reddit's r/sysadmin titled "everything is a web app and i want to die" captured the mood perfectly. The author described the absurdity of using a web-based terminal emulator: "We put a terminal... in a web page... to connect to a server... to avoid using an actual terminal. It's SSH with extra steps and input lag." The frustration isn't just about performance. It's about the feeling that something fundamental was traded away. Native apps integrate with the host operating system. They respect its conventions, its keyboard shortcuts, its accessibility features, its visual language. Web apps, by contrast, tend to feel like they exist in their own bubble, a browser tab that happens to have its own window. When every app looks and behaves like a website, the entire computing experience starts to feel homogeneous and slightly off. Fonts render differently. Scrolling physics don't match. Context menus are custom-built instead of using the system defaults. These are small things individually, but they compound into a general sense that your computer doesn't quite feel like your computer anymore.

The pendulum swings back

Something interesting has been happening in the last couple of years. There's a growing counter-movement, developers and companies pushing back toward native development. Part of this is driven by the maturation of cross-platform native tools. Flutter compiles to actual native code, giving apps consistent performance without the browser overhead. Tauri, a Rust-based alternative to Electron, uses the operating system's built-in web view instead of bundling Chromium, dramatically reducing app size and memory usage. Some teams, like the developers of the screen-sharing app Hopp, have gone further, moving their most demanding features from web views to pure native Rust implementations after hitting too many WebKit limitations. There's also a philosophical shift happening. Developers are rediscovering that native apps can offer experiences that web apps simply can't match: smoother animations, better battery life, tighter OS integration, and that hard-to-define quality of feeling "right" on the platform. PCMag captured this sentiment in a piece titled "Microsoft Is Finally Fixing Windows 11's Web App Problem," noting that Microsoft itself has started acknowledging the issue and working to replace some WebView2 components with more native implementations.

AI changes the equation

Here's where the story takes an unexpected turn. Before AI coding tools became mainstream, the economics of native development were brutal. Learning Swift for iOS, Kotlin for Android, and C++ or Rust for desktop meant maintaining expertise across multiple ecosystems. It was slow, expensive, and the talent pool was limited. AI has dramatically lowered the barrier. Tools like GitHub Copilot, Cursor, and various AI app builders can now generate platform-specific native code with reasonable quality. A developer who knows React can describe what they want in natural language and get a working Swift prototype. The "write once, run everywhere" promise of the web mattered most when the alternative was "hire three separate teams." When AI can help bridge the knowledge gap, the calculus changes. There's an irony here: AI coding tools are overwhelmingly better at generating web code, because that's what dominates their training data. As one Reddit user observed, "AI feels way better at web dev than mobile apps" because "native apps are way more complex due to relatively niche and fragmented languages." But this advantage is temporary. As AI models improve and native codebases grow in the training data, the gap will narrow. The result is a possible future where building native apps becomes nearly as fast and cheap as building web apps, without the performance and experience trade-offs.

What we actually want

The real insight isn't that web apps are bad or native apps are good. It's that we accepted a trade-off without fully understanding what we were giving up. We traded application quality for developer convenience. We traded performance for shipping speed. We traded platform integration for cross-platform reach. For some applications, that trade-off makes perfect sense. A project management tool or a documentation app doesn't need to squeeze every last frame out of the GPU. But for others, the weather app on your desktop, the music player, the chat client that runs in the background all day, the costs have been quietly adding up in wasted battery life, sluggish interfaces, and that nagging feeling that software used to be better. The pendulum is swinging, not all the way back to the old world of platform-specific silos, but toward a middle ground. A world where the default assumption isn't "make it a web app" but rather "what does this application actually need?" Sometimes the answer is the web. Sometimes it's native. And increasingly, new tools and frameworks are making it possible to choose native without paying the old price. The everything-is-a-web-app era isn't ending. But the assumption that it's always the right choice is finally being questioned. And for anyone who's ever watched their laptop fans spin up just to check the weather, that's a welcome change.

References