Forking the Web: A Proposal for a Simpler, Document-Centric Internet
The modern web has evolved from a system of linked hypertext documents into a complex ecosystem of heavyweight application engines. For many, the current state of the web—characterized by bloated specifications, monolithic browser engines, and the omnipresence of JavaScript—represents a departure from the internet's original purpose: the efficient exchange of human knowledge.
In a provocative proposal titled "On Forking the Web," Rodrigo Arias Mallo suggests that the only way to reclaim this simplicity is to create an alternative specification. The goal is not to clone the existing web, but to build a lean, stable framework that allows humans to share information without requiring a full-blown virtual machine to render a single page.
The Pillars of a Simplified Web
Mallo's vision for a "forked" web is built upon several core technical and philosophical goals designed to prevent the complexity creep that has plagued HTML over the last three decades.
1. Radical Simplicity and Size Constraints
To ensure a diversity of clients and low barriers to entry for new browser developers, the specification must be short. Mallo proposes a literal physical constraint: the entire compressed specification should fit within 1.44 MiB—the size of a classic floppy disk. This prevents the "specification bloat" that currently makes the HTML spec an 18 MiB behemoth.
2. Semantic Versioning vs. Living Standards
The current "Living Standard" model, where specifications change weekly, makes it nearly impossible to build a compliant client without constant updates. Mallo argues for strict semantic versioning (e.g., 1.2.3). Under this model, a published version of the standard would never change; breaking changes would require a major version bump, and typos would be handled by patch versions. This would allow a developer to build a perfectly compliant browser based on a printed copy of the spec, knowing it will remain compatible forever.
3. Strict Grammar and Zero Tolerance
One of the most controversial aspects of the proposal is the requirement for a non-ambiguous formal grammar. In this proposed web, if a page does not conform to the specification, the client is forbidden from rendering it.
By rejecting the "robustness principle" (the idea that a parser should be liberal in what it accepts), the goal is to simplify parsers and force authors to use cleaner languages—potentially moving toward Markdown for content creation while maintaining a strict underlying transport format.
4. The Removal of Scripting
Mallo asserts that adding scripting capabilities to the web was a fundamental mistake. In his vision, interactivity is handled by the OS or specialized clients via open protocols (such as Geo links for maps) rather than embedded JavaScript. This shifts the burden of optimization from a "one size fits all" web page to native programs optimized for specific devices.
The Counter-Argument: The "XHTML Debacle"
The proposal has sparked significant debate, particularly regarding the insistence on strict grammar. Many critics point to the failure of XHTML as a cautionary tale.
"This is what XHTML was, and it was a complete disaster... getting a 'parser error' is always worse than getting a page that 99% works," notes user @TazeTSchnitzel.
Critics argue that the web's greatest value lies in its resilience—the fact that broken, decades-old sites remain readable. A strict-grammar approach would effectively erase a vast portion of the existing web's history, rendering it inaccessible to any compliant browser.
The Application vs. Document Divide
A recurring theme in the discussion is the tension between the web as a document and the web as an application. Some contributors suggest that the problem isn't the existence of scripting, but the lack of separation between these two layers.
User @hypendev argues that the modern web is a "giant mess" because it tries to be both. They suggest a clear architectural divide where the UI language is separated from the application code, preventing the "kafkaesque" complexity of current web development. Others suggest that the solution isn't a new web, but a return to protocols like Gemini, which are designed from the ground up to be non-executable and secure.
The Economic and Practical Reality
Beyond the technical merits, the discussion highlights the systemic forces that drive web complexity. Mallo notes that monopolistic entities have an incentive to "capture the standard," increasing complexity to raise the barrier to entry for competitors.
However, skeptics argue that the very things that make the modern web "bloated"—JavaScript, complex APIs, and tracking—are exactly what make it profitable for the companies that maintain the infrastructure. As user @1vuio0pswjnm7 points out, a no-script web would be "dead on arrival" for the tech industry because it would dismantle the mechanisms of surveillance and advertising that fuel the current internet economy.
Conclusion
Forking the web is a romantic and technically appealing idea for those who miss the era of the "small web." While the practical hurdles—network effects, the necessity of interactive apps, and the legacy of the XHTML failure—are immense, the proposal serves as a critical reminder of what has been lost: a web that was a collection of documents, rather than a collection of platforms.