This is the collected form of a thread I initially brainstormed on the Fediverse, with the introduction taken mostly from this other commment thread of mine.

Introduction

There has been a lot of noise recently concerning Mozilla's choices about where to take their Firefox browser, especially in view of their choice to go all-in on “AI” even against a largely negative feedback from the community. While some have defended, or at least found a justification of this choice based on “market” consideration («people want AI»), many (among which myself) remain unconvinced, for several reasons.

I have listed a few, ranging from the low market share of and making it hard to digest any claims about the credibility of an “educational” intent for the adoption (particularly since they fired their advocacy dvision) to their insistence on holding onto the idea even when this aliented their entire volunteer Japanese localization team —something that a “public benefit” corporation that claims to be consistently low on resources should be extremely wary of doing.

In general, Mozilla has been shown to be extremely unreceptive to feedback from its community in general, possibly unaware of the fact that the selected few that still hold on to Firefox as their primary browsers are largely people who care about the open web first and foremost, and feel deeply betrayed by the last decade plus of decisions made at Mozilla that do little more than paying lip service to the principles of the open web, while in practice assisting in dismantling it. And it's impossible to know, without insider knowledge, if their management is simply obtusely incapable of understanding their precarious position, under threat of seeing their advertisement funding cut off by Google if they don't comply (or just realise ad revenue won't be there forever), or simply trusting that people have nowhere else to go. What are disgruntled Firefox users going to switch to, after all? Google Chrome? Ah, please.

As @rysiek​@mstdn.social puts it,

Mozilla is the browser vendor equivalent of centrist political parties.

or rather, as I would put it, the “center-left” parties, whose “moderate” positions simply help shift the Overton window to the right, normalizing positions that are antithetical to their own existence, in a futile effort to pursue an (electoral, or user) base that would never vote for them anyway.

And not only recent political events such as Zohran Mamdani's election to mayor of New York City show how successful even just a moderate push to the left can be: to make things even worse for Mozilla, switching to minority browsers is actually much easier and effective than voting for minority parties in political elections.

The net result of this hard-headed decisions at Mozilla has been that long-time Firefox users have been looking harder at alternatives.

@mcc​@mastodon.social, like many others, have been promoting Servo, the experimental browser initially developed by Mozilla and then discarded by firing the entire team working on it, and now reborn as an independent project.

Supporting is an excellent idea, if not else because its survival increases the number of independent browser engines in active development. But Servo is not yet viable as a primary choice: performance is abysmal, standards support is low, and user interface is featureless and unstable. People wanting to start looking at options now will have to look elsewhere (this is, of course, orthogonal to any support one may give to the Servo project). The only currently viable alternatives to Firefox that aren't just skins around the or rendering engines are Firefox forks (Fireforks?)

As I have already mentioned, there are mainly three active Firefox forks that may fit the needs of users abandoning Firefox out of concern for the direction its development is taking: LibreWolf, WaterFox and Pale Moon. And of these, the first two ( and ) are basically just “Firefox without the most egregious privacy-invasive misfeatures”, which leaves the question open about their viability if Firefox goes under —in fact, the LibreWolf developers have clearly stated that they won't be able to hard-fork and go their own way. with its rendering engine is thus the only currently viable alternative that has shown it can exist and grow independently from Firefox.

And so I've been pondering: what is really needed of a web browser? We know that implementing one from scratch is a titanical challenge. But is that also true of maintaining an existing one?

To answer that, we should first stop and consider what is a browser, and what is the World Wide Web. And the interesting part is that we're currently in a process of “speciation”, if I may borrow a term from evolutionary biology.

A tale of two Webs

The World Wide Web was born with the intent to achieve an interconnected web of documents (or, more in general, resources that may include things like images or other multimedia elements): and this is not only what it was in the beginning, but also what most of the open, independent web still is, even when it's more dynamically generated (wikis, blogs).

What we've seen under the moniker of “Web 2.0” in the last 20+ years, but especially in the last decade, has been the development of a different interpretation of the Web.

Major corporations saw in the “Web 2.0” the opportunity to leverage this communication channel as a means to deliver services to the users, or, a rose by any other name, as a way to write cross-platform application front-ends.

This isn't exactly news to anyone who has been using the web more than a decade, but I think it's quite important to stress this again: the modern web features both kinds of websites: document repositories, and application front-ends (“web apps”).

And web browsers are used to access both kinds of websites, but —and this is extremely important— the two kinds of websites have very different requirements. For example, the V8 engine that powers Chrome was specifically designed to improve the quality of service of web apps, and while the “web of documents” can at times benefit from said improvements, it doesn't have particular needs in this regard, except maybe to compensate for the deficiency of other components (especially )

A lot of the development efforts (both creative and destructive) in web browsers in the last decade+ has been going into fostering the “web app” vision of the web, to the detriment of the “web of documents” vision. From the removal of native support for and feeds to the introduction of JavaScript APIs like WebUSB or the Web Environment Integrity attempt I already discussed in the past, nearly all work done on browsers has been in this direction.

This difference isn't just a matter of feature sets; in fact, it's primarily a matter of design principles.

A browser for the “web of documents” is a User Agent: it's a tool in the hands of users, designed to maximize the usability of said documents.

A browser for the “web of apps” is a Corporate Agent: it's a tool in the hands of corporations, designed to maximize the control they have on the user machine.

One can obviously see how this reflects in the development of Chrome with the removal of features that are unnecessary or, even worse, detrimental to corporate interests (the most famous recent such change being the introduction of the so-called Manifest v3 for WebExtensions to kill ad blockers), but you can also see it in Firefox development when their “listening to the community” means doubling down on shoving unwanted (aka genAI/LLM) everywhere and dropping support for .

Under this analysis, browsers like Vivaldi are in a very precarious situation: on the one hand, the browser is being developed under what is arguably a “web of documents” mindset, and in fact more in general as a “Swiss knife of the Internet”, (similarly to the classic Opera browser, as I've already written about at length). On the other hand, its reliance on the Google-controlled Blink engine that is designed for the “web of apps” cripples it in its efforts: while they've been able to reintroduce native RSS and Atom support, Vivaldi doesn't support JPEG XL because Blink has removed support for it (although things seem to be changing on that front), and will have no choice but to drop XSLT support following Chrome's timeline, unless its developers finally decide to put in the development effort themselves. The same holds for any other browser that depends on Blink, WebKit and soon even Gecko. This will make all of them less of a User Agent and more of Corporate Agents infiltrated in our machines.

So, it's time to realize that the “web of documents” and “web of apps” are two completely different beasts, only incidentally related to each other, and that it might not even make sense to waste efforts in developing tools that support both equally well. This means, in particular, that we may have to make peace with the fact that one browser might not be enough: we will need two of them.

For me, this is already the case, by the way: although Firefox is my primary browser, I still have to resort to Chromium from time to time, either because some websites simply refuse to work correctly in Firefox, or because it's the only way to ensure a solid “separation of concerns” (unsurprisingly, what I use Chromium for is the more corporate-y stuff.) And even without asking, I'm sure I'm not the only one. (From the poll I'm running on the Fediverse, over 40% of the respondents at the time of this writing use a separate browser for some corporate site, and less than 30% use the same browser for everything without any separation.)

In this sense, the question «are LibreWolf/WaterFox viable if Firefox goes down» becomes less important: Pale Moon has shown that a viable alternative at least for the “web of documents” is in fact possible (and it exists already). So the question would rather be «will we have a viable alternative to corporate browsers (Chrome, Safari) for the “web of apps”?»

I think the answer is yes: even if LibreWolf and WaterFox wouldn't be able to survive or keep up to date with evolving standards without their reliance on Firefox, we will likely still have Blink- and WebKit-based browsers around to work as “slightly less shitty corporate agents” to browse the “web of apps” —at least as long as Blink and/or WebKit remain open source.

If anything, the biggest issue would be that, since the “web of documents” and the “web of apps” use the same protocol, as the two diverse it will be come harder to switch from one to the other during a browsing session.

In this sense, the Gemini protocol folks have arguably had the right idea: “we'll make our own web, with simple text and image formats”. This, to steal @witchescauldron​@kolektiva.social's expression, pushes the “web of documents” away from the “web of apps”, and solves the issue by making it apparent that “the two webs” are completely different from each other.

But as I've already mentioned elsewhere, the Gemini protocol approach, in my opinion, throws away the baby with the bathwater. Many of the web formats and technologies are actually extremely useful even for the “web of documents”: the problem isn't with , , , , or even , the problem is that browsers have been catering exclusively to the “web of apps”, neglecting (when not outright obstructing) the “web of documents”. We can keep that tech and the “web of documents”.

The good old, classic Opera/Presto had an interesting approach here: since it couldn't guarantee, despite all efforts, perfect compatibility with websites that weren't designed around web standards but “for specific browsers”, it provided a menu option to open in a different browser any page you were in. I don't think I've seen such a feature in any other browser (apparently there were extensions for it), but I think it's actually the simplest solution to the diverging paths for the two webs.

(This is actually a feature that all browsers should have, regardless of the “apps vs documents” thing, and while I can understand why the major ones won't, I hope to see all others adopt it.)

If we accept that the “web of apps” and “web of documents” are two separate things, and that the development and maintenance of the browsers for the “web of apps” is essentially left in corporate hands, what is left is the question: how expensive is it to develop and maintain the browsers for the “web of documents”?

And I suspect that the answer is “much less” (than the “web of apps”).

For starters, most of what the WHATWG is working on is largely irrelevant for the “web of documents”. This means largely no development efforts is needed in “web of documents” browsers to “run after the latest revision of the spec”. I would expect most of the work to be of the maintenance kind (fixing bugs, security issues, and the like), which is sadly the kind of brutal, unglamorous work nobody wants to do.

Some new work to support more recent revisions of “document-useful” standards like CSS may be needed: this is a much slower process, although it can be quite complex.

It will be interesting to see, as the consciousness of the divergence of the “web of apps” from the “web of documents” grows and matures, how this will reflect on the adoption of new features by website developers in the face of graceful degradation.

My guess would be that “web of apps” developers will gladly throw themselves at new features as soon as it's “all green” on CanIUse (which I don't expect will monitor “web of documents” browsers: even now it doesn't feature minority browsers like Pale Moon or Vivaldi), while I expect “web of documents” developer to be more cautious in their approach: there's a reason why a gardening metaphor is often used for the independent web.

Just to be clear, I'm not saying that maintaining a “web of documents” browser would be effortless, or that it can be supported just by the kind of “amateur coder in their spare time” work that stereotypically underlies development (see also @glipari​@sciences.re's comment thread here).

In fact, if anything, specifically because the main work needed is the kind of unglamorous work that most developers dislike (bug fixing and the like), it's going to be even less likely to find the flock enthusiasts that volunteer their time on it for free. So this aspect does not, in any way, eliminate the need to find a way to support the developers of such a browser.

(By the way, while it's true that, as @glipari points out, browser development for the “web of apps” is motivated by the money it brings in, this doesn't necessarily explain why the “web of documents” gets not only neglected but in fact actively crippled. There seems to be indeed a lot of effort going into developing the “web of apps” in such a way that is specifically goes against the “web of documents, even when we have solutions, sometimes existing solutions, that can serve both.)

This is why it is important to fund projects that maintain and develop these browsers (although for example I would like to have from the Servo team a clear statement about the kind of browser that they want to be; it may not matter now as they are still quite far behind in terms of standards support, but it will matter soon, if not else in terms of what to prioritize, and it would be nice to know that we aren't throwing money at the next Firefox, down the enshittification drain).

(And no, don't expect me to propose a solution for the funding problem. I don't have one, unless we finally get Universal Basic Income everywhere, but that's a whole different topic of discussion.)

A wishlist for the “web of documents” browsers

Let's pretend for a moment we have solved the funding problems. In this case, I would love a “web of documents” browser to go beyond.

For example, such a browser would support the Gemini protocol just as well as HTTP. It would support the text/gemini format just as well as text/html —and why not, also text/markdown (yes, it's official) and text/asciidoc (registration pending).

It would have native support for feed discovery and for the RSS and Atom XML formats. It would support the multi-document navigation metadata that enjoyed a brief moment of glory in the early aughts and support for which currently only survives, AFAIK, in the Pale Moon Website Navigation Bar plugin, and it would support the HTML+SMIL profile that only briefly existed in an ancient IE experiment.

It would support XSLT 3 (and 4, when it comes out), and XQuery as a scripting (or more appropriately templating) language. It would support XHTML2 (seriously, have you read the spec? It's so much better than HTML in so many ways it's ridiculous what we've been deprived of; even with a dislike for XML Events and XForms, which is the “web for apps” part, there's no justification for throwing away the rest).

And of course, it would support “any” multimedia format (one of these days I will bring to this site the brainstorming I had about how to achieve this, and hopefully I'll remember to link it here).

But that's enough daydreaming.
Let's start from what we have.