Ask HN: Why do new browsers use Chromium instead of Firefox as their base?
Every time there is a post here related to Firefox, I see a lot of people complaining about the state of browsers and the utterly dominance of Chrome and Chromium based browsers.
I’m wondering if that are technical reasons why the newish browsers (such as Brave or Edge) are choosing Chromium instead of Firefox as their starting point.
If so, shouldn’t this be a priority for Mozilla to change that?
190 comments
[ 3.3 ms ] story [ 87.5 ms ] threadIf you think that there are engineers specifically on the Chrome/Chromium team who ARE interested in the technology, what's the chances that there are engineers on the Firefox team who feel the same?
My point being companies will always have to be monetarily-biased, and the hope is that the team working on the product itself still believe in it because they don't get much kickback from management's decisions about the technology.
I know, they claim their goal is to promote the Open Web and so on... But that ideal from the 2000's is long gone at Mozilla, when you see how the leadership is acting.
It has this weird structure because the search deal makes too much money relative to donations according to IRS nonprofit rules.
If B corps existed back when this structure was created, then they would have incorporated as that, but B corps didn’t exist then, and there’s no benefit to reincorporating as a B corp now.
Mozilla doesn't seem to have performance driven incentives. The remaining supporters of Firefox at this point are people who are mad at tech companies/care a great deal about privacy.
Servo isn't a finished rendering engine yet and the browser I saw that could exclusively use servo was not compliant enough and since mozilla fired the servo team there is no certain future for it anymore. Projects that tried to make servo embeddable are all dead and gone (see https://github.com/paulrouget/servo-embedding-example for example)
So yeah last time I tried to use gecko I failed and didn't try again (years ago) nobody is willing to do the work and mozilla seems to focus more on other stuff...
When did that happen? It seems the managerial class has completed their takeover of Mozilla in the last few years. A real shame, since it basically cedes the entire web to Google.
Refocusing on making Mozilla a viable entity without the need for cash splashes from Google is doing precisely the opposite. By diluting Google's financial control it ensures decision-making is both actually and ostensibly impartial.
Gecko is still a perfectly functioning browser engine. It's far easier to keep Gecko up to date with modern web standards than reinventing the wheel.
As nice as it would be to have a free and open source browser engine written in a memory safe language, I can't see there being a lot of money in it for Mozilla.
In 2020 it was $242M and $137M.
The future-focused servo team was not the place to cut a couple million.
I think all of us on HN are a bit saddened about Mozilla cutting back on the Rust and Servo teams, but political-correctness isn't the reason behind that. Let's not turn this into one of those discussions.
As a black person in tech, I can't tell you how much that whole debacle drives me insane. I never once in my life ever made the association between "master branch" and "slave master". But now every single time I pull a repo with a "main" branch instead of "master", I have to think about it and play along to assuage someone's white guilt. I absolutely refuse to ever make the switch.
If you're getting harrassed by someone because you've got some repos with a "master" branch then I sympathise with you - the people giving you shit are likely engaging in a bit of performative outrage and don't really understand what this is all about. However if you're really getting upset when you clone a repo and see that someone's named it "main" then I have to say that might be on you.
"white guilt" doesn't necessarily care if their ancestors did it.
> But rather it's someone trying to follow a broader movement whose aim is to try to avoid terms they think are rooted in hatred or oppression.
It's annoying and sigh-inducing to be reminded that such a movement is full of people that don't understand how words work, that "master" has plenty of perfectly good contexts that don't imply "master/slave".
> However if you're really getting upset [...] that might be on you.
Nobody is "really getting upset" and that entire part of your post is needlessly insulting.
Honestly don't know what you're getting at here. You're going to have to spell this one out to me.
> It's annoying and sigh-inducing to be reminded that such a movement is full of people that don't understand ... that "master" has plenty of perfectly good contexts
I don't disagree. See my comment about people engaging in performative outrage, it does exist. But in this case you're annoyed at the very sight of the word "main". Like ... c'mon
> Nobody is "really getting upset" and that entire part of your post is needlessly insulting.
Are you misunderstanding that "However if you're really getting upset ..." means "However you're truly getting upset ..." and not "You're getting really upset ..."? Additionally if you read my comment, I provide two interpretations:
1. they exclaim "WTF" when attacked for having named a branch "master" (IMO understandable)
2. they exclaim "WTF" at the very sight of a branch named "main" (IMO a bit silly)
I honestly don't know which is the right one. It is up to the commenter if they want to tell us which it is.
Update: and just like that this part of the thread has become the farce I feared it would, we are debating whether the words "main" and "really" are offensive. This is a very important thing to consider when answering the question "Why do new browsers use Chromium instead of Firefox as their base?"
You said "I can almost guarantee that it's not someone with a guilty conscience believing that naming their branch differently absolves them of something they or their ancestors did." but the accusation of doing it out of "white guilt" isn't really saying they were trying to absolve themselves of something their ancestors did.
> I don't disagree. See my comment about people engaging in performative outrage, it does exist. But in this case you're annoyed at the very sight of the word "main". Like ... c'mon
Annoyance is pretty mild. If seeing it reminds me of it, what do you expect to happen? I don't think that's unreasonable.
> Are you misunderstanding that "However if you're really getting upset ..." means "However you're truly getting upset ..." and not "You're getting really upset ..."?
I understand that. By even bringing it up you're implying it's necessary to worry about people "truly getting upset" which is not saying great things about your opinion of your conversation partners. I mean look above where you said "c'mon", you're implying that it's unreasonable for me to be "annoyed".
> Additionally if you read my comment, I provide two interpretations:
And I was talking about interpretation 2 specifically.
I interpret "I have to WTF" as something akin to a double take, not "truly getting upset".
> This is a very important thing to consider when answering the question "Why do new browsers use Chromium instead of Firefox as their base?"
Shrug.
Mozilla is also one of the most open companies in our field — given how often we read about far less significant events there, it seems incredibly unlikely that there's some sort of substantial but well-concealed dark funding of “PC work” which has remained secret even after, say, lots of people being laid off or leaving especially when such work would by necessity have visible impacts.
Was the Firefox OS less future-focused than Servo? I don't think so, and given that Servo actually did survive long enough to give back to the mainline Gecko (in the form of WebRender and so on). It might or might not make actual sense to conclude that as the ROI shrinks, but it is always easier to claim the decision was wrong after that decision.
> Firefox OS did have much potential to countries with less mobile penetration, as observed from KaiOS's success in India.
Such "success" is inevitably fleeting. Eventually a "developing" market develops to demand more established and desirable products. Nokia had those markets under lock and key for a long time, back when EU/US had already moved on to iPhone-like products; but then consumers inevitably gravitated towards the fashionable.
“fashionable” is the wrong word: it should be “functional”. Those old Nokia phones were very good at being phones but that's it — maybe a minimal messaging app, but anyone who used one knows just how limited those old mobile OSes were.
I think FirefoxOS was an interesting idea but there are really important thresholds you need to be able to hit and that was the critical error they made. There was no plausible way to grow the low-end feature phone market into a large enough business to get there when competing with cheap knock-off Android devices. If they'd started years earlier or gotten a major vendor on-board, maybe, but at their funding levels there was no way to make the numbers work and it was pretty clear at the time that this was a low-probability gamble.
https://www.mozilla.org/en-US/foundation/annualreport/2020/
All the "audited financial statements".
It should be the second full-page chart.
https://engineering.mongodb.com/post/code-generating-away-th...
CEF was also relatively straightforward to use. Both times we were embedding them in C++ applications.
Aside from thread-wrangling I thought it was trvial to embed.
I miss such numbers so much.
[1] https://spidermonkey.dev
[2] https://archlinux.org/packages/extra/x86_64/js78/
[3] https://www.linuxfromscratch.org/blfs/view/svn/general/js78....
https://github.com/mozilla-spidermonkey/spidermonkey-embeddi...
Also js78 uses the version of spidermoneky from Firefox 78. The current Firefox ESR is 91 (released in august), but I don't see any js91 package, and https://github.com/mozilla-spidermonkey/spidermonkey-embeddi... still says to use the 78 ESR. Note that ESR78 is end of life and no longer receives security updates.
And from what I understand, there is no attempt at backwards compatibility in the spidermonkey interface, so each upgrade requires a lot of changes to the embedding program.
Yes, it is possible to embed spidermonkey, but there are a lot of challenges.
But it didn't become more widespread until a switch to Chromium was made, which made the entire process a lot simpler in both execution and distribution.
And there hasn't really been a need to revisit Gecko.
Even spidermonkey, the javascript engine, is never reused as v8.
Different design priciples
But the "embedding gecko is hard, embedding chromium is easy" explanation certainly seems to be wrong, in terminology at least.
GNOME and Cinnamon desktops use it, MongoDB uses it, polkit, etc. It's obviously not embedded nearly as much as V8 but it does have a few.
Other than Ekioh’s Flow, I don’t know any other competitive attempts from companies building browser components from scratch.
https://www.reddit.com/r/firefox/comments/m8cwdu/why_arent_t...
With google building a track record of shady tactics, I would agree. firefox seems the better choice. It seems no more difficult to fork than chromium (though I've never tried).
My 2 cents, there's nothing to stop anyone from refusing to support updates on old frameworks and I'd suspect google to pull the rug out from beneath everyone before firefox anyday.
The core problem is that Gecko is not easily embedded. It does not strongly separate the renderer from the application, and that means that it is very difficult to simply use in the middle of another app.
You can compare it to WebKit and the old mshtml controls: the entire engine is designed, specifically with the intention of being a content view in an application.
Chromium inherited the core webkit design, so it is also much easier to embed than gecko. It requires much more work than a webkit webview, but that's largely down to exactly where they felt their API boundaries should be (e.g. a conscious design decision vs happenstance).
The end result is that forking Gecko is useful if what you want to do is make a fork of Firefox. Using gecko for anything else is challenging - there used to be a Mac browser built on gecko, and it required a huge amount of work to keep going, and would routinely fall behind due to changes that broke embedding. Just a browser, so it still had the same basic UI structure, and it was still hard to make in the first place, and hard to maintain.
arent they protocols? implementations of a protocol should not change.
my big gripe, chromium seems to make more analytics calls than gecko. are they grouping calls? probably.
gecko/firefox doesnt seem to have this agenda. Doh along with super-cookie controls seem to out-perform chromium in every way.
The end result seems to be privacy.
embedded?? are you using ChromiumOs?
Chrome/Chromium and its stack was designed to be easy to reuse and build upon. This may have been an explicit design goal because of the difficulties with reusing parts of Firefox and other software.
Embeddability has little to do with it; Chromium (as opposed to WebKit) isn't actually that embeddable. Rather, market share is king. With a high market share, the community will step up with projects like Electron and Chromium Embedded Framework that add embeddability.
No way. I remember the bad old days of XULRunner. In 2010, pre-Electron, it was literally easier to implement my own WebKit-based app from scratch in C++ than it was to follow the documentation and use XULRunner.
Firefox's embeddability was bad. Really bad.
Google achieved market share by taking the embeddable WebKit, wrapping it in a non-embeddable wrapper called Chromium, and eventually forking WebKit to Blink in large part to make it non-embeddable and more tightly coupled to Chromium.
So hey, any companies out there interested in bringing back a little diversity in browser engines? Or just making a tiny dent in Google's dominance for the greater good? Consider funding work to make Gecko better suited to embedding.
I don't think that's really the key problem since you don't have to build a new browser out of FF by embedding Gecko. FF itself is a browser that was made out of another browser, much of the old core Mozilla technology is basically a cross-platform app-building framework with one of the 'apps' being a browser. Somewhat unobviously, this turned out not to be a great way to build a browser in the long run.
It's actually great in the amount of flexibility and access it gives to 3rd-party developers to customize the browser itself. Unfortunately, the price seems to be complexity and rigidity in some critical areas (performance, embeddability).
Mozilla seems to choose what to do with donations though. I don't think there's any way to target funding for Gecko, Rust, etc.
I'd rather see a new player in the space. I have no confidence in Mozilla.
If anyone with a ton of money wants to focus Mozilla specifically on Gecko, Rust, whatever, then that person can probably get them to do it.
Bingo. Let's not forget, Chromium itself is built off a fork of kHTML, the rendering-engine-as-a-library originally developed and used by KDE project.
Apple forked kHTML and released WebKit. That gave the world Safari. Not long after, WebKit became the engine powering Chromium/Chrome, but with process isolation and high-octane JavaScript interpreter (V8). Then quite some time later, frustrated by Apple's control over the engine, Google forked WebKit and came out with Blink.
Sometimes the only difference between provenance and history is the written narrative.
I see you've bought into Google's historical revisionism.
When Google introduced multi-process rendering into Chrome, it was a massive technical innovation, but it was built at such a low level that it was effectively proprietary to Chrome. No one else could use it without pretty much adopting all of Chrome.
Apple (along with the rest of the technical world) recognized the benefits of multi-process, but Apple wanted to ensure that literally anyone building a WebKit-based browser could gain the benefit of multi-process rendering. So they created WebKit 2 [1]:
"WebKit2 is designed from the ground up to support a split process model, where the web content (JavaScript, HTML, layout, etc) lives in a separate process. This model is similar to what Google Chrome offers, with the major difference being that we have built the process split model directly into the framework, allowing other clients to use it."
In other words, Google's main technical advantage would be baked into the browser engine itself and made available for everybody.
As you can imagine, Google was less than thrilled, and the differing natures of the multi-process implementation led to duplication and complexity. So, when Google decided that supporting multiple architectures was too much work, it had a choice.
Google could do the hard work of switching Chrome's multi-process rendering to WebKit 2, which would mean a significant browser rework, but it would mean that any and all browsers derived from WebKit would have all of the same basic capabilities, and at the same level, as Chrome itself.
Or, Google could use it as an excuse to proprietize its work by forking, thus ensuring that any future stream of enhancements made to the browser would only benefit Google and Chrome instead of everybody.
In the end, Google decided that the only thing it cared about was itself:
"However, Chromium uses a different multi-process architecture than other WebKit-based browsers, and supporting multiple architectures over the years has led to increasing complexity for both the WebKit and Chromium projects. This has slowed down the collective pace of innovation - so today, we are introducing Blink, a new open source rendering engine based on WebKit."
So remember, when Google made a proprietary technical leap in an otherwise open source project, it was Apple, not Google, who made sure that everyone could benefit from the same technical leap. And when it became too difficult to maintain two versions, it was Google, not Apple, who forked the engine and the community in order to proprietize improvements for their own gain.
--
[1] https://lists.webkit.org/pipermail/webkit-dev/2010-April/012... [2] https://blog.chromium.org/2013/04/blink-rendering-engine-for...
This is a bit of a silly narrative built on what's basically different architectural decisions. Chrome embedding was intended to be through CEF (which was fully multi-process), while WebKit through WebCore.
You could just as easily say that Apple decided not to do the hard work of migrating Chrome's multi-process architecture into WebKit and instead made a hard break and just started landing incompatible changes. From the thread you posted, you can even see a WebKit embedder at KDE blindsided by the news[1].
But in reality, browsers are hard, and in a way WebKit and Chrome were always forks but with shared components. The Blink fork was just a fork of one of the biggest of those components and a formalization of what was pretty much always the case by moving to separate source control, code review, etc.
[1] https://lists.webkit.org/pipermail/webkit-dev/2010-April/012...
When Firefox was new, it was trivial to embed Gecko. There was an ActiveX-Widget that you could just drag to your VB or C# form and get a browser. There were also a bunch of browsers which were just wrappers around Gecko (K-Meleon or Galeon). It was also possible in other environments, though maybe not so easy - StarOffice/OpenOffice included Gecko, too. One reason this was possible is that from the beginning, Gecko was built with components in mind. XPCOM was very much like COM and allowed you to have a stable C++ ABI. Your classes are basically structs with a known memory layout and function pointers, and you use interfaces to access them.
Unfortunately it was a bit overengineered, and component technologies fell out of favor and were removed from many projects (XPCOM, COM, BONOBO, UNO...). I think it was a overreaction to the excesses of object orientation in the 90s- Microsoft is moving back to the opposite direction with WinRT. Anyway, the modularity was removed from Firefox/Gecko on purpose in order to simplify the code.
Webkit comes from a similar heritage (Kparts). I think the reason why there are embeddable Webkit widgets is just because people did the work to create them - QtWebKit, WebView2, ..., not because Webkit is inherently more embeddable. In fact, the multi-process nature causes a bunch of problems. You can't just reach into the DOM from your native code, but you have to inject JS to manipulate it, and so on.
Well, with that said, Mozilla is the wrong shepherd for Firefox given that they laid off 25% of their workforce last year.
Chrome adopted the webkit model of being primarily an embeddable engine, that happened to have a browser as its primary use case. The WebKit framework is used extensively throughout macOS and iOS, across a variety of applications, precisely because the framework is designed as a content view, not as a browser.
> Servo’s mission is to provide an independent, modular, embeddable web engine, which allows developers to deliver content and applications using web standards.
This is servo's mission, on their website, and the last time I checked, they provide absolutely no documentation on how to actually do it.
If you need embedded, just use CEF like everyone else. If you need a browser base, just use Chromium. Everyone else is dicking around.
I would have written a WebKit port[1] for my own purposes, because CEF has significant technical limitations, but WebKit has no documentation on how to do it either. They have documentation on what a WebKit port is, and what ones exist, but not actual documentation on how to create your own callbacks for view abstraction and blitting etc. It's a much more significant effort compared to just using CEF.
[1]: https://trac.webkit.org/wiki/SuccessfulPortHowTo
I've been compiling it locally and playing with it. I run it like:
$ servo https://news.ycombinator.com
To do that, I've got an alias set up to point to my dev build.
alias servo='f() { /home/tychi/SourceCode/servo/mach run --release $1 };f'
The problem is Google is using Chromium dominant market share to push some questionable "features" into standards.
> The fact that Google did such a good job on early chrome compared to everyone else is really why it’s so popular.
Chrome is good, but Google being the largest advertising machine in the world also helps.
You can read Creative Selection by Ken Kocienda to get the backstory on why they chose KHTML over Gecko. You can also Google for podcasts that Don Melton has been on.
For those who don’t know: “they” is Apple here. Apple forked KHTML to create WebKit. Google contributed to WebKit and later forked it into Blink.
The world class team that is responsible for protecting the iPhone protects Chromium.
Are you talking about Google's Project Zero? If so, you can include lots of software with that logic, and it would make even less sense to say that "the world class team that is responsible for protecting Intel processors protects Chromium".
[1] https://www.torproject.org
That was Apple's reported reason for using KHTML and making WebKit which Google used for Chrome and forked eventually. They wanted something light and embeddable. Don't blame them. Also, that software was LGPL.
I was always hoping that Microsoft or Apple would fund the Mozilla Foundation to keep a competitive web engine afloat and prevent Google Chrome engineers from dominating the web. They can take the Firefox code for their closed source software under the MPL.
Really doubt MS is going to do that these days. Kinda hoping Apple does since Safari is often the last to support new web standards. It would take very little of their profit and yet keep a big competitor from dominating a critical function of their most profitable products. This is regardless if they actually use Gecko or Servo.
That's right. And the Safari team chose KHTML despite the presence of Dave Hyatt - a key Firefox developer and creator of Camino browser (which did embed Gecko). That's probably everything one needs to know about how easily embeddable Gecko is.
Where "web standards" are "whatever Chrome does", and written by Chrome devs. There you've also got the reason nobody starts from the FF/Gecko/Servo codebase.