13 min read | 3712 words | 25 views | 0 comments
Flexibility is the greatest strength of the web. It's also its greatest weakness.
The web has come a long way since Tim Berners-Lee invented it back in 1989. Today, much of the content users interact with regularly is dynamic and interactive (often referred to as "Web 2.0"). This has paved the way for web developers to be able to provide application-like experiences from within the web browser.
HTTP itself hasn't changed significantly in the past couple decades, and it hasn't needed to, since Web 2.0 is a function of modern graphical web browsers, not the HTTP protocol itself. Although HTTP is an application-layer protocol (at the top of the OSI or TCP/IP models), I find that it's often useful to think of the browser DOM itself (controlled using HTML, CSS, and JavaScript) as being an additional layer on top of HTTP, which is just the protocol used to deliver the code. The implications of this are interesting — for example, line-mode browsers (e.g. Lynx) are perfectly compliant and valid HTTP clients (much like curl is), but they can't be used to interact with much of the modern web, which expects a graphical browser capable of interactivity. Furthermore, strictly coupling the web to HTTP directly seems wrong — most web browsers have traditionally supported FTP, for example, and in theory, a modern website could be built using a collection of interlinked FTP resources.
If you think about it, this is rather unusual. No other application layer protocol widely used today is like this. For example, consider IMAP, a widely used mail access protocol. There are some parallels in the IMAP ecosystem to HTTP, especially if we look at the Mozilla family of mail clients (the most popular of which is Thunderbird). The Mozilla mail clients effectively have an embedded web browser in them, making heavy use of JavaScript for rendering in the user interface. This is plainly obvious when using RSS feeds, where a Mozilla-based browser is used when reading an article. Reading HTML emails also requires the facility of effectively a full-blown web browser. Of course, not all mail clients support this functionality, but Mozilla clients are fairly feature-rich.
Even though JavaScript can be found in both web browsers and mail clients, there is a big difference between the two — in the browser, the developers of any of the content you consume (the pages you visit) can directly ship JavaScript into your browser that it will then try to execute. In the Mozilla suite of mail clients, JavaScript is used to build part of the mail client itself (much of it is also written in C++), but even HTML emails don't entail JavaScript execution within the mail client.
There are many implications of this distinction, some obvious and others more profound. We don't access rich, interactive applications in our mail client. In theory, a mail client is capable of retrieiving what is effectively a web page via IMAP and could theoretically execute it. For many reasons, mail clients don't do this. Web browsers, in contrast, do exactly this, albeit using HTTP to receive the JavaScript, rather than IMAP, although as mentioned, in theory this could also be FTP or some other protocol supported by the browser.
The more profound revelation here is that merely a compliant HTTP client is no longer sufficient for interacting with most resources delivered over HTTP, which happen to be rich, interactive webpages that require a full, graphical web browser, not just an HTTP client. This is what truly sets the web apart from other ecosystems — for example, emails, even HTML emails, are generally well-structured and well-defined enough that a rich variety of tools can interact with them. For better or worse, there is a lot of automation that exists around email. In contrast, think about automation tools when it comes to the web. For simpler tasks, tools like wget or curl can be used on their own to retrieve the content desired, perhaps with some minimal parsing afterwards. Many pages may require XML pages in order to parse the returned HTML — a task which is sometimes annoying, but generally possible. More complex are pages that expect a graphical web browser that can execute JavaScript, a problem which has given birth to a whole host of graphical web-driving tools, like Selenium. Can you imagine having to do this for, say, email automation? Gross!
Herein lies the paradox of the modern web: it allows developers to create increasingly rich and interactive experiences that they can ship to their end users; conversely, its enormous complexity makes it extremely hostile to users or clients that want to be able to interact with the web on their own terms. Continuing with the email analogy, IMAP is the equivalent to HTTP and MIME is generally the equivalent to the DOM when it comes to the structure of an email (or a webpage). While parsing MIME is hardly trivial, it is very well-defined, and there are a number of tools that have already solved this problem, meaning that it's fairly straightforward to write new IMAP clients and use existing MIME libraries to interact with pretty much any email out there. No such tool exists for the web. If you decide, for example, that you want to extract some piece of information from a webpage that you frequent, there may not be any easy way to do this, thanks to JavaScript. Your web browser can handle this easily, but your web scraper probably can't, particularly if the site was designed in a manner that either didn't consider or was actively hostile to this use case.
HTTP clients are fairly easy for any good developer to write. Not so for web browsers — today, they are among the most complicated pieces of software created by man. Chromium, the base of the most widely used browsers today, is over 35 million lines of code. This is roughly as large as the entire Linux kernel project.
What has this complexity brought us? Many of the aforementioned interactive applications, certainly, but also most of the broken user experiences that exist in computing today. The "DOM layer" (or Layer 8 in our hypothetical "expanded OSI model for browsers") is an ever-changing landscape, always in flux, with new web standards, particularly JavaScript standards, coming out regularly. This wreaks havoc on compatibility — web browsers, more than any other software, become obsolete in a matter of years, if not months. Of course, that's completely ignoring security — it seems that new patches are constantly being releases for "critical vulnerabilities" in commonly used web browsers. In fact, Google Chrome has had the most CVEs of any software that isn't an operating system (in fact, it's had significantly more CVEs than many operating systems).
What this means is that a user who doesn't update his web browser will soon find that many things will no longer work for him. Software updates are not always innocent (the general "enshittification" of software today broadly demonstrates this). While security updates in and of themselves may be good, it's not always practical for software everywhere to get updated, and it's not realistic to think that it is. Vendors may also choose to stop supporting certain platforms, as Google has done with Windows 7, for example. Chrome 109 is the latest version of Chrome officially available for Windows 7; there are third-party forks like Supermium that backport changes to a fork supporting older OSes, but these, too, have their own issues). Software is very opinionated. People are picky. Vendors are not necessarily in the wrong for dropping support for lesser-used OSes, but if you believe, as I do, in user choice, and the right of users to use the software of their choice, then users are not in the wrong, either.
The plight of users on the web is an interesting edge case. By and large, most of today's software is fairly mature. I would posit that there have been no significant material improvements in most commonly used applications in fifteen years now. Windows 7, for example, does everything a modern operating system would be expected to do, in many ways better than the versions that succeeded it. Office 2010 is compatible with documents created by Office 365, with a less barf-inducing UI. Old versions of Acrobat read PDFs just as well as the current one (and without the UI getting in your way, I might add). Old Mozilla mail clients, even abandoned or hardly-maintained forks, are still capable of reading email — it's not like email has somehow changed. Old versions of 7-Zip can be used to decrypt archives, it's not like the 7-Zip format has changed. The Telnet client in Windows 2000 is still capable of connecting to a Telnet server, it's not like Telnet itself has changed. The counterexample that proves the exception, fire up any web browser that's more than a few years old, and watch it barf spectacularly on any number of modern websites, even seemingly benign ones like, say, GitHub. As a society, we are simply accustomed to updating our web browsers constantly, almost religiously, because that is simply what one does with a web browser, despite this being atypical for virtually every other piece of software we use regularly today.
Why is this? It's because the web continues to evolve in ways that are often not backwards-compatible with old browsers, something that is generally avoided in most other standards and protocols. Many protocols, like IMAP, for example, evolve slowly through new RFCs or independent extensions that are sometimes later finalized in communities like IETF working groups. In contrast, the web is more like the wild west, with new "standards" being invented left and right, often from companies that hold significant browser market share, like Google.
To put it bluntly, in many cases, the web is evolving purely for the sake of change. New standards are often invented that yield minor improvements at best, while rendering all existing web browsers immediately obsolete and incompatible, as was the case with the nullish coalescing and optional chaining operators. As sites employ these newfangled capabilities, users of minority platforms begin to find many things are now broken. GitHub is a great example of this. Rather than improving the site or making it more usable, it seems their engineers are tasked chiefly with implementing JavaScript changes that break the site in subtle or major ways for older browsers (or really, anything that isn't N or N-1 Chromium). In the case of GitHub, it's especially given ironic, given their supposed goal of fostering innovation and the development of new software, an ideal which is in complete antithesis to breaking the website for non-dominant platforms.
In many ways, what's old is new again. During the original browser wars, browser vendors employed proprietary markup, styling, and scripting capabilities that frequently led to many sites only work in certain browsers. Although today, we pretend that everything is now "well standardized", we have effectively returned to this earlier time, where once again, a large number of sites only work in a small handful of browsers.
A Tangent About User Agents
On the web, there is an entire practice centering around detecting browser version and, in many cases, actively blocking users of "undesirable" browsers — again, a practice virtually unheard of elsewhere. (When's the last time you sent an email only to have it bounce as follows: "Your email client is too old and you have been blocked from sending emails to our users. Please upgrade your mail client and try again." Can you imagine if email were as horrible as the web?) Yet, this is exactly what Slack does when you try to visit its website, something Windows 7 users are coerced into doing since the Slack application doesn't support it anymore. Although I find Slack and Electron web apps in general to suck, I do occasionally visit them in the browser for certain projects, only to be greeted with a banner that my browser isn't supported, even though it works perfectly fine. Spoofing my browser version as Chrome 209 (a single-digit change from Chrome 109) works around this — annoying, and I like to think I'm perturbing Slack's browser usage statistics, though I'm not so conceited as to think a few actions like this will actually make them change. This is a good example of what not to do as a web developer though — if you're going to block a browser, at least do it based on actual browser functionality, rather than on something so arbitrary as the user agent. But really, the fact that we have to deal with browser blocking at all just demonstrates how fickle the modern web has become.
Even though Google has been making efforts to get rid of user agents[1], of late, many sites have been doing this more, rather than less frequently. An example of this is Chris Siebenmann's blog, which initially blocked me when I try to view an article in Chrome 109 (though not Supermium, New Moon, or Internet Explorer). He was gracious enough to fix this, and I had some empathy for the ongoing battle with LLMs (yet another enshittifying technology that is exacerbating the enshittification of existing technologies) that he and many other webmasters are dealing with. As it is, there are a couple possible ways of trying to block LLMs (bad and worse): using user agent blocks or obfuscating JavaScript, both of which, Siebenmann rightly points out, will harm innocent users. His approach has been somewhat aggressive while incorporating feedback, an example of how to good by your users. On the other extreme are people like Jamie Zawinski, well-known for his early role in Mozilla and for having created the "threading algorithm" widely used in email today. His website now intercepts pretty much all third-party browsers with IF YOU ARE NOT A ROBOT, UPGRADE YOUR OUTDATED SYSTEM SO THAT YOU STOP LOOKING LIKE A BOTNET OR A BULK DOWNLOADER. After politely attempting to point this out to him, as I had to Siebenmann, he responded:
NT 6.1 was released in 2009 and is used almost exclusively by botnets. Your fetish for using jurassic Microsoft systems is a you problem, not a me problem.
Okay, so Zawinski is also a well-known asshole (much like many a technocrat). What's a bit sad in hindsight is Zawinski used to be an advocate for free software, an ideal which, while not entirely the same as "user choice", is very similar. In any case, he seems to have since changed his mind about user empowerment.
These practice of explicitly blocking "undesirable" browsers, whether for legitimate or frivilous reasons, are actively hostile to users of minority platforms. This is something I pondered if it was the right way to word this, but I believe it is correct. Chris Siebenmann makes an interesting argument that web browsers are an enabler of minority platforms. I think he has a point that is partially valid, but I think it's incomplete, and the reality is more nuanced. More accurate would be to say that web browsers enable majority minority operating systems, and tend to suppress minority browsers. Sounds fancy, but really, it's quite simple. Siebenmann was making the argument that Linux, as a minority OS, rarely receives the investment by vendors to make dedicated applications for. However, major browsers are released for Linux distros, hence enabling users of current Linux distros — hence "majority" (current, i.e. users that stay up to date with browser updates) "minority" (Linux) systems. In contrast, Windows 7 users are now generally in the minority as far as updates and platforms are concerned — "minority minority" users, if you will, though really that can just be simplified to minority users. As the modern web tends to involve incompatibilities as a rule, rather than an exception, even if for no good reason, minority platforms tend to suffer under this regime, and "majority minorities" (not too dissimilar to the concept of "model minorities") are really just an exception that prove this rule. So, to the extent that majority minorities are just a form of majority as much as they are a form of minority, I think the web does a great deal more to enable majority platforms than it does minority ones. (And Siebenmann himself acknowledges that this can be a challenge on "sufficiently minority platforms", as are increasingly common today, especially given the wider tail of Windows versions and browser versions in use than ever before.)
This is a real threat to third-party browsers, many of which are "free-thinking" software projects like Pale Moon, which march to the beat of their own drum and have what borders on being a cult following. Having spent my fair share of time lurking in these sorts of communities over the years, I've noticed a trend in the userbase of these kinds of third-party software projects, a large number of which are forks of old Mozilla software. Most literally, they are dissatisfied with the user interface and experience of the newer "Big 2" browsers, but it's much more than that. They are "free thinking" users who believe in user choice and don't like the way that enshittification has ruined most contemporary software. They believe that software should be evaluated by the quality of the user experience it provides, not how "new" or "shiny" it is. They believe software should empower the user, whether directly (as in direct browser controls) or indirectly (as in traditional browser extensions that a user may wish to use[2]). And they certainly won't be told by Google or Mozilla or the other browsers that be what software they should be using! (The same principles apply for non-browser software as well, for example to forks of Thunderbird.)
Third-party browser or not, much of the web today is, no doubt, overly bloated, chiefly enabled by browsers enabling the release of huge amounts of sloppy JavaScript on the masses and cultivating a culture where JavaScript must not be merely tolerated, but is often required for common tasks. In many cases, such JavaScript does not execute correctly in third-party browsers, causing sites to malfunction as JavaScript continues to evolve for no real reason. Users, of course, are used to being told that, if something doesn't work in one browser, they should simply try again in another one. We are now accustomed to trying a website in two, three, four, even five different browsers to see if it will work in any of them. It's a horrible user experience, and one that just doesn't exist in any other facet of user computing today. Imagine having to use four email clients to read your email, because some emails would cause some of your mail clients to crash. Who would put up with that? Nobody! But on the web, this is merely normal.
Unfortunately, there are no signs that this kind of exclusionary behavior is slowing down. Companies like Google like to pay lip service to open source, but in fact, have done quite a lot to hamper open-source browser projects and browser freedom in general, as is evidenced by their stance on DRM, which is hostile to the point of encouraging piracy[3]. In theory, you can use any browser you want, but in practice, Google goes to extreme lengths to make sure it's one of theirs.
A Bleak Future?
Altogether, this has resulted in the web feeling somewhat aggrivating to deal with on a regular basis. Between JavaScript bloat and breakage, many websites seem designed to be actively hostile to their users. While this has ushered in the flexibility that exists in today's web, it's a double-edged sword in that experiences that were allegedly supposed to make things "easier" often seem to make things "harder". While it's possible to pull off "Web 2.0" correctly, it seems there are a fewer web developers that actually know how to design proper, accessible websites, a problem that will likely only get worse as more things become "AI-hindered". These days, it's almost refreshing to see "Web 1.0" content — simple, static HTML, maybe some CSS, and no JavaScript to speak of — 100% crap free. You don't have to worry about compatibility, because incompatibility is largely a problem created by JavaScript. Virtually any competent HTTP client will be able to interact with your site, and DOM parsing is structured in well-defined ways.
Over time, the web has morphed from a document retrieval system into a medium to try to do "everything" (or almost everything) we do online. It has become, as the saying goes, a jack of all trades, master of none. More than that, it has succeeded in make things easier and more efficient for some people, while making things more contrived, if not downright difficult, for others, particularly as many people are now expected to do many common tasks online. "Enshittification" isn't inevitable though, even in the case of the web, and even in the case of JavaScript — while the web has a history and tendency to go rogue, it doesn't have to be that way, and web developers continue to have a responsibility to, well, "develop responsibly". These days, the web rarely feels like a good end user application experience — adequate at best, and downright horrible at worst. Let's do better. As we do in most applications outside of the web, prioritize compatibility, and if given the choice between prioritizing developer experience and user experience, the latter is the right choice every time.
[1] While presented with the veil of preserving privacy, the actual implementation of user agent reduction by Google is another threat to minority platforms, such as Windows 7. Google essentially doesn't care about legacy platforms, and has now actively crippled the user agent by making it report inaccurate operating system versions, a far cry from anything to do with privacy. For this reason, Supermium on Windows 7 currently uses a Windows 10 user agent, a problem that has been pointed out to its developer. The effect of Google's move is for user agent data to exaggerate the usage share of supported platforms (e.g. Windows 10) and underestimate the usage share of unsupported platforms (e.g. Windows 7), feeding into the false narrative that such platforms are seldom used.
[2] Both Google and Mozilla have moved towards crippling browser extensions in their browser ecosystems.
[3] win32ss said it best: The use of VMP signing, streaming discriminates against browser users in ways that other forms of media do not and effectively discourages the use of legal methods of obtaining content.
Log in to leave a comment!