The web is running on borrowed time

Every web application you have ever used runs on three technologies that were never designed to work together. HTML was created in 1991 to mark up academic documents. CSS arrived in 1996 to separate presentation from structure. JavaScript was designed in ten days in 1995 to add basic interactivity. Each one was a patch on the previous layer’s inadequacy — and thirty years later, we are still stacking patches.

The stacking problem

These are three fundamentally different computational paradigms forced to coexist: declarative structure, constraint-satisfaction styling, and imperative single-threaded computation. The browser juggles all three simultaneously, in a runtime never designed for any of them together.

Consider what happens before a single button renders: hardware, kernel, host operating system, browser, JavaScript virtual machine, framework, and finally your component. Four to six layers of abstraction. The overhead is not incidental — it is structural.

The browser is already an operating system

This is the part most people miss. The modern browser has a process manager, a memory manager, a security model, a networking stack, a rendering pipeline, a full virtual machine, file I/O abstractions, and inter-process communication. It is not like an operating system. It is one — running on top of another one, duplicating nearly everything underneath it.

Every workaround the industry has produced — PWAs, Electron, Tauri, React Native — patches the same root problem: web apps are guests on the operating system, not citizens of it. A 150-megabyte download to ship a notes app is not a solution. It is a symptom.

What a first-principles answer looks like

We call the idea an Internet-Native Runtime: not a browser, not a virtual machine, but a first-class application host where the network is a primitive of the runtime itself. Applications would live on the network, execute locally with real hardware access, and be secured by declared, auditable capabilities rather than sandboxed isolation.

• One language, one compilation target — structure, style, and behaviour unified, compiled rather than interpreted.
• Capability-based security — an app declares exactly what it needs; the runtime enforces it at the OS level. Entire vulnerability classes — XSS, CSRF, supply-chain scripts — stop being possible by construction.
• Direct rendering — scene graphs submitted straight to the GPU, not a cascade of virtual DOM diffs and layout recalculations. The battery savings alone would be measured in hours.
• Web distribution, native execution — apps fetched, verified, and cached from the network, running with native-level performance.

Why we write about this

Xelerate Lab is a services company. We build websites, platforms, and institutional systems — and we build them well precisely because we think about infrastructure from first principles, all the way down. The INR is our long-horizon research interest: a statement about where we believe computing should go, and the kind of thinking we bring to everything we ship in the meantime.

It is also an open invitation. If this problem interests you — as a researcher, an engineer, a foundation, or a partner — we would genuinely like to talk.