There's a number of reasons, but one of the biggest is that it's impractical for an individual or small group to create a web engine that is capable enough that users will want to use it. This means the only options are to either fork an existing browser (as most Chromium forks are doing) or build a browser around an embeddable engine (as WebKit-based browsers do, and hopefully one day Servo-based browsers will).
For many interested in creating a browser, a new engine is one of the primary reasons for doing so, and so forking or embedding being the only option means that many who would've created a new browser don't, because from their perspective there's no point in a Chrome/Firefox/Safari clone with a slightly different coat of paint.
WebKit at least partially addresses the clone issue, making it easy for developers to write entirely new UI code using their toolkit of choice, but comes with the caveat of not receiving much attention on non-Apple platforms, which is a problem with browser security being so important.
Also, saying 'Chromium fork' is mostly untrue since these browsers almost always change stuff that's required (ie. changing the appearance, logos, chrome:// uri, and maybe solving some platform-specific bugs) then continue to pull changes from upstream Chromium with little intent to iterate on the core components of the browser or implement new standards. Brave is the one exception with IPFS support but that's it - not even MSFT did something like enabling PlayReady in chromium, it's straight widevine.
Much of the media playback IP is tied up by the big players. Who wants a browser without media playback?
Aside from that, how do you make money on a web browser? Without some kind of payback, it's pretty unlikely a browser project will get funding. Particularly since there are decent browsers on all platforms already.
Opera was originally based on the Presto layout engine from 1995-2013. Then it switched to being a Chromium based browser in 2013 so they could utilize the Chromium plug-in ecosystem.
The ecosystem is the big issue for a lot of these products. It why Microsoft's Windows phone failed so badly - they didn't have the app store to compete with or allow users to migrate to their platform without losing a lot of apps they already used on Apple or Android.
The ecosystem is a major reason why you don't see more competition.
> Then it switched to being a Chromium based browser in 2013 so they could utilize the Chromium plug-in ecosystem.
Opera switched to Chromium because they didn't consider it profitable enough to keep developing their own engine, and laid off a large portion of their browser developers. It was entirely about money and nothing to do with using Chrome extensions.
Google basically controls the "standards" now, and it has the resources to keep churning them endlessly while spreading propaganda about how much better the new features are and how everyone should use them --- because they're only implemented in its browser.
There are perfectly capable HTML4-level browsers like Dillo, NetSurf, etc. and a bunch of similar projects on GitHub (under elaborate yet non-browser descriptions such as "HTML viewer with CSS support".) If only people would stop drinking the Goog-aid and unnecessarily "app-ifying" sites, maybe we would have more browser diversity... after all, the majority of sites I use are from the "document web" and not the "application web".
Edit: downvoted for talking against Google, interesting...
Looking at the holistic picture (as anyone implementing an entire browser must), it's probably a stretch to say they're "designed" at all – web standards are a patchwork of almost archaeological layers built up over several decades. Even many deprecated bits must still be implemented to support the millions of websites users will want to visit. Backwards compatibility is hard :-/
This has never been true. We wouldn't have JavaScript if Netscape didn't go off and do their own thing. Netscape and Microsoft were locked in a fierce embrace-and-extend battle for the web. XMLHttpRequest wasn't even a standard when Gmail came out in 2004, and wasn't a standard until at least 2006.
Web standards merely describe the current world of web browsers and attempt to retroactively take credit for it.
>Web standards merely describe the current world of web browsers and attempt to retroactively take credit for it.
I'm not sure I understand what you mean here by "take credit" but, that aside, are you suggesting that it would have been easier for Netscape and Microsoft to cooperate (or for gmail to support both) without some standards?
Back in the day yes. Modern web standards upgrades are designed (a) because Google wants them, (b) for regulatory capture -- making it too difficult for a browser to be created (I'm abusing the term to refer to behavior regulated by "web standards").
(c) because they provide features requested by developers/users. Compare modern JS to JS from 10 years ago, it's pretty clear Google is not the only one benefitting from the new standards.
The question is cooperation between who exactly? A cooperation can turn into a collusion. And all I can see as members of these boards is a bunch of corporations, that are known for using underhanded tactics.
If we're talking about creating a browser from scratch, it's nearly impossible to implement one without a huge investment of both time and money. Browsers are unbelievably complex, and the new features are being added at such a pace that you need to run twice as fast just to keep up.
If we're talking about forking an existing browser, that is doable. But you still need a huge investment to understand, change and extend that code. Once again, browsers are unbelievably complex beasts.
Because a modern browser is about as complex as an operating system, and moves even faster.
Check out the complexity of ES6. You're gonna need an interpreter for that which performs acceptably well, plus a DOM interface to the rest of the browser. And check out how complex CSS is when it starts interacting with everything. Gotta handle all that too. Along with the basics of HTML structure, and how to interpret horribly broken HTML. And all of those pieces have to work together in realtime for dynamic animation, and do so fast enough for webapps to work and without eating too much of the host system's memory and CPU. And handle the constant addition of new JS APIs and how they have to interact with the host OS. Better be compatible and integrate well with Windows, OS X, and Linux too.
Building a new one from scratch today is pretty comparable to building a new operating system. You'd probably need to coordinate thousands of people working fulltime to get it off the ground. And it's basically impossible to charge any money for it, since all of the tech majors give away fully supported mature browsers for free.
In theory, you can fork an existing browser. But they all move so fast, keeping a fork with any useful changes up to date with the main browser is going to take a significant sized team too.
Microsoft is a tech giant, and even they decided to dump their independent Internet Explorer codebase in favor of using a Chromium fork. Now the only other truly independent browser codebase is Firefox's, and they haven't been doing so great the last few years.
It's probably practically impossible to build a browser that isn't a fork of Chromium these days.
My take-away from the post here is that to build a good browser you'll need to include some licensed bits. You might have a hard time incorporating those licensed bits into an open source project. Which sort of brings things back around to a business problem.
