Ask HN: Why are we so at the mercy of Google and Mozilla for web browsers?
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?
143 comments
[ 2.8 ms ] story [ 67.3 ms ] threadhttps://www.quora.com/How-come-an-internet-browser-is-millio...
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.
What could be the difference? Location?
I just block cookies on Quora and it works.
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.
http://toastytech.com/guis/qnxdemo.html
Even support for Unicode is so complicated it's scary.
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.
However, Safari has had support for basically everything you need for a PWA except, thank god, notifications.
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.
> 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?
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.
No disrespect to MS of course, but nobody needs another browser by force when one is already installed natively.
Are you prepared to devote your entire life to it? Why not?
It's Chrome/Chromium-variants vs Safari
Firefox lost the war many years ago
Opera was the best browser imo, i wish it took off, nowadays it's just a chromium variant; wich is sad
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.
Probably because Safari's dev tools are notoriously worse than what Chrome and Firefox offers.
2. Safari devtools are a lot worse than Chrome.
Actually, it doesn't. Look at the "usage relative" chart:
https://caniuse.com/?search=localStorage
Safari is the distant second option.
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 just left an org where everyone used Macs (many thousands). Never saw anyone use Safari (except for one project manager expert beginner).
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.
I do keep Chrome/Firefox around for when I need extensions or Chrome Remote Desktop.
https://developer.mozilla.org/en-US/docs/Web/API/Fullscreen_...
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
Ugh, please. They've only got a mere 200 billion in liquid cash.
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.
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).
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.
As a person who uses Safari as the main browser, I call bullshit.
How many web apps where cancelled or has to be fundamentally changed because safari?
As a user you tend to not see it as safari is a high profile target and as such devs tend to make sure it works for it.
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.
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.
0: https://caniuse.com/css-cascade-layers
Hell, it works more "everywhere" than Chromium (let alone Chrome) does.
Which is really sad because Safari used to have near-best-in-class dev tools 10-12 years ago.
Where?
> In my market (mostly in the UK)
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.
In case you didn't know.
>Where?
>> In my market (mostly in the UK)
>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.
>In case you didn't know.
Is that tone really necessary?
> 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.
We will have to agree to disagree on that.
> we build products used in multiple continents and Safari has never been first. At best, 3rd.
So, you have a different experience to me, which is the literal point, and in fact to the global average where Safari is very much second:
https://gs.statcounter.com/
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.
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)
Not a problem lately, but I don't expect this to last forever, unfortunately.
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.
It appears that the servo team was fired but the repo is still seeing some development [1].
[1] https://twitter.com/directhex/status/1293352458308198401?s=1...
It appears that the servo team was fired but the repo is still seeing some development [1].
[1] https://twitter.com/directhex/status/1293352458308198401?s=1...
Is that a recent issue (or fix on FF)? I watch NF on Firefox all the time. Windows, Mac and Linux all.
Prior to that, the comment explains:
> Mozilla had an Adobe deal that did not extend to non-Firefox Gecko embeddings.
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.
[1] https://github.com/servo/servo/wiki/Remaining-work
We aren’t at anyone’s mercy.
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.
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.
You severely underestimate how much work needs to be done to create a new web browser.
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.
And that’s the whole point.
Mozilla has made a browser. So has google. Why make them out to be bad actors for providing something that is too big for mortals to even contemplate?
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.
[1] https://www.reddit.com/r/firefox/comments/a98gmi/donations_t...
[2] https://arstechnica.com/information-technology/2020/08/firef...
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.
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.