Ask HN: Why do new browsers use Chromium instead of Firefox as their base?

[josemando]

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?

[BlackLotus89]

Gecko and servo are both not easily embeddable.

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...

[thayne]

That non embeddability is probably also a major reason why there isn't a significant node competitor based on spidermonkey. I get wanting to focus on Firefox as a whole, and that making components more independent can add quite a bit of work. But at the same time, if it was easier to use gecko in other browsers, and spidermonkey as JS environment outside the browser, I wonder if that would increase usage of and interest in the underlying technology.

[ramesh31]

>since mozilla fired the servo team there is no certain future for it anymore.

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.

[vhab]

Early attempts at embedding browsers in games were based on Gecko as well.

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.

[jeffparsons]

It seems like everyone has reached much the same conclusion: there may be many factors, but the real killer and root cause is that Chromium is well suited to being embedded, and Gecko is not.

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.

[bostik]

> root cause is that Chromium is well suited to being embedded

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.

[captainmuon]

> the real killer and root cause is that Chromium is well suited to being embedded, and Gecko is not.

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.

[pvg]

real killer and root cause is that Chromium is well suited to being embedded, and Gecko is not.

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.

[tyingq]

>Consider funding work to make Gecko better suited to embedding

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.

[88913527]

If not even Microsoft is willing to make that investment (given its vast resources), it's unlikely any smaller players would. I agree with the sentiment (diversity is good), but it's extremely expensive to build a browser. Maybe that's the real issue.

[mook]

My understanding was that, something like a decade ago, Qt tried that. Fresh embedding API and everything. Maybe it's fine to try again? Maybe Mozilla will be more receptive this time…

[JohnWhigham]

Consider funding work to make Gecko better suited to embedding.

Well, with that said, Mozilla is the wrong shepherd for Firefox given that they laid off 25% of their workforce last year.

[jcmontx]

Could someone explain what _embedding_ means in the context of web browsers? Thanks

[pcwalton]

As an engine, Chromium has overwhelming market share, so it decreases risk to build on top of it. Choosing an alternative browser engine increases risk.

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.

[dfabulich]

> Embeddability has little to do with it; Chromium (as opposed to WebKit) isn't actually that embeddable.

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.

[toyg]

You have your cause and effect backwards. That market share was achieved in large part by ease of embedding. Google itself started the project on WebKit because it was easier to embed and manipulate than anything else, and were pretty careful to allow others to do the same one level higher up the stack (i.e. making it easy to build your own branded browser on top of Chromium).

[jupp0r]

There is the Chromium Embedded Framework which makes it somewhat easy to embed Chromium: https://github.com/chromiumembedded/cef

[commoner]

While embedding Gecko in desktop applications is not as straightforward as embedding Chromium, Mozilla's GeckoView project makes it easier to do this on Android:

https://mozilla.github.io/geckoview/

GeckoView is the foundation of Firefox for Android and Firefox Focus. The SmartCookieWeb-Preview browser, which supports sideloading Firefox extensions on Android, is also based on GeckoView:

https://github.com/CookieJarApps/SmartCookieWeb-Preview

[iggldiggl]

But then again on Android the OS already provides a Webview implementation for usage by apps, so while on Android Gecko might be more easily emebeddable than on Desktop, it's then hobbled by the fact that on Android the choice for app developers is either using the default Chrome/Blink-based Webview provided by the OS at absolutely no size-penalty, or else thinking about shipping a full browser engine with your app at a size penalty of dozens of MB, at which point you might then consider possibly using GeckoView instead of shipping your own specific version of Blink.

[csdreamer7]

As others have said; Gecko and Servo are not easily embeddable.

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.

[starik36]

> Gecko and Servo are not easily embeddable.

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.

[tannhaeuser]

> Safari is often the last to support new web standards

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.

[pkaler]

Chromium embeds the Blink browser engine which is a fork of WebKit which is a fork of KHTML.

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.

[Someone]

> on why they chose KHTML

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.

[andrewmcwatters]

I had a conversation here with people about Servo and it was immediately clear that it was a collection of people who wanted to play around with Rust and not actually solve a problem that people have while saying that they did. They were way more concerned with bullshit like governance than meat and potatoes like writing a getting started article.

> 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

[tylerchilds]

The documentation on how to run it is in the readme. They've only got pre-release builds available on their website, since the tech isn't production ready yet.

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'

[pvg]

One reason is that Firefox is an older browser design (compared to Chrome), in parts retrofitted. That's a difficult, laborious rut to get out of, especially if your competition has more resources and a big head start. If you're starting a new browser variant, it doesn't make much sense to also start with Mozilla's disadvantage.

[shadowgovt]

Chrome was architected specifically to overcome the shortfalls of the IE and Firefox engines at the time. Firefox has not only been playing catch-up, it's been playing catch-up against specifically its greatest weaknesses.

[daoismyname]

It's what happens when you fire you engineer CEO for his personal opinions (that I disagree with) and replace him with a "company culture" that has nothing to do with engineering, but has the "right" opinions.

[Barrin92]

Firefox became competitive again on a technical level after the overhaul with 57 long after Eich was gone, and under Eich the browser was already in a steady state of decline for a long time both technologically and in terms of usershare.

Trying to ride old stereotypes about engineers and management that has nothing to do with facts is pretty cringeworthy.

[gilrain]

I mean, they had an internal employee revolt, since his “personal opinions”, opinions backed by cash, were that those employees should have their human rights limited.

You can’t lead effectively if the people you are trying to lead justifiably view you as hostile to them.

[loganmarchione]

At this point, more people are using Chromium, so more devs target it, so more browsers are based on it. However, in the beginning, Firefox’s engine (Gecko) was harder to embed than Chromium’s engine (Blink).

https://www.reddit.com/r/firefox/comments/m8cwdu/why_arent_t...

[gbraad]

The Mozilla rendering engine (gecko) was never meant to be embedded in the same way webkit is. It changed a little with Fennec and firefox. The engine became leaner... Yet still it isn't easy to reuse.

Even spidermonkey, the javascript engine, is never reused as v8.

Different design priciples

[dralley]

>Even spidermonkey, the javascript engine, is never reused as v8.

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.

[josemando]

But aren’t Brave, Edge and Opera based on Chromium instead of only Blink? Am I missing something?

[BrendanEich]

Brave started in 2015 on Gecko, using Graphene (FirefoxOS multiprocess/sandboxed app framework). We switched by end of year due to too many gaps (HTML5 DRM was a big one) and incompatibilities (mobile, mostly). Big spreadsheet, most rows netted out negative for Gecko. No way to change now, and a worse bet now based on Mozilla fundamentals.

[pipeline_peak]

I think Chromium’s performance contributed a lot to its dominance. Browser distributions have to build off of it to be relevant.

Other than Ekioh’s Flow, I don’t know any other competitive attempts from companies building browser components from scratch.

[olliej]

The aggressive advertising on many of the most popular sites on the web also helped a lot, the occasional accidental breakage of other browsers on those same google properties also worked out in their favor.

[tata71]

Performance & security, easy choice.

[novok]

I only use firefox because of it's multi-account container capabilities and some other better privacy features, which is more to do with it's wrapper vs. it's actual engine. Someone could make multi-account containers or better with chromium, and if they did I would just use that instead.

Otherwise firefox is a slower, less secure browser and an older more crufty codebase and less webdevs test it thoroughly. Why would I choose it as a new browser wrapper developer ever?

[causi]

On June 21st, 2011 Mozilla decided that Chrome would lead and Firefox would follow. Almost every single change to Firefox since then made it more similar to Chrome, not less. If you're making a browser, you follow the leader, not the first follower.

[edoceo]

What happened on that day? Is there more historical details?

[luka-birsa]

We had to choose between Webkit and Gecko. For us it was primarily the license, which was GPL vs MIT. Gecko was a non starter.

[pentagrama]

I'm wondering, Tor [1] is a Firefox based browser in the same sense as Edge/Brave/+ are based on Chromium?

[1] https://www.torproject.org

[baq]

Servo should be developed for taxpayers money just to keep Google honest.

[victorbstan]

Wasn’t chromium based in WebKit? Same as Safari. Basically Apple forket webkit to make safari and Google forked WebKit to make chromium. I really don’t see what the hubbub is about trying so hard to have gecko, webkit, etc. rendering engines out there. If the end goal is standards compliance, the outcome should be the same. The fact that Google did such a good job on early chrome compared to everyone else is really why it’s so popular. Ultimately it’s open source. I think chromium could become more popular than it is, if they upped their marketing and made access to up to date binaries as frictionless as possible for as many platforms as possible.

[robertoandred]

Apple forked KHTML to make WebKit, which it used to make Safari. Google originally used WebKit to make Chrome, but then forked WebKit to make Blink, which it uses for Chrome now.

[dikei]

> If the end goal is standards compliance, the outcome should be the same.

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.

[shp0ngle]

That's simple. Gecko is awful to embed and use independently of Firefox.

Now my question would be why not WebKit, as that is also easy to embed. There are browsers that use WebKit, just not that many.

[dragonwriter]

> Now my question would be why not WebKit, as that is also easy to embed. There are browsers that use WebKit, just not that many.

Wasn’t part of the WebKit/Blink split that Google cared about supporting non-Apple platforms and Apple didn’t want to anymore, (and the reverse on a number of Apple-priority features), and both sides purged their post-split engine codebases of the stuff they weren’t supporting, making post-split WebKit very much not suited to non-Apple platforms.