The Future of Apps is Converging

My predictions for the future of app distribution and development

The convergence of technology. Generated by Gemini. Unfinished.

The complexity we’ve created as developers is unsustainable — a state that has forced many of us to use AI for navigating this vast space. Meanwhile, the web has been lacking in creating an environment where apps can thrive. And, to the detriment of users and developers alike, this has enabled monopolies to seize power.

Since the mid-90s, creating a “write once, run anywhere” solution has been every developer’s wet dream. In this article, I will argue how advancements are making this dream possible, blurring the line between web, mobile, and desktop software. True convergence will require architecting from the bottom up. An effort that might finally come to fruition, thanks to the new generation of web standards.

This article assumes intermediate domain knowledge within programming.

The Complexity Crisis

The fragmentation across platforms, architectures, and operating systems has reached a breaking point. We, as developers, are spending more time navigating and managing the chaos than building actual solutions.

If it were up to the hardware vendors, you would learn Swift for Apple devices, Kotlin for Android, JavaScript for browsers, C# for Windows, and completely different frameworks for smart TVs, IoT devices, and embedded systems. Then there’s the multiple CPU Instruction Set Architectures (ISAs) you have to account for. Mobile devices typically use ARM, and desktops use x86. However, Apple introduces M-series chips, fragmenting the desktop ecosystem further, and Microsoft follows suit as always. TVs have their own quirks, and don’t even get me started on the maze of IoT and embedded.

The amount of complexity grows exponentially as you account for more platforms. This is a very relevant and real issue for developers. Here are actual situations that many teams face in the real world:

• Having multiple platforms as targets. Very often, you want your app to run in the browser and on mobile. YouTube is a great example of an app that has to run everywhere — mobile, web, consoles, TVs. Maybe you even would want YouTube on your smart fridge.
• Game developers have to target a wide range of devices, with different capabilities and multiple architectures, Nintendo Switch, Xbox/Windows X86, PlayStation, mobile ARM, MacOS x86 & ARM, Linux, SteamDeck (x86–64).
• Game and Graphics developers also have to take into consideration Graphics APIs. Even though the underlying hardware is the same, different operating systems provide different APIs, with various versions and extensions for each: OpenGL, OpenGL ES, Vulkan, DirectX, and Metal.

We’ve created a nightmare of fragmentation that only AI can realistically handle now — multiple platforms, different architectures, inconsistent APIs, and incompatible systems. AI has become the solution to a problem we fundamentally created ourselves. Instead of solving the root cause, unnecessary fragmentation, and complexity, we’re building AI assistants to navigate the chaos. But it doesn’t have to be this way. With a proper bottom-up approach, we can create a unified computing interface that works everywhere. But it’s not like we haven’t tried…

The Endless Quest For “Write Once”

Let’s be frank. The endless quest for a “Write Once, Run Anywhere” solution isn’t about improving usability for the end-user; it’s about making our own lives as developers easier. Most development happens in a capitalist framework where time is money. Every team faces the same fragmentation crisis. So, to save time, a lot of solutions that promise “write once” have emerged.

Let’s say your team wants to develop an app that runs on the web, desktops (Windows, macOS, Linux), and mobile devices (iOS, Android). What are your options today?

XKCD: Standards

You’re immediately faced with a dizzying array of choices, each promising a silver bullet but delivering a unique set of compromises:

• **Web (Browser, PWA) — Javascript:** JavaScript was meant for simple scripts, but now runs massive applications like Figma and Canva. Its success created a new problem: the DOM was a terrible foundation for complex UIs. This spawned a zoo of frameworks (React, Vue, Svelte) just to tame the beast we created. (Web Development Is Getting Too Complex, And It May Be Our Fault)
• **Tauri/Electron — Javascript:** To get web apps on the desktop, we decided to just ship an entire web browser with every app. It works, but it’s a resource hog. A simple text editor can end up consuming hundreds of megabytes of RAM, completely negating the “lightweight” promise of the web. Tauri improved this by using the device's native WebView.

The next solutions make use of the platforms' “Native Controls”. Native Controls are UI elements provided by the operating system. So the look and feel of your app might differ from platform to platform, but will stay consistent within their respective ecosystem. Overall, Native Controls outperform a WebView. Here are some options:

• **.NET MAUI/Blazor — C#:** .NET MAUI is Microsoft’s successor to Xamarin.Forms. It compiles C# & XAML to native controls, and supports optional Blazor Hybrid mode (run Razor-based web components inside a WebView).
• React Native — Javascript: Turns react components into native views through a JavaScript runtime and (until recently) the bridge. The New Architecture (Fabric + JSI) replaces that bridge with C++-backed synchronous calls for lower latency.

The final solutions have opted instead of full control over the entire graphics, they may still include support for Webview and native controls on some platforms:

• **QT — C++, Python, JavaScript: **QT is the corporate option, and has powered tons of IOT devices and industrial software. Uses Native graphics rendering. Has bindings to multiple languages.
• **Flutter — Dart:** Flutter is Google’s solution to this problem. It circumvents the DOM by bringing its own rendering engine (Skia) everywhere (even in browsers). You have to learn their proprietary language and widget system.
• **Avalonia — C#: **The C# responsive to Flutter, uses Skia too.

The list keeps getting bigger and bigger. Regardless of whether you’re a developer or not, you’re probably overwhelmed by all those ecosystems, languages, frameworks, libraries… ughh.

We are so cooked.

They’re all trying to solve the same problem. Creating a common abstraction layer over the environments to create a “write once, run anywhere” solution. This includes solving and “re-solving”, Windowing, Input, Platform Specific APIs, Layouting, Rendering, and Widgets/Elements.

Some of them delegate half of the issues to a WebView, while others have been in development for 30 years. The common thread here is that every solution is a painful compromise. You either ship a browser with your app, lock yourself into a vendor’s walled garden, or fight a constant battle with leaky abstractions and platform quirks.

In the end, these are all top-down patches on a fundamentally fragmented system. The dream is alive, but the reality is messy. True convergence will require a bottom-up rethink.

Tangled In The Web — The De-Facto Platform and Its Price

A man at his desk tangled in a cobweb. Generated by Gemini

Realistically, the web ends up being the common denominator for most apps. Because of its broad adoption, ease of use, and accessibility. Most teams reach for a web-first approach where they develop a web app first and then port it to other platforms — hence the birth of React Native. The ubiquity of web technologies cannot be understated. So much so that Web-first operating systems have popped up like LG’s TVOS and Chrome OS.

However, this web-first approach comes at a steep cost. The browser is a golden cage: secure, sandboxed, and universally available, but also incredibly restrictive. It was designed to display documents, not to run high-performance applications. This has historically made it a hostile environment for entire classes of software, none more so than games.

The core of the problem lies with the browser’s foundational technologies: JavaScript and the DOM. They represent an abstraction layer that is both too high and too rigid. The DOM, designed for structured documents, is an incredibly inefficient way to render dynamic and complex user interfaces. It’s the reason an entire ecosystem of frontend frameworks exists. At the same time, JavaScript acts as a mandatory, high-overhead gatekeeper.

A ton of work has been put into improving browser performance — see Catching Up With Web Performance, a podcast specifically about browser performance. However, issues like parsing, threading, garbage collection, and dynamic typing are fundamental to JavaScript. These can’t just be improved away with behind-the-scenes updates. The issues are denying the low-level hardware access needed for real flexibility. You’re forced to pay the performance tax for features you might not want, without getting the control you actually need.

Games — The Ultimate Stress Test

Games are the ultimate stress test for performance. While a CRUD app, a simple frontend to a database, can tolerate a few hundred milliseconds of latency, a game measures its performance budget in single-digit milliseconds. For decades, the web has failed this test spectacularly.

As someone who also builds games, I’ve lived this pain firsthand. Like many, I often delegate the impossible task of “write once, run anywhere” to the game engine. Unity, in my case. But Unity’s WebGL builds are a harsh reality check: they load painfully slowly, chew through memory, and just aren’t performant enough for anything ambitious. If you seriously want to target the web, you ultimately need a separate, dedicated codebase. The dream of a single codebase for all platforms is still out of reach for game developers, and the web is the biggest hurdle for these key reasons:

• No Direct Graphics Access: For a long time, the only option was WebGL. Based on OpenGL ES 2.0, it’s a 15-year-old API that lacks the modern features of Vulkan, Metal, or DirectX 12. Everything had to be funneled through slow JavaScript bindings, creating a massive performance bottleneck.
• Networking: Real-time multiplayer games depend on UDP for fast, low-latency communication. Because of security reasons, the web has historically offered no such thing. Developers are stuck with TCP-based WebSockets, which introduce unacceptable latency for fast-paced online action games.
• Storage Limitations: Modern games are enormous. AAA titles can exceed 150GB, and even indie games often clock in at over 10GB. The web’s storage APIs, like IndexedDB, were never designed to handle this scale. There’s no robust way to download and cache massive asset packs, making medium to large-scale games a non-starter.

Simple “.io” games were popular for a period, but the limitations have made “serious” game development on the web a fool’s errand. Often, games and apps that are “serious” totally avoid the web browser and require the user to download an executable. If they did support the browser, it was a stripped-down version, and non-desktop support would be questionable.

The performance penalty is simply too high — a tax that no high-end game can afford to pay. Despite the web's ubiquity, this in effect has chased games off the web and into downloadable app distribution. This has caused proprietary app stores to thrive at the detriment of the consumer.

Why Should You Care? — A High Stakes Game

Everything is okay. Generated by Gemini.

It’s easy to treat all this as just a technical debate, but the stakes are much higher. The way we build and distribute software shapes the entire digital world. What gets built, who can build it, and who controls access.

The Battle of Digital Storefronts

Steam’s dominance in PC gaming distribution exemplifies the platform power problem. For years, Valve’s platform has functioned as the essential gatekeeper for reaching PC gamers. As a game developer, Steam is the main option — If you want significant reach, you play by their rules and accept their terms. Steam’s revenue structure demonstrates how entrenched these systems are. They essentially take upwards of a 30% cut, just to provide users with a coherent storefront and basic meta features.

Valve, the company behind Steam, has been sued multiple times for abuse of market power, monopoly allegations, and various other consumer cases. Steam dominance and first-mover advantage can be clearly seen in Valve Corporation’s financials. According to leaked financials, they make upwards of $15 million in profit per year per employee. This is among the highest in the world. This shows the little work that is truly being done to maintain this monopoly.

Ironically enough, the Steam Marketplace is built using Chromium, a free and open-source browser technology. An essential technology powering the same web that they’re circumventing.

The mobile landscape presents an even more restrictive environment. Apple’s App Store exemplifies platform control through its comprehensive gatekeeping mechanism: another 30% commission on digital goods and services, strict content policies, and an opaque review process that can make or break applications.

This is a huge problem affecting developers and consumers alike.

Epic Games, the creator of Fortnite, has taken this battle upon their own for us. Epic created the Epic Store to directly compete with Steam and has set a new 12% standard revenue cut. This forced the industry to re-examine what was “fair” for digital distribution. Additionally, Epic has confronted Apple in an infamous legal dispute. Internal Apple documents exposed during litigation showed the company’s deliberate efforts to maintain its revenue streams and prevent competition. These efforts weren’t merely about in-app purchase fees — it was fundamentally about platform sovereignty and the right to compete within a digital ecosystem that billions depend on. (There’s so much interesting reading on the cases from Apple/Steam, a highly recommended topic for further reading.)

This could all be circumvented if apps and games were directly usable from the browser, both on desktop and mobile.

The Hidden Cost — Developer Time and Energy

Behind every app, there’s a team of developers burning countless hours wrestling with platform quirks, arbitrary restrictions, and ever-changing APIs. So much time is spent solving problems that have nothing to do with the end user. For example, simply making the same app work on different platforms, or jumping through hoops to satisfy a gatekeeper’s requirements. This is time and energy that could be spent building better features, fixing bugs, or improving performance. Instead, it’s wasted on busywork and bureaucracy.

This issue cannot be understated. Within the software industry, literal “porting companies” exist, whose sole job is to migrate apps to different platforms. The numbers again tell the story of this hidden cost. The game porting services market alone was valued at $1.2 billion in 2024 and is projected to reach $3.5 billion by 2033. Even for simple mobile app porting, developers can expect to spend between $15,000 and $50,000 to transition their application between iOS and Android.

But the real frustration comes from platform gatekeepers and their unpredictable review processes. Developer Jake Nelson experienced this firsthand when his routine iPhone word game update took 15 revisions and a full month to get approved, despite never receiving clear guidance on what was wrong. One indie developer was rejected by Apple’s App Store 43 times for the same app, leading him to create an AI-powered Chrome extension just to help navigate the rejection process.

The app store review process has become so notoriously unpredictable that developers commonly describe it as “nightmarish”. Google’s Play Store isn’t much better — when they introduced more stringent reviews requiring at least three days for approval, developers who had been publishing since 2010 found their apps suddenly stuck in review limbo. The review process is so opaque that developers often receive only generic rejection messages, leaving them to shoot blindly.

These aren’t just minor inconveniences. When Apple’s review process delays can stretch from days to weeks, and resubmissions reset your position in the queue entirely, developers lose crucial momentum and revenue. The unpredictability forces developers to build buffer time into every release cycle, further extending development timelines and increasing costs.

All of this represents a massive hidden tax on innovation. Developers are spending weeks or months solving platform-specific problems instead of creating value for users. The existence of billion-dollar porting industries and the countless horror stories of arbitrary rejections reveal a system where the platforms have shifted much of their complexity burden onto the people building the software we all depend on.

The Web — Ubiquity at a Price

You’d think the web would be the answer — open, universal, and accessible from anywhere. But web apps are often a compromise. Performance lags behind native apps, especially for demanding use cases like games or creative tools. Yet companies still force a web implementation, because it’s the only way to reach everyone without getting locked into a single vendor’s ecosystem. The result is that users get slower, clunkier apps, and developers have to maintain multiple codebases or accept a lowest-common-denominator experience. Even for simple applications, developers resort to big frameworks to do the heavy lifting. Alex Russell, a leading web advocate, starkly puts it:

CPUs are not improving fast enough to cope with frontend engineers’ rosy resource assumptions. <…> Though the JS community remains in stubborn denial about the costs of client-side script.

— Alex Russell, The Mobile Performance Inequality Gap, 2021

The performance of the web isn’t just about picky users; it has inadvertently created income inequality in who can access the World Wide Web. A problem that is currently increasing, according to Alex’s latest 2024 performance gap post:

“The performance gap between wealthy users and budget shoppers grew more this year than the gains from improved chips delivered at the low end. Inequality is growing faster than the bottom-end can improve.”

Modern, highly interactive sites may fly on the latest flagship devices, but become frustrating or even unusable for billions on slower connections and less powerful hardware.

The problem isn’t limited to a technical headache for developers. It’s a question of who gets to participate in the digital economy, who controls distribution, and how much innovation is possible. Walled gardens stifle competition and creativity. Fragmentation wastes developer talent. Poor performance and forced compromises hurt users. The push for open, portable standards isn’t just about convenience. It’s about reclaiming agency for both developers and users, and building a healthier, more vibrant software ecosystem for everyone.

As noted by Alex Russell, the web stands as the final stronghold for an open and competitive software ecosystem. However, he cautions that this promise is threatened by layers of unnecessary complexity and inefficient code, which risk locking out users on less capable devices.

The Web Is THE Standard

The web has become the de-facto target for modern software, not because it’s perfect, but because it’s everywhere. If you want your app to reach the widest possible audience, the web is the only platform you cannot ignore. However, for years, developers have been boxed in by the limitations of the browser: slow JavaScript, the rigid DOM, and a lack of low-level access to hardware. The web was never designed to be a universal application platform, but the world demanded it anyway.

These issues have been recognized by the World Wide Web Consortium (W3C), and luckily, new APIs are being introduced to break through the old barriers and finally give developers the tools they need to build truly high-performance, portable, and secure applications. I believe that it is these new standards that are going to drive the convergence. The most noteworthy are WebAssembly, WebGPU, WebTransport, and WASI. These are not just incremental upgrades; they’re a bottom-up rewrite of what’s possible.

• WebAssembly gives us a fast, safe, and portable binary format for code.
• WebGPU unlocks modern graphics and compute power, finally bringing the web up to par with native platforms.
• WebTransport breaks old security restrictions, speeding up online connections.
• WASI provides a secure, standardized interface to system resources.

Let’s look at them individually and why they’re crucial for unlocking high-performance applications in the browser.

WebAssembly — A Common Instruction Set Architecture

WebAssembly (abbreviated Wasm) is the cornerstone of this convergence. It first appeared in 2017, and as opposed to JavaScript, it is designed to be a safe, fast, and efficient binary format for code. Instead of a programming language, Wasm is a virtual portable Instruction Set Architecture (ISA). An ISA defines the set of operations a computer can execute. Wasm is a virtual ISA, meaning that it doesn’t describe the operations of an actual computer, but rather a common set of operations that most computers support. A translation to native instructions is still needed, but Wasm sidesteps the entire frontend compiler pipeline, meaning lexing or parsing is not required. For translation, Wasm supports both just-in-time (JIT) and ahead-of-time (AOT) compilation. These are all huge performance advantages.

Another advantage is the ability to compile your native code to WebAssembly directly. Instead of compiling your C++, Rust, or C# code separately for x86, ARM, or whatever comes next, you compile it once to Wasm. That single binary can run on any device with a Wasm runtime, which, thanks to browsers, is nearly every device on the planet.

A compilation target for other languages was so sorely needed that Asm.js was created already in 2013 to try and solve this problem. It was a subset of JavaScript that tried to be a common target by avoiding JS-specific features. However, it was a hack. It was never meant to be a long-term solution. It was a stopgap measure to buy time until WebAssembly was ready.

A graph showing how WebAssembly can be compiled from any language. from: Future Internet

Of course, there are still challenges. For performance-critical applications, hardware intrinsics are a sticking point. In my own experiments with high-performance particle systems, I’ve relied heavily on SIMD (Single Instruction, Multiple Data) instructions — specialized CPU instructions that allow processing multiple data points simultaneously, like SSE and AVX, to get maximum throughput from the CPU.

Thankfully, this is being addressed. The Wasm SIMD & Relaxed SIMD proposals introduce a standardized, portable 128-bit SIMD instruction set. While it might not give you access to the full power of a specific chip’s AVX-512 capabilities, it provides a powerful common denominator that unlocks significant performance gains without sacrificing the “Write Once, Run Anywhere” promise. For those looking for absolute performance, like AAA Games, you’re still left with a choice: use portable Wasm and sacrifice peak performance, or write native code and lose portability.

While I’m still hoping for variable length or larger SIMD widths, the current implementation is a pragmatic compromise that makes high-performance Wasm a reality.

WebGPU — Enabling Graphics Computing

Where Wasm allows low-level access to CPUs, WebGPU allows access to graphics computing. If the web is going to be the portal to “compute”, you have to include the GPU. WebGPU is the long-awaited answer to the web’s graphics bottleneck. Even though graphics cards were originally made to run graphics, their fast and parallel nature enables the acceleration of a whole array of computing tasks. They unlock new possibilities for games, AI, scientific computing, machine learning, and high-performance visualization. The new WebGPU API makes this possible, all running securely in the browser or any environment that supports the standard.

For years, developers were stuck with WebGL, a wrapper around OpenGL ES 2.0, which was already outdated when it arrived in browsers. WebGL made it possible to render 3D graphics on the web, but it was never designed for the demands of modern computing.

WebGPU is an interface built on top of different graphics APIs. from: LearnWebGPU

WebGPU is an API inspired by and abstracts over Vulkan, Metal, and DirectX 12. WebGPU gives developers direct, efficient access to the GPU, enabling advanced rendering techniques, compute shaders, and parallel processing that were previously impossible on the web. WebGPU is now available in most modern browsers (like Chrome, Edge, and Safari), though support is still evolving.

WebGPU has its limitations for AA and AAA development. Lack of shared resources and sophisticated binding models that modern games require creates significant bottlenecks. State changes in WebGPU are expensive, and without bindless resources, you’re constantly rebinding textures and buffers.

Here again, these issues are recognized and are being actively worked on. Bindless resources are coming to WebGPU. The proposal is actively being developed, with an expected timeline of late 2026. Bindless lets shaders access an unlimited number of textures and resources without the traditional binding limitations. This is the feature that could unlock at least AA gaming on the web.

WebTransport — Fast, Secure Networking

The last API I want to highlight is WebTransport. Fast and latency-free networking isn’t only required by multiplayer games anymore; a wide array of online collaborative tools now depend on solid networking. Including my own project saket.studio. The last barrier to writing network-enabled web applications was the limitations of the networking protocol.

TCP vs QUIC handshake from wikimedia.org

Previously, only HTTP/2 and WebSockets were available options for client-server apps, both relying on TCP. Transmission Control Protocol (TCP) is a connection-oriented protocol. Before data transfer, TCP establishes a connection using a three-way handshake, then divides the data into packets, each tracked with sequence numbers to maintain reliable, ordered, and error-checked delivery of data between devices across a network. Essentially means that TCP sacrifices performance for the reliability of arrival of packets, a tradeoff you cannot make for real-time applications.

For real-time applications such as games or collaborative tools, you often want to synchronize the position of a user, which changes continuously. You would only care about the most recent position, and you don’t care about the previous locations. With TCP, if you “lost” a position in transmission, you would have to wait until it is resent, which is undesirable.

Unlike these traditional protocols, which are built on TCP, WebTransport leverages QUIC’s UDP foundation to improve performance by reducing latency and streamlining security. Unlike WebSockets, which offer a single, ordered, reliable stream, WebTransport exposes multiple parallel streams and datagram support, giving developers more granular control over data delivery, prioritization, and reliability based on their application’s needs. Combined with faster connection setup and built-in security, WebTransport unlocks new possibilities for efficient, scalable, and responsive web applications that were previously difficult to achieve with traditional TCP-based solutions

WebTransport is fundamentally a better, more low-level abstraction layer and is expected to eventually replace WebSockets. This is the last key to enable online and low-latency games and applications with richer communication capabilities.

New Web Standards — Less Abstraction, More Power

A unifying characteristic of these new standards is their low-level, capability-based APIs that acknowledge the vast diversity of hardware on which software runs. They empower developers to leverage specific hardware features when available, without imposing such requirements, providing both flexibility and control. Collectively, these technologies transform the web into a genuinely universal platform.

WebAssembly, WebGPU, and WebTransport do more than just enhance the web’s capabilities; they fundamentally redefine what “cross-platform” means. For the first time, we have a coherent set of standards embraced by all major browsers that offer true universality. This convergence delivers a platform that is simultaneously portable, secure, and increasingly performant, enabling a seamless path to run everything from simple CRUD applications to cutting-edge, high-end games — all from a single shared codebase.

Hasn’t this been tried before?

A caveman playing with a rock tied to a stick. Generated by Gemini

Now, the C programmers among us might be shrugging their shoulders. This isn’t the first time we’ve seen virtual machines promise cross-platform compatibility. After all, the “Write Once, Run Anywhere” (WORA) motto comes from Sun Microsystems and their promise of Java and the Java Virtual Machine (JVM) in 1995. Similarly, Microsoft later created C# and the Common Language Runtime (CLR). They both promised an end to developers' frustration of targeting specific hardware.

Hardware began to fragment significantly in the late 1980s and throughout the 1990s, creating a diverse landscape of processors, operating systems, and device architectures. The Virtual Machines (VMs) were therefore created and became wildly popular, especially in enterprise settings. Concurrently, the rise of Object Oriented Programming (OOP) piggybacked on the encapsulation and reusability that these platforms promised, to the detriment of the entire industry; however, that’s a different story. Despite these efforts, the dream of convergence never came true. Later the mid-2000s, the web proliferated and took over the torch of Write Once, Run Anywhere.

Now the landscape is more split than ever, but my prediction is that with the introduction of the new web standards, this time will be different, mainly for two reasons.

The first reason is GPU access. Because of emerging trends within AI, more computing will be delegated to the GPU. An obvious shortfall of the previous generation of VMs is the lack of GPU access. For a VM to be a truly universal abstraction over the hardware, the GPU has to be a first-class citizen alongside the CPU.

The other is the fact that JVM and CLR require separate runtimes to be installed, whereas every device already has a web browser. The web platform dictates the computing environment for a huge percentage of applications. WebAssembly doesn’t need special installation — it runs on any device with a browser, which is essentially every computing device made in the last decade.

WasmGC

If you aren’t convinced yet that this time will be different, just have a look at how the Java and .NET ecosystems are changing. They have both added support for targeting compilation to Wasm. Blazor compiles the whole Mono runtime to WASM to run .NET applications in the browser!

While compiling an entire runtime isn’t ideal, the W3C is actively addressing this with the WebAssembly Garbage Collector (WasmGC) proposal. Before WasmGC, compiling languages like Java or C# to WebAssembly meant bundling another garbage collector next to the existing JS one, making binaries unnecessarily large and slow. Now, with WasmGC, theoretically, these languages can use the browser’s (or host’s) built-in garbage collector directly. This means smaller binaries, faster startup, and — crucially — shared memory management between JavaScript and WebAssembly.

This breakthrough means the entire ecosystem of garbage-collected languages — including Java, C#, Kotlin, Dart, and Scala — could efficiently target WebAssembly without the overhead of a custom runtime. This opens the door for a new wave of truly cross-platform applications, allowing developers to write in their language of choice and run their code everywhere Wasm is supported.

Going Native — The Browserless Web

For years, “web technology” meant “browser technology.” But that’s changing fast. This new generation of standards, especially WebAssembly and WebGPU, is breaking free from the browser and becoming true, portable computing foundations. This is a fundamental shift: the web stack is evolving into a universal runtime, not just a browser sandbox. That is what is causing this convergence.

WebAssembly and WebGPU have nothing to do with “web” per say.

These standards’ association with the “web” is unfortunate and causes misconceptions because their utility spans wider than the browser. Runtimes like Wasmtime, Wasmer, and WasmEdge let you execute WebAssembly modules natively outside the browser. At the same time, projects like Dawn (Google’s WebGPU implementation) and wgpu-native (Rust’s implementation) bring the full power of modern GPUs to native apps, using the same APIs as the browser, but without the browser’s constraints. This means you can build a desktop app with WebGPU and Wasm, and run the same codebase in the browser with minimal changes. The line between “web” and “native” is dissolving — they are converging.

WASI — The OS Interface

The last link to run web applications in any environment is an abstraction over operating systems. That’s exactly what the WebAssembly System Interface (WASI) is. WASI provides standardized, secure access to files, networking, and system resources, all in a way that’s portable and sandboxed. With WASI, you’re not just running code in a browser sandbox; you’re building applications that can run anywhere, with direct access to the underlying system, but without the security issues of native code. This is what enables the vision of a “universal runtime”.

For example, with WASI, you can write a CLI tool in Rust, compile it to WebAssembly, and run it on any platform — Linux, Windows, macOS, or even in the browser — without changing your code. This is a huge leap for portability and security.

We are a couple of WASI proposals away from this goal. Right now, Native applications resort to something like GLFW or SDL to handle cross-platform system support. Right now, they provide key APIs which WASI hasn’t finalized, Windowing, Audio, Clipboard, HID/USD support for pointers, haptic, keyboards, joysticks, etc.

WASI-GFX — The Native Graphics Bridge

The WASI-GFX is a major proposal. It aims to define a standardized, low-level graphics and compute interface for WASI, allowing WebAssembly modules to directly utilize WebGPU—no browser, no JavaScript, just pure performance.

This is necessary because the current WebGPU API is deeply tied to browser security models and JavaScript interoperability. In the browser, all GPU access is mediated through JavaScript and the DOM, which adds overhead, restricts capabilities, and enforces a security model that isn’t always relevant or desirable outside the browser.

By disconnecting from JavaScript interop and browser APIs, wasi-gfx enables Wasm applications to access graphics hardware natively, with fewer layers and less friction. This opens the door for high-performance, portable applications that can run anywhere a WASI runtime exists—not just in browsers, but on desktops, servers, and embedded devices. It could enable “bring your own UI solution” flexibility. You could build applications using any UI framework — React, Vue, native widgets, or custom solutions — while sharing the same underlying runtime.

For example, imagine a 3D modeling application compiled to WebAssembly that could run identically on a Linux workstation, a Windows gaming PC, or even a headless server for batch rendering — all using the same binary, accessing the GPU directly through wasi-gfx, without requiring a browser or JavaScript runtime. This is a critical step toward making Wasm a true, self-sufficient platform for native applications, not just web apps.

Docker

These web standards won’t just have an impact on desktop environments. In a famous tweet, Solomon Hykes, co-founder of Docker, expressed significant views on the potential impact of WebAssembly (WASM) and the WebAssembly System Interface (WASI) on container technology and orchestration tools like Docker and Kubernetes:

[embed]Tweet by Solomon Hykes, co-founder of Docker, expressing the importance of Wasm and WASI

This highlights how WASI could provide a lightweight, portable, and secure runtime environment natively for applications, a capability that Docker later introduced, but with more complexity and overhead

Hykes emphasizes that replacing containers also implies replacing Linux since containers rely on Linux kernel features such as cgroups. WASI offers user-space virtualization and capability-based security, providing strong isolation with less overhead than traditional containers, potentially simplifying the deployment and scaling of applications.

He perceives WebAssembly and WASI as transformative for where computing is headed, especially for server-side and edge workloads, where their portability, speed, and security shine, in contrast to containers, which are heavier and more complex due to bundling OS dependencies.

However, Hykes does not suggest WASI will outright replace Docker or Kubernetes today. Instead, he envisions a future where Docker could run containers alongside WASI-based workloads, showing a complementary evolution rather than a sudden replacement.

His perspective highlights the importance of WASI as a system interface, making WebAssembly practical for general computing beyond browsers, enabling smaller, faster, and more secure isolated software components.

Native Convergence

With all of these pieces in place, Wasm, WebGPU, WASI, one can see that there’s not a big step to using these standards in a native environment outside the browser. You could expect to see way more apps being developed using these web standards, also running in a native environment.

The convergence is already happening in my personal projects. I’m developing Saket Studio (name subject to change), which is a “Holistic Collaborative Data-Oriented Creative Software” 😅. It’s targeting desktops, macOS/Windows/Linux. Even though the app is being written in C# and using SDL3, it is utilizing parts of these web technologies. For graphics rendering, I’m using WebGPU Native under the hood, with C# bindings developed by EmilSV (which leverage Google’s Dawn implementation). Also, I plan to use WebAssembly as the plugin format, so users can write and run high-performance plugins in any language that compiles to Wasm.

They aren’t limited to the browser. You can pick and choose how to use these technologies. They are the stepping stones to finally achieving the Write Once, Run Anywhere dream.

The Portable Applet — Endgame

With the web pioneering these new standards, I see them evolving into a new kind of portable applet. One that truly supports “Write Once, Run Anywhere”, including the web. Imagine building a single application — a self-contained bundle of code, assets, and logic, compiled to WebAssembly and using standardized APIs for graphics, storage, and networking. It doesn’t care about the underlying OS or hardware. If the host supports the standards, the applet just works.

This means teams can actually write “web-first”, and have it run performantly on native machines without much porting effort. This means no more specific API’s of GLFW, winit, SDL3, etc. They could all simply implement a universally defined API, and they would simply be implementations of these web standards. Similar to how WASM runtimes work today. Of course, for some workloads like AAA games, hardware-bound simulations, and highly specific OS dependet apps, this convergence might still be out of reach for now.

Image going to a website to access an application, say Figma. Similar to how Progressive Web Apps (PWA) work, you don’t have an explicit download or installation step. You simply drag the icon to your desktop, and it will just work alongside your other native applications. Not opening in a browser and similar performance to your other apps.

Operating System Support

OS-level support for web standards is already a thing in web-first operating systems like Chrome OS and LG webOS. Where web applications are first-class citizens, the transition might be seamless. But I could foresee a future where desktop and mobile operating systems alike could natively ship with a Wasm-like runtime, to support this future applet.

A future operating system could even just be a thin layer, and Wasm modules are the real applications, portable across any hardware that supports the standard. This creates a unified computing stack where the same application can run on x86, ARM, RISC-V, or any future architecture without modification. The abstraction layer handles the complexity, not the developer.

Conclusion

This model would finally break the cycle of fragmentation and endless porting. Developers could focus on building great experiences, not rewriting code for every platform. Users could expect their favorite tools and games to work everywhere, with the same quality and features. And the entire ecosystem would benefit from a unified, open, and secure foundation.

This is what Progressive Web Apps (PWA) wanted to be, but failed because of the limitations of the web. This new applet could be distributed in the same way through websites or app stores. This could remove the user barrier to installing applications, and possibly break distribution monopolies.

They could run in a browser, a native shell, or a future OS built around these standards. Security is built in by default, thanks to the sandboxed nature of WebAssembly and WASI. Performance is no longer a dealbreaker, because the applet can access the GPU directly via WebGPU and run at near-native speeds.

The Practical Path Forward

We’re witnessing the birth of a new computing platform. WebGPU and WebAssembly represent portable, secure, and reasonably performant alternatives to traditional platform-specific development. The “web” in these technologies is increasingly misleading — they’re portable computing standards that happen to run in browsers.

The key insight is that this isn’t just about making web apps faster — it’s about creating a fundamentally new computing paradigm. One where the same application binary can run anywhere, access hardware efficiently, and maintain the security model users expect. The “portable applet” represents the endgame: self-contained, secure, performant applications that work identically across every device.

The convergence I’ve outlined isn’t a distant dream — it’s happening now, in stages. Many CRUD applications and frameworks already take advantage of Wasm today. Real-time applications are rapidly improving as WebGPU matures and WebAssembly performance gaps narrow. Within the next decade, as bindless resources arrive and WASI stabilizes, we’ll see AA games and high-performance applications become viable on this unified platform. The deployment advantages are compelling, and the development experience is approaching native quality.

This transformation will happen gradually, then suddenly. Early adopters are already building with these technologies. Major platforms are beginning to embrace them.

The future of apps isn’t just converging — it’s already here for those ready to embrace it.

You can find more of my technical writing and projects at saket.dk & my blog on Medium.