I hear what seems many a valid complaint about Google's conflicts of interest in managing Google Chrome and how it has down-stream effects on Mozilla and other web browsers. What exactly is keeping developers from making a fully featured open source web browser not at the mercy of Google or the browser's developers?
The scope of what a "web browser" is has been steadily inflating at an insane rate. Not only that, but a lot of features are basically "required" to be able to deal with modern websites.
You would need a team the size of Chrome's to be able to just _keep up the pace_ and never actually close the feature gap. That's a ludicrous amount of money for an incredibly risky project, since users are very complacent and get attached to their browser choice.
In fact, the browser is so multi-featured and has space for so many individual behaviours that users will get used to specific things (shortcuts, menu behaviours, even the sorting of address autocomplete results) that they develop the same (understandable) attachment to the exact way a browser works, just like what happens with operating systems. Then it's not even a rational choice anymore, and only another equally irrational event would cause them to reconsider their choice (either a major fuck-up by the browser they use, or some apparently inconsequential thing about the alternative).
You could make a feature-slim browser, but it would never reach wide adoption, because non-technical people would still need to open one of the big ones to do their online banking, or make video calls, or whatever.
>You could make a feature-slim browser, but it would never reach wide adoption, because non-technical people would still need to open one of the big ones to do their online banking, or make video calls, or whatever.
A prime example of that practical reality is ex-Mozilla founder/programmer Brendan Eich having to switch Brave's forked code from Firefox to Chromium ... because one of the reasons is "Chromium can play Netflix videos":
https://news.ycombinator.com/item?id=22062636
Similar to Eich's decision, other entities like Opera and Microsoft gave up on trying to maintain their own proprietary browser engines and just decided to fork Chromium. If Microsoft with billions sees no strategic need to invest in their own Trident/Edge browser and are willing to switch to a competitor's browser as a baseline, that should give an idea of how daunting a task it is for a hypothetical group of FOSS programmers to code an alternative browser.
EDIT reply to: >Gecko is just relatively unfriendly to embed in an app.
That may be true but that difficulty didn't stop Eich/Brave from using Gecko at first. His comment said they had to switch to Chromium because of performance issues and the DRM to watch things like Netflix.
This is bigger than some think. There were a lot more Gecko browsers back when you didn’t have to buy into XUL/XULRunner or fork Firefox to use it. RIP Camino and K-Meleon.
100%. To add a little more detail, the scope is both broad and deep.
Broad - You have many, many new features like WebAssembly or WebXR Device API. All of these are bets and it is hard to know which will gain adoption, so you build things like WebSQL, only to have them abandon for a new winner (IndexedDB).
Deep - Rendering HTML5 content with CSS3 styles is such a massive effort. Check out the Servo project, Mozilla's attempt to rewrite the rendering engine in Rust. You have world experts that have already written a rendering engine and after years of progress (2012 - 2018) there was still more to do[1]. TODOs include implement Flexbox, which is core primitive in today's web design toolkit. I'm not sure how feature complete Servo is today, but it is shocking how much effort is required to build a production rendering engine.
Agreed. Back in 2004, we did a college project to build a web browser for our CS Class and I built a poor man's browser using Java and Swing (Yes I know I know). Honestly, I was able to load a few websites using it and I was super proud of myself :). Today though, I doubt I can write something like that so quickly and get any adoption since browsers are fully loaded with so much stuff these days.
> You could make a feature-slim browser, but it would never reach wide adoption, because non-technical people would still need to open one of the big ones to do their online banking, or make video calls, or whatever.
Yeah. There are slim browsers around, but feels quite pointless if you need to keep Chrome or Firefox installed anyway. (Last week I used Dillo because Firefox was broken: https://news.ycombinator.com/item?id=29918052)
There was a time just a year or so ago where I had Chrome, Firefox, and Safari all ready to roll because some bank-of-mine's website would break right at the crucial point (click to confirm bill pay, transfer, whatever). Maybe it was my ad blocker? Whatever, I had to switch to another browser to actually complete my transaction. And then, in two months, the fail behavior would appear on the browser du jour and I would switch back to another one of the three.
Not a problem lately, but I don't expect this to last forever, unfortunately.
Whenever this question is asked Apple is left out, please remember that all browsers on iOS are effectively Safari.
In my market (mostly in the UK), 54% of transactions happen on a iOS device. Nearly 60% of transactions are using the Apple Webkit engine when you also count Safari on MacOS.
Apple absolutely dominates browser engines, I cannot understand why devs (with Macs) don't all do their initial development with Safari then test in Firefox/Chrome. Seems completely backwards to do your development mostly with Chrome.
Devtools. Chrome's are bar-none IMHO and safari's are absolute dogshit. God have mercy on your soul if you try to use the dev tools for Safari on the phone and/or a cross-platform web-based app on the phone. It crashes more often than not and locks up like crazy. I do everything in my power to avoid using Safari except at the last stage of testing.
Therein, as the bard would tell us, lies the rub. UK is a bunch of islands. Unless you are building super localised products, the world is a big place with a lot of people who don't use iOS.
>Therein, as the bard would tell us, lies the rub. UK is a bunch of islands. Unless you are building super localised products, the world is a big place with a lot of people who don't use iOS.
You have purposely quoted my comment out of order, implying that I’m unaware of how geography and market effect browser usage, when that’s literally my point and Safari does dominate in some areas.
Yes that tone was absolutely neccesary because you wrote
> I cannot understand why devs (with Macs) don't all do their initial development with Safari then test in Firefox/Chrome. Seems completely backwards to do your development mostly with Chrome.
I do 98% of my dev with a MBP. I hate it but its a work laptop. That being the case, we build products used in multiple continents and Safari has never been first. At best, 3rd. So no sir, we aren't doing things backwards.
That's really interesting, I also have a feeling that the percentage of Safari users that spend money on the internet, is bigger than that share on Chrome
These are my own metrics, which are most important to me. However I believe they are mostly representative of the UK consumer e-commerce market.
Obviously if I was building something like an enterprise/business SASS web app that was mostly used on desktop it would be a different story and Chrome would probably dominate.
My point is people regularly forget about Apple WebKit (due to iOS) in these sorts of discussions.
When it comes to deciding how to test your site and choosing which to use as your "primary" browser while developing, I beleve you should use the one the majority of your customers are using. For us (and allot of people) that's Safari but use your own (not global average) metrics.
I quite like Safari as an end user, but I do tend to do most of my development/manual testing on Chrome first because I just plain don’t understand Safari’s dev tools. If I could just attach Chrome’s debugger, I’d happily use Safari more for dev.
IMO it seems like "all browsers on iOS are Safari" isn't that big of a deal because 'browsers' on iOS still get to throw all their own features and sync services into their browser app. It'd be like saying you wish you didn't have to use Windows' window APIs to create windows or wished you could avoid UIKit to do anything on iOS.
This is conflating "Browser Chrome/UI" and "Browser Rendering Engine", from a developers/business (and a web standards) perspective the rendering engine is what matters. From that perspective all bowsers "engines" on iOS are Safari/Webkit.
From a purely business standpoint, the UI really is all that matters. Users don't choose firefox over Chrome just because FF has CSS cascade layers[0] (for example), they choose it because they think the sync/PW manager is better for them, or they might like the look of it more compared to alternatives.
That might well be why a user chooses it, even on iOS. But from my perspective as a business owner and developer, on iOS Chrome is Safari no matter what. When I test my site for use on iOS, I test in Safari. Which variant they use is irrelevant.
Firefox doesn't crash and pretty much works everywhere, and Safari doesn't crash (although it only works on Darwin); that doesn't sound like a differentiator.
This is hyperbole: if you are developing against web standards, most things work compatibly in all browsers now. In my experience, it's a bit more likely that you'll find a problem with Safari than Chrome or Firefox but not enormously so; the worst I've found are typically cases where someone only developed in Chrome and ended up relying on the non-standard API they started with rather than the final standard version.
Crashing not just the tab but freezing the whole browse and desktop UI on a non malicious well formed standard compatible pice of wasm...
That (freezing the whole desktop) shouldn't even be possible even if safari has some bug.
also no usable crash report or anything, no way to debug it etc.
Sure that's just one maybe especially unlucky example.
And my comment comes from a "additional cost safari imposes compared to e.g Firefox" point of view. So I'm counting long outstanding missing features as bug (except if missing for reasonable privacy concerns).
Anyway as far as I can tell it's not as bad as IE in it's later days, but not that much better (wrt. cost it forces onto you).
That sounds like you may have an issue with the total amount of RAM used until it eventually failed but that's an edge case, not “a buggy mess”, and it's not like neither Chrome nor Firefox never crash. It's been at least half a decade since one of them has been notably more or less reliable than the others in my experience.
Regarding crash logs, Safari uses the same system crash reporter as everything else. If you want to see those, look in the Console app or use “defaults write com.apple.CrashReporter DialogType prompt” or the Crash Reporter Prefs tool from the Additional Tools for Xcode package to make crashes trigger a prompt.
> And my comment comes from a "additional cost safari imposes compared to e.g Firefox" point of view.
Welcome to web development? Preferring one browser always means that you perceive other browsers as a cost because inevitably you will run into a bug or compatibility issue in the one(s) you test less frequently with. It's less common in all browsers these days but it's still pretty much a given that I'll find something unexpected in one of the 3 browsers I end up supporting.
And some weird CSS behavior that only exists in Safari right now: like :first-child selectors, limited flex-basis values, the gap property not working in a multi-column layout... It's mysterious discrepancies like this that drive me insane doing frontend for iOS. Apple can't spend a crumb of it's $2T+ getting their browser and dev tools up to par with even Firefox? Please
Two things: that's not “a buggy mess” unless you think Firefox/Chrome magically turn into one if you use one of the APIs which Safari supports which they don't or have bugs with. Again, remember that I wasn't saying that there are no problems, only that they were exaggerating the magnitude and degree to which it's specific to Safari.
Second, this is not only not “a buggy mess” but a conscious design decision and one which I generally agree with. Safari supports full-screen video, which is the primary reason why I want this, and the full-screen API is a notorious security risk on touchscreen devices even more than traditional computers because you don't have the equivalent of the escape key or the operating system UI giving you a way to tell that the “Please enter your password” dialog which just popped up was generated by the web page and not your OS. On iOS, Safari is already close to full screen anyway so the extra few pixels is less than what you'd need to account for in different screen heights between devices anyway.
As a dev who works on a Mac with Safari, I say none: my co’s app, which is quite complex, “just works” on Safari (what I use), Chrome (what the rest of the team uses), and Edge (what our bigger customers use).
Is this because of React? Babel? Webpack? Maybe. All I know is that we happily code away on this complex beast, and everything. Just. Works. Everywhere.
The original statement was "anything beyond basic website Safari is a buggy mess", not "You use it sure, but du you know how much additional money was sirens just to work around problems".
So. As a person who uses Safari as a primary browser, I call bullshit on the first statement.
Additionally, as a person who does frontend for a living (21 years and counting, sometimes just frontend, sometimes fullstack), I call bullshit on the second statement.
Perhaps, but I still prefer to develop with Safari then test with FF/Chrome. I'll admit that I'm not necessarily doing cutting-edge JS stuff, but the Safari tools are good enough for my needs.
I have my whole family using Safari almost exclusively with Wipr content blocker, due to battery life, integrating with keychain and Apple Pay, and I trust Safari for privacy and security more than Chrome.
I do keep Chrome/Firefox around for when I need extensions or Chrome Remote Desktop.
Curious where you all are going where you aren't plugged in all the time anyway? I don't think I've been away from a charger being within 5 feet of me for 2+ years.
Yes, the power savings and heat reduction are significant to a large enough degree that one has to wonder why Chrome and Firefox are so much worse in that way.
It’s my primary browser because of battery life, tab bar and url bar being the same bar, and it’s reader mode. I’ve tried a lot of chrome extensions and don’t like any of them near as much as safari’s built in one.
My mom does, but she's getting more and more frustrated with website incompatibilities. I think she knows the onus isn't on Apple, but she still thinks they need to invest more to keep up.
You might want to look at the stats for whatever sites you work on. For the Mac users of public sites I work on Safari is roughly tied with Chrome with Firefox about 1/5th of either one.
> every time I have used Safari I ended up frantically looking for a chrome icon
No idea what you do in Safari that makes you go to Chrome.
Well. I open the unbearable Google Cloud Console in Chrome. It's marginally faster there. And because I only keep one Google login in Chrome, since none of Google's properties seem to be able to figure out how to work with multiple Goigle accounts consistently.
The simple answer is, browsers are brutally hard. Browsers have to support an almost infinite amount of instructions, whether it's html, css, js and now wasm, not to mention the insane amounts of apis, protocols and so on. I mean just open the developer tools and think of the insane amount of work that would have to go into developing something like this. Even Microsoft with thousands of developers at their disposal and finances to double them with a snap of a finger, figured that it's not worth developing a browser engine in-house. That alone speaks volumes.
Chrome has such a market dominance that it effectively determines what 'fully featured' means. Regardless of what the specs say, if something works a certain way in Chrome the layman's expectation is that it should work the same way in every other browser.
> What keeps developers from building an open source alternative?
Well I can't speak for all software developers but I can tell you that for me the juice to squeeze ratio isn't in a good place. I already have a job and it takes up most of my time. The open source movement has turned out to be unsustainable in my eyes since its ideological roots are easily subverted by the project sponsors. Meanwhile commercial closed source software is only viable if you can find paying customers. Virtually no one is willing to shell out for a web browser since there are highly useful 'free' alternatives. Certainly I find it troubling that virtually all the data in the world is being collected, collated, and sold. Most folks don't seem to care enough about the privacy concerns to open up their wallets though. Google has effectively 'won' the browser wars barring a government solution. So why should I or any other software engineer enter into a David v. Goliath fight for virtually no pay or appreciation when I could go work on the next big web app and make a small fortune instead?
Quoted from Lam Luu above (in case you don't have quora login):
Let’s do some accounting. A (quasi) modern browser must:
Parse 4 different languages: HTTP, HTML, javascript, and CSS
Encrypt and decrypt SSL (multiple versions of SSL, in fact).
Deal with network.
Act as first and most important defender of user’s security.
Deal with graphics (e.g. win32, Xorg, etc.)
Layout HTML and CSS.
Interpret Javascript.
Deal with local storage.
The above list is just the bare minimum. A regular modern browser also:
Has plug-in systems (more difficult to design than most people think).
Stores history and favorites. Syncs them across different devices, too.
Supports multiple tabs at the same time.
“Incognito” mode.
Stores passwords.
Provides GPS, webcam, and microphone support (HTML5).
Stores and recovers session in case of crashing.
Checks for upgrade and installs itself as needed.
Do all of the above fast fast fast.
I mean, any of the above items (in both list) would require at least tens of thousands of line of code to do right. Yes, even network programming. Effective and fault-tolerant handling of network is very very hard.
And this is just the bird-eye level of looking. Each item can be split into smaller items, each of which is major in their own right. For example, HTTP has multiple versions, and a web browser has to deal with as many as possible. Javascript is, well, no comment. HTML is a *** mess, to put it mildly. SSL has multiple versions, each of which has its own bugs to contend with.
If medical devices are like avionics, life critical software is actually pretty boring. And it is probably a good thing.
I definitely didn't have the feeling that "if I get that wrong, someone will die". Yes, it is definitely true that people may die, but responsibility is so diluted that if feels so foreign. You are given specifications that are extremely detailed, you implement them, all the fancy stuff is banned. You freeze the version, then someone reads the specs, write the tests, pass the tests, weeks later, they discover a problem in the specs, update the specs, update the code, update the tests, freeze, more testing, etc... Refactoring? Don't even think about it. Continuous integration? Sure, but that won't update your documentation signed by 15 different people that is necessary for certification. The process is so mind numbing and tedious that the fact that there are lives on the line is the only motivation. And even with that, many people simply don't give a fuck (and it is as scary as is sounds).
When the software is finally in production, if there is a problem, it passed through so many hands that no one and everyone is responsible at the same time.
I wonder how many lines of code were in the QNX 1.44MB demo disk, which was a bootable floppy that included a javascript enabled browser, hardware drivers for video, networking, windowed graphics, etc.
As a side-note, the web has grown several orders of magnitude more complicated since then. I'm willing to be that every single codec is more complicated than the JS VM they used to ship. JavaScript JITs are scary beasts, too, themselves several orders of magnitude larger than a simple JS interpreter, etc.
Even support for Unicode is so complicated it's scary.
Also, web browsers from that era were very insecure. The “You Are an Idiot” Trojan was from that era.
Web browsers with the same featureset, but developed to modern security standards, would be nigh impregnable. Unfortunately, the market has a certain level of tolerance for holes, and that tolerance level isn’t zero, so the extra “budget” gained by sandboxing, fuzzing, ASLR, and safe C++ practices, gets invested into new features instead of left on the table.
RedHat still offers Konqueror (Safari's father, and Chrome's grandfather) in their repositories. I think that would likely be a better base to revive a community browser.
After some discussion of suckless.org last week, I decided to load "surf," the suckless webkit browser, on OpenBSD.
The URL appears to be specified only on the command line, not in the GUI (the Ctrl-G sequence in the manual page does not appear to work). I can't get it to accept a self-signed cert (easy in any other browser). No back/forward button in the default GUI, and I can't get them to come up.
Browsers are hard, and they require a funded and dedicated organization to maintain them.
From time to time I use surf, but it isn't a fair example of what is hard. Suckless.org's philosophy means you may need to recompile for any configuration change and something like trusting a self-signed cert is often done via configuration.
I still use Konqueror as a file browser. There was a day I used it for web browsing + file managing (back in KDE 3 days), but there's very few updates being made to KHTML these days and it has stagnated.
I had heard that Konqueror had removed KHTML, and substituted a qt widget that bundled a recent Apple webkit. I'm not sure about this status, and I'd have to look it up.
Nobody is forcing us to use browsers from google or Mozilla.
We are all free to implement our own UA. The specs are all open standards.
What stops us from writing browsers is the sheer volume of time and effort required - hundreds of thousands of hours of highly skilled work. That is all.
In the absence of such an effort, we would be left high and dry, with no way to experience the web.
Fortunately, that isn’t the case, because some others have done the work and allow us to use their browsers.
For that, we might feel grateful.
We might also be wary, and try to be aware of any adverse consequences of using someone else’s thing. That’s common sense, but it is still not a case of being at someone’s mercy. That situation loomed when one company sought to control the standards for the web as well as the implementation, but what we have today is different to that.
The specs are open standards, but do the specs specific enough to actually do something that would work in practice?
By "work in practice" I mean handle most sites that people actually visit and display them almost identically to the way Chrome and Firefox do. If your new browser doesn't do the same thing as Chrome and Firefox on those sites, the users are going to perceive it as your browser sucking.
If Chrome and Firefox deviate from the spec in some way, you will have to match that deviation.
If there is something not covered in the spec but that browser have to deal with (such as handling malformed HTML, which a lot of sites have), you will have to match what Chrome and Firefox do there.
This feels like saying that you're not forced to be subject to the laws of your country, because you could always go find an unclaimed island and create your own country. At some point the practical impediments are such that yes, we are at their mercy. And no, Google at least does not deserve any gratitude for creating a more efficient ad delivery machine (what, you think they provide a browser out of the goodness of their hearts?).
You're not stuck in some evil country. You have Mozilla. If you want to improve it, you can submit code to it. Or start a new browser project by rounding up a dozen friends who feel the same way you do and going for it. If you're not a software engineer, you can be an evangelist who inspires software engineers. What is stopping you from working towards your own ideals?
And even if you could do it, it's not a given that you can make a good one.
In fact, I believe making a good browser is impossible because the web is fundamentally broken. The standards require your browser to be crap. The browser is no longer a user agent, it's a server agent, and trying to block & work around antifeatures is akin to writing an antivirus program that somehow detects and blocks malicious code without breaking the rest of the program. You can try, but it's a ridiculous never-ending cat and mouse game and if you don't keep up, you just end up "breaking the web" without actually making any part of it good.
There's no such thing as "PWA". There's half a dozen to a dozen disparate APIs, and every PWA proponent has their own list of what they consider PWA support.
However, Safari has had support for basically everything you need for a PWA except, thank god, notifications.
For how many websites use notifications unnecessarily... I have a hard time feeling sorry for anyone complaining about how they can only do notifications from an app (which Apple could review).
There are legitimate uses of notifications from websites, like being told from my webmail that I've received a new email. Or any other messaging service. But no, let's throw the baby with the bathwater because some blog sites ask for notifications to spam you.
Apple isn't crippling PWAs because it cares about the user. They get more money if you pay for an app on their App Store. Simple as that. In every PWA thread I keep reading the same Stockholm Syndrome argument that Apple are crippling PWA to save us from the notification spam. Meanwhile I have native apps spamming me with offers.
Apple isn't crippling PWAs. Once again: there's literally no such thing as PWA. It's bunch of very different standards.
You decided that notifications support are a 100% must to qualify as "not crippling PWAs". Whereas to qualify as a "PWA" an "app" literally only needs two things: service workers and being able to be "installed". Everything else is just gravy.
The complexity equivalent to regulatory capture.
I once got banned from /r/firefox for implying intent on googles behalf here. Apparently that is a conspiracy theory.
In the end there are however clear incentives and profiteers of the development. Google has an incentive to keep the web complex enough to the point where they are the monopoly. Same goes for governments and complexity of security mechanisms.
How ever we got here, now google is the internet and security is achieved by things like TLS. Its inefficiencies that are profitable for existing power structures.
Which also makes it a lucky coincidence that mozilla is behaving as user -unfriendly as they do.
I would imagine it's regulatory capture by accident - Chrome constantly gets requests from developers (which includes big corporations) to add features, so I imagine saying 'no' requires a lot of user research to back up why users/developers actually don't want a feature.
Google doesn't need to bother with intentionally adding complexity. That's happening by itself just fine.
They just need to not aggressively fight complexity.
And calling TLS a inefficiency that is profitable for existing power structures.
Or implying that Mozillas user unfriendlyness is a lucky coincidence.
Sounds quite a lot like conspiracy theories to be honest.
I mean I wouldn't even call most of the recent moves Mozilla did user unfriendly. Depending on the user they target they weren't. They just made the mistake to forget that many of their "simple" users are there due to their "tech enthusiast" users... A mistake easy to do is you mainly look at statistics.
Increasing complexity has these effects intent or not. I think the description of complexity capture still fits. Its a situation that is beneficial for google so they are a unlikely source for a fix here. And like others in the thread pointed out, the entry hurdle is too large for new competition. The only way out is with an alternative without the complexity.
I am going to stick with the TLS part though. The more complexity you add in crypto the less safe it becomes. Adding unnecessary complexity weakens the entire solution. And the current "is" situation is certificate authorities and man in the middle attacks. Not to mention overblown implementation you have to patch till the end of time.
edit: I think its also not a surprise that the question boils down to complexity. I would argue its the big open question of our time. We keep building till the negative consequences can no longer be dealt with through technology alone.
Developing a modern feature-rich browser is a gargantuan task and you need many skilled (expensive) developers to work on it; easily millions of USD yearly in salaries alone. Some donations here and there won't cut it, you basically need FAANG money to do it. Additionally, at least the last time I checked, Mozilla has made it impossible to donate to Firefox development; donations go to their activism branch, not browser dev [1]. In 2020 they also fired 25% of their work force [2]. They'll probably sunset the product altogether within a few years and that leaves us with an ever-greater market share of Chrome and derivatives, and from here on out it's hard to conceive of a viable strategy to develop an independent browser. Maybe a government or EU could do it, but that comes with its own set of problems.
It takes a huge, lengthy effort to make a browser that is close enough to standards compliance and performant enough that people would be happy using it.
Even if you do all those things, there's little guarantee that your efforts would be noticed by many people, since you would need to do a LOT of marketing (especially to get your browser installed by default in MS/macOS worlds).
The costs are just not worth the risk-adjusted rewards.
> What exactly is keeping developers from making a fully featured open source web browser not at the mercy of Google or the browser's developers?
It is incredibly difficult to build a web browser because of the sheer complexity and scope. You are essentially building an entire platform on the scale of an operating system that must support legacy features and behavior from decades ago. Users expect everything to just work, and if you can't make it work, then they have little incentive to use your product. Just ask Microsoft[0].
Apple's Safari also uses a distinct rendering engine, Webkit. Chrome is based on Blink which was forked from Webkit and the two are quite different now, including in terms of supported features.
Maintaining compatibility in web apps is a problem thats mostly been irradiated since MS finally dropped IE. In terms of architectural decisions you are going to end up very closely tied to Googles design decisions if you want to maintain full compatibility going forward.
Theres really no winning here, FF already has to follow in Chromes footsteps because of how dominant they are in the market. They have all the decision making power on "what the web supports".
Because we were at the mercy of NCSA Mosaic, Netscape launched as a Mosaic killer. Then as Microsoft awoke in alarm because they were at the mercy of Netscape they launched Internet Explorer, effectively killing Netscape which spun out Firefox in response. Google became alarmed by the prospect of being at the mercy of Microsoft and so launched Chrome.
There's a huge barrier to entry if you start from scratch. You can fork an existing browser of course, but what would you change if you could so?
It seems difficult for a browser to differentiate itself these days, as the existing ones have had the time to build out fairly complete feature sets, and they can just copy each other if there is some big new idea.
You named the closest solution we have to the Chrome hegemony- Firefox. It's a fully-featured browser that's open-source and maintained by a nonprofit organization.
Browsers are complicated. Like, desktop operating system levels of complicated. Think about it- multitasking, resource allocation, I/O management, graphics, file management, networking... these are things your browser does.
If you really want to get into the weeds, check out Surf (http://surf.suckless.org). Its features include "the ability to display websites and follow links."
> What exactly is keeping developers from making a fully featured ... web browser ... ?
I think the biggest issue is the complexity and scope of work. If you want a web browser, I can make you one over the weekend, it just will only work with a tiny subset of pages. To fully handle every website is so hard even Mozilla gave up on their rewrite of their engine, Servo. If it was easy, they probably would have finished.
If you are suggesting, "Why don't we all pay a bunch of progammers to make the world's best browser that is everything I want?", you can try, but everyone has different ideals about what a browser should be.
Just looking at Firefox's docs[0]: "The clone can take from 40 minutes to two hours (depending on your connection) and the repository should be less than 5GB (~ 20GB after the build)."
It would take some time (to say the least) to even start building a new browser capable of what Firefox can do given that size.
While servo shares an ecosystem with Firefox it is far more independent than chromium is so I would suggest it is the most likely emerging alternative browser engine and browsers built on it could become roughly as different from firefox as safari is to chrome.
It's not like other areas are so different, the number of compilers that are keeping up with LLVM and GCC has dwindled to the point that I can't name one without checking if it is EoL.
Shouldn't the title be "Why are we so at the mercy of Google for web browsers?" since Google is the one that financially pays for Mozilla to develop Firefox? If Google were to pull their funding, Firefox would cease to exist.
Or maybe it should really be "Why are we so at the mercy of Google and Apple for web browsers?" Since Safari is really the only other mainstream browser that is not entirely under Google's thumb.
I responded to a nested comment elsewhere saying I have seen one Firefox fork in 2021. Replay.io. A neat web debugger featured here.
I was mildly surprised Microsoft went with Chromium. Not forking Gecko or some mix of stuff that are not Blink. Or even Blink itself. I may be incorrect here, and maybe the separation of engine and browser is not as big as I’m thinking, but every major Chromium based browser including Edge are forks of Chromium, not just Blink. I don’t know how big of a difference that is.
I wonder what could have been if Microsoft had moved on from Trident Edge earlier. Say internally two years earlier than our timeline. If they still would have gone the Chromium route. With more time, they could’ve ironed out enough issues like Netflix videos and Firefox. Microsoft may have had enough of being the butt of jokes, especially, by people in tech and geek circles, and wouldn’t want to try anything remotely outside the norm (aka Chromium). Putting aside XUL extensions, the other dismissal by people is Firefox still having far fewer extensions than Chromium. Even with all three major browsers/engines using web extension api now. Msft may have not wanted to deal with the PR of that either.
It would be really nice if Gecko and its future had Microsoft too. I’m sure some would say they’d rather the behemoth that is Microsoft not be allied and working on Gecko/Firefox. Yet It has to be better than the current situation. Unless Microsoft forks Blink and has their own engine in the future.
Apple never putting any effort into the Windows Safari app, no less, an Android version is also a bummer.
The final bummer: Firefox and Mozilla getting so much crap from tech and geek communities. I never looked up how they spend their money, but being so cynically against Firefox’s every minor possible misstep is not helping.
This comment may appear to be an apologist for Microsoft, Apple, Mozilla. It’s not that. Firefox continues to lose market share. Safari is sticking to its 2.5 OSes (if iOS and iPadOS are 1.5) and i believe have a better chance of losing ground unless something like their web extension library quickly grows or is able to use most Chromium extensions. All this to say. My focus is on Chromium not having a 90%+ market share on the three desktop browsers and 95%+ on Android.
And yes Apple not allowing competing browser engines on iOS is lame.
What everyone else has said about why there are so few new cleanroom browsers. If you're looking for one of the few examples that isn't based on Blink, Gecko, or WebKit, it's Flow. https://www.ekioh.com/flow-browser/
The web browser went from being a way to browse hyperlinked documents to a virtual machine used for application development. The scope for both has ballooned to the point where you would need a large team and some kind of feature to attract enough users to make it worth building something new.
browsers have taken the place of operating systems.
why are we at the mercy of windows and mac os? alternative operating systems exist, just like alternative operating systems exist. but their marketshare is small.
Recently started noticing that they (MS) shoved their mobile Edge browser into the Outlook app in iOS. It was consistently nagging to just activate (whenever any URL is clicked from an email). It was time to say goodby to the Outlook app.
No disrespect to MS of course, but nobody needs another browser by force when one is already installed natively.
If you have to twist people’s arms to get them to use something it means they don’t fucking want it. I am surprised that Microsoft hasn’t stooped down to sending out junk mail on paper begging people to use Edge.
You would need a team the size of Chrome's to be able to just _keep up the pace_ and never actually close the feature gap. That's a ludicrous amount of money for an incredibly risky project, since users are very complacent and get attached to their browser choice.
In fact, the browser is so multi-featured and has space for so many individual behaviours that users will get used to specific things (shortcuts, menu behaviours, even the sorting of address autocomplete results) that they develop the same (understandable) attachment to the exact way a browser works, just like what happens with operating systems. Then it's not even a rational choice anymore, and only another equally irrational event would cause them to reconsider their choice (either a major fuck-up by the browser they use, or some apparently inconsequential thing about the alternative).
You could make a feature-slim browser, but it would never reach wide adoption, because non-technical people would still need to open one of the big ones to do their online banking, or make video calls, or whatever.