The web may be the most successful software platform ever created. From a systems engineering perspective, it is also surprisingly inefficient.
Every day we download the same libraries, ship source code instead of precompiled artifacts, and compile applications inside browsers rather than distributing optimized executables. We tolerate thousands of competing implementations of the same ideas and routinely accept forms of duplication that would seem wasteful on almost any other software platform.
If engineers were designing the web from scratch today, there is a good chance they would not build the web we have.
Yet many of the web’s apparent inefficiencies are not accidents. They are tradeoffs. The more I studied browser history, the more I noticed a recurring pattern: every optimization requires coordination.
Shared runtimes require standards. Shared libraries require registries. Platform APIs require governance. Compatibility requires agreement. Efficiency often comes from getting more people to cooperate.
At first this sounds like a technical observation. It isn’t. Coordination determines who gets to make decisions, who controls the platform, and who can innovate without permission. Viewed through that lens, the history of the web starts to look less like a story about browsers and more like a story about power.
What began as a thought experiment about browser binaries eventually became a question about participation itself. Why did the web become the most accessible software platform in history? And what would we have had to sacrifice to make it more efficient?
The Web Was Never Meant To Run Applications
To understand why the web looks the way it does, it helps to remember what it was originally built to do.
When Tim Berners-Lee created the World Wide Web, he wasn’t designing a software platform. He was designing a document system. Researchers needed a way to publish, retrieve, and navigate information distributed across different computers. URLs identified documents, HTTP transferred them, and HTML described them. The browser’s job was simply to render information.
Seen through that lens, many of the web’s unusual characteristics stop looking strange. Documents are naturally represented as text. Text is easy to create, inspect, modify, and transmit. The early web optimized for publishing information, not distributing software.
Software arrived later.
JavaScript, introduced in 1995, was never intended to power full applications. It existed to make documents interactive. Validating forms, responding to button clicks, and updating portions of a page without a reload were the kinds of problems it was designed to solve.
Then capabilities accumulated. CSS separated presentation from structure. Browsers gained storage, graphics, media, networking, and eventually technologies like Canvas, WebGL, and WebRTC. The web did not become an application platform because someone designed it that way. It became one because every generation added another capability.
Like a city that gradually expands beyond its original boundaries, the browser became something much larger than anyone initially intended.
We Already Tried Building A Different Web
The most interesting part of the binary-web thought experiment is that it isn’t entirely hypothetical. The industry has already experimented with more application-centric versions of the web.
Java Applets distributed executable code through browsers. ActiveX exposed powerful platform capabilities. Flash became a runtime for games, media, animation, and sophisticated applications. Silverlight attempted something similar.
For a time, some of these technologies looked like the future. Flash in particular solved problems that HTML could not. Before HTML5, it powered video streaming, interactive media, browser games, and rich user interfaces across much of the internet.
Looking back, it is tempting to treat these technologies as failures. But many were technically impressive and, in some respects, ahead of the standards that eventually replaced them.
What matters is the direction the web chose.
Again and again, capabilities that began inside specialized runtimes migrated into open standards. Video became a browser feature. Audio became a browser feature. Graphics became browser APIs. Animation became browser APIs.
Part of this shift was driven by security, portability, accessibility, and performance. But another force was operating beneath the surface.
The more functionality lives inside a shared runtime, the more everyone must agree on that runtime. The more everyone must agree, the more decision-making becomes concentrated.
The web repeatedly chose architectures that distributed power more broadly, even when they were not obviously the most efficient.
Why Doesn’t The Web Ship Applications?
This question originally motivated the entire thought experiment.
Most software platforms distribute precompiled artifacts. The web largely distributes source code. At first glance, that seems irrational. Why download JavaScript and compile it on millions of devices? Why repeatedly ship framework code? Why reconstruct applications inside every browser?
The answer becomes clearer when viewed through the lens of coordination.
The web minimizes the amount of agreement required before someone can create and publish something useful. Anyone can deploy HTML. Anyone can deploy JavaScript. Anyone can invent new abstractions. No platform vendor, runtime committee, or operating-system release cycle needs to approve the idea first.
The cost is efficiency.
The benefit is independence.
A World Built Around Applications
Imagine an alternate history where applications, not documents, were the web’s primary unit of distribution.
A URL points to a program rather than a page. Publishers distribute precompiled artifacts. The browser behaves more like an operating system runtime.
The distinction is not really text versus binary. Modern browsers already process enormous amounts of binary data through images, audio, video, fonts, and WebAssembly modules. The real question is where complexity lives.
Today’s web performs much of its assembly and compilation on the client. A more application-centric web would move more of that work to publishers and shared runtimes.
The benefits are easy to imagine. Faster startup. Less parsing. Smaller application payloads. More predictable execution.
But every one of those advantages introduces new dependencies. Who defines the runtime? Who maintains compatibility? Who decides when interfaces change? Who resolves disputes when different interests collide?
A technical problem gradually becomes a governance problem.
Shared Libraries And The Cost Of Efficiency
Shared runtimes are a good example.
In theory, browsers could download common libraries once and reuse them across thousands of applications. From a bandwidth perspective, this sounds elegant.
Yet software history repeatedly moved in the opposite direction. Static linking became common. Applications bundled dependencies. Containers packaged entire execution environments.
The reason is simple: duplication is often cheaper than coordination.
If every website depended on Browser Runtime v4, someone would need to decide when v5 ships, how compatibility works, and who bears the cost of maintaining old versions. A bandwidth optimization quietly becomes an organizational problem.
Eventually you have created something that begins to resemble an operating-system vendor.
Bandwidth costs become governance costs.
The Forgotten Superpower Of The Web
The strongest argument for the web’s architecture may have nothing to do with performance.
It may be that the web dramatically lowered the cost of participation.
Most software platforms separate creators from consumers. You install an application, use it, and remain largely isolated from its implementation. The distance between user and creator can be enormous.
The web developed differently.
When I first started learning web development, I spent an embarrassing amount of time copying other people’s websites. Not to steal them, but to understand them. I’d open View Source, save the page locally, and start changing things. Delete sections. Modify styles. Break layouts. Figure out why something worked. Then put it back together again.
Some of the most valuable lessons I learned came not from documentation or courses, but from taking apart software that was already running in my browser.
For decades, this was one of the web’s hidden educational systems. A curious teenager with a browser could inspect the same technologies used by major companies. No enrollment required. No approval required. Curiosity was enough.
And the consequences extended beyond learning.
For years, website owners seemed genuinely surprised to discover that users could see everything they shipped. People installed extensions that removed paywalls, revealed hidden content, or modified sites in ways their creators never intended. The details varied, but the lesson was always the same: once content reached a browser, users possessed it in a very real sense.
Website owners often believed they controlled what users could see. The browser quietly taught a different lesson.
If you’ve sent it to the client, it no longer belongs entirely to you.
The browser was never just a viewing device. It was a participant. Users could inspect, modify, and experiment with the software they received.
That matters because participation is not only about publishing software. It is also about learning how software is built.
A platform that lowers the cost of learning eventually lowers the cost of innovation. A platform that lowers the cost of innovation distributes power more broadly.
Seen from that perspective, View Source was never just a debugging feature.
It was an educational institution.
WebAssembly And The Road Not Taken
The strongest evidence for this entire argument may already exist.
WebAssembly delivers many of the advantages advocates of a binary web wanted. Binary distribution, near-native performance, language independence, and portable compilation targets.
For decades, engineers argued that the web needed something like this.
Eventually they got it.
Yet WebAssembly did not replace HTML, JavaScript, or the document model. Instead, it became another layer of the existing web.
That decision feels significant.
The web embraced binary execution without abandoning the architecture surrounding it. It accepted the optimization while rejecting the larger shift in power and coordination that might have accompanied it.
What Was The Web Actually Optimizing For?
At some point I realized this thought experiment was never really about binaries.
It was about power.
A more application-centric web optimizes for efficient execution. Less parsing, more code reuse, smaller payloads, and stronger contracts. The engineering case is compelling.
The web we built often optimized for something else.
Lower coordination costs.
Permissionless publishing.
Independent experimentation.
Accessible learning.
Distributed decision-making.
From a systems engineering perspective, the web often looks irrational. It repeatedly chooses duplication over efficiency. Frameworks are downloaded millions of times. Dependencies are bundled instead of shared. Similar ideas are implemented again and again.
And yet those inefficiencies purchase something valuable.
No central runtime owner.
No mandatory package registry.
No gatekeeper deciding who gets to innovate.
The same pattern appears throughout the web’s history. Developers built frameworks instead of waiting for browser vendors. Capabilities that began inside proprietary runtimes migrated toward open standards. Sites shipped their own code rather than depending on shared infrastructure.
Again and again, the web chose architectures that distributed decision-making rather than concentrating it.
The question is not whether a more application-centric web would have been technically superior. In many ways it probably would have been.
The question is what we would have traded away to get those benefits.
A more application-centric web optimizes for efficient execution.
The web we built optimizes for participation.
Looking back, I’m not convinced the web made the technically superior choice. But I increasingly suspect it made the choice that distributed power most widely.
The web’s greatest achievement may not be that it allowed anyone to publish software.
It may be that it allowed anyone to learn how.
AI Usage and Diligence Statement
Artificial intelligence was used extensively throughout the development of this article. I provided the initial concept, technical thought experiments, supporting observations, personal experiences, and editorial direction. AI was then used to generate draft text, explore alternative interpretations, suggest structure, and refine prose.
The writing process was highly iterative. Rather than generating a single article from a prompt, I engaged in an extended dialogue with the AI, providing feedback, criticism, and additional ideas across multiple revisions. I also instructed the AI to critique the article from different perspectives, including those of a browser engineer, editor, and publicist, and used those critiques to guide subsequent revisions.
AI produced a substantial portion of the article’s wording, transitions, and organizational structure. However, the selection of arguments, overall thesis, inclusion or exclusion of ideas, final conclusions, and personal anecdotes were directed by me. The final article reflects a collaborative process in which AI acted as a drafting, editing, and critical review tool under human supervision and editorial control.
I take full responsibility for the opinions, arguments, conclusions, and factual claims presented in this article. Although AI was used extensively during drafting and revision, the final selection of ideas, arguments, and conclusions was made by me, and the article reflects my views at the time of publication. All factual claims are true to the best of my knowledge.