Why a clean start for the web wont solve the problem
After reading Tom MacWright’s article on “A Clean Start for the Web”, I felt compelled to critique his plan, despite sharing concerns about the current state of the web.
The Monoculture of Browsers
Tom’s initial argument is driven by the recent layoffs at Mozilla, highlighting that this leaves a monoculture of Blink and WebKit browsers developed by major corporations. This situation raises concerns about the diversity and sustainability of web technologies.
The Document Web vs. The Application Web
The author suggests that the web can be divided into two categories: the Document Web and the Application Web. The use of tools designed for building application websites on document websites has led to a range of issues, including bloat and accessibility problems.
As such, the proposed solution is to split the web into two distinct parts. The Document Web would operate on a standardized markup language like Markdown, while the Application Web might utilize WebAssembly.
The Document and Application Dichotomy
Tom’s suggestion to separate the Document Web and the Application Web implies that the two are equal or at least comparable. However, the reality is that the majority of the web is heavily “app-like,” with 80% of all internet traffic consumed by videos, gaming, and social media1.
Even if a successful Document Web solution were to emerge, users would likely spend most of their time on the Application Web. The stronger network effects and more powerful capabilities of the Application Web would likely attract publishers to place their content there as well.
The Gopher protocol, released in mid-1991, meets many of the author’s Document Web requirements. It features a simple syntax and allows for search and linking. However, there are numerous reasons and nuances explaining its failure to compete with the World Wide Web, one of which is its limited extensibility2.
It is likely that another attempt at creating a Document Web would face a similar fate, especially since the standards for documents have only risen since then.
Why the Web is Slow
Technologically, a strict Document Web, as Robert O’Callahan, a former distinguished engineer at Mozilla, points out, is unlikely to outperform modern web browsers. If modern browsers are already so well optimized, why does the web still feel slow?
Slow sites result from misaligned economic incentives; no one builds sites to be intentionally slow. As the majority of internet traffic flows to major players due to network effects, other websites must compete fiercely for the remaining audience.
Website maintenance is not free, and charging for services on the web can be cumbersome. Consequently, many document sites resort to displaying ads to remain sustainable. This leads to heavy JavaScript bundles that either add advertising, track users, or engage users to increase sales.
On the application side, since heavy JavaScript bundles primarily impact the initial load, optimizing for this metric is often deprioritized in favor of adding more features to the app. Application developers tend to focus more on optimizing runtime performance, which is significantly more challenging. In this context, I foresee WebAssembly playing a larger role in the future.
Looking Beyond the Web
Tom’s arguments also raise the question of why browsers are becoming increasingly complex. The proliferation of new web standards is not merely a matter of internal competition; the web is also competing with mobile apps, and mobile apps are winning.
The majority of internet traffic now originates from mobile devices, with only 10-17% of users actively browsing the web on these devices3. Steve Jobs’ initial vision for the iPhone was to run only web apps. Unfortunately, the web’s performance and limited capabilities at the time had to yield to native mobile apps.
This performance gap persists because most phones on the market still have low single-core clock speeds. As a result, Android and iOS feel more fluid, as they perform UI work in a delegated thread, while most web apps operate entirely in the main thread.
Moreover, mobile apps offer capabilities like native notifications, which enhance user engagement and value, prompting many companies to encourage web users to switch to their mobile apps.
Without similar capabilities, mobile web usage is likely to continue its decline. A stagnating web standard would not benefit the web, as it would allow the next platform to surpass the web’s position as the dominant platform. This is why browser vendors are continually pressured to implement new features.
In essence, the browser has become as complex as an operating system because it is competing with operating systems.
Browser Monoculture and Open Source Sustainability
Let’s return to the main issue: browser monoculture, which is not unique to the web. This has always been a concern with platforms in general.
On the desktop side, the market is predominantly controlled by Windows and macOS.
On the mobile side, we have Android and iOS.
On the browser side, we currently have Chromium and WebKit browsers.
The dominance of FAANG companies and Microsoft allows them to provide platforms for free and dictate the rules governing them. This is likely why many perceive the monoculture surrounding browsers as dangerous and why they lean towards open source. Unfortunately, open-source platforms have historically struggled with funding to sustain engineering efforts. This challenge is exacerbated by competition with free products. Mozilla has been remarkably resilient in surviving and competing with tech giants for so long. An open-sourced clean start would face the same challenges and would likely have a smaller consumer base to draw from.
Thus, Mozilla’s plan to focus on profitability makes a great deal of sense. By first addressing the monetization issue, they can continue to contribute to building a healthier internet. They face a significant challenge ahead, but I wish them luck.