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

[1] https://spidermonkey.dev

[2] https://archlinux.org/packages/extra/x86_64/js78/

[3] https://www.linuxfromscratch.org/blfs/view/svn/general/js78....

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.

https://github.com/mozilla-spidermonkey/spidermonkey-embeddi...

CEF was also relatively straightforward to use. Both times we were embedding them in C++ applications.

https://engineering.mongodb.com/post/code-generating-away-th...

Aside from thread-wrangling I thought it was trvial to embed.

I miss such numbers so much.

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.

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.

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.

https://www.mozilla.org/en-US/foundation/annualreport/2020/

All the "audited financial statements".

It should be the second full-page chart.

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.

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.

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.

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.

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

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.

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

In any case though this would raise the backwards compatibility constraints on Mozilla quite a bit, and I'm not sure whether they'd be willing to take on that burden. Of course even now they can't go around breaking GeckoView-APIs all willy-nilly, but when it does happen, it "only" affects app developers the next time they want to recompile their app with a newer GeckoView version.

If GeckoView was being distributed as an independently, user-installable library instead, any breakage at all becomes a big no-go, because users naturally expect their existing GeckoView-using apps to keep working regardless of which updated version of GeckoView they might happen to install.

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.

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.

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

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

Firefox was born in 2002 (under Eich management) as Phoenix, it's kinda obvious that 16 years later (57 is from 2018, Eich left in 2014) it needed a technological upgrade.

In ~2009-2010 Firefox was used by 33% of the web users.

Today it's at ~6%.

I blame management, the alternative is believing Firefox just had bad luck or that developers at Firefox suck (which they do not)

There are other factors at play than managerial incompetence:

- the entire iOS part of "all web users" uses WebKit because Apple doesn't allow other engines. For Android, most devices ship either Chrome or a WebKit wrapper (the default Android WebView), and many users don't bother switching browsers from the default. As ever more Web usage moves towards mobile, the disadvantage towards Firefox only accelerates - which is part of the reason why Mozilla tried to build a competitor.

- Many users also don't bother very much to switch their desktop browser. Apple users, especially on mobile, tend to stay with Safari as not even Chrome can keep up with the battery life optimizations Apple did, much less Firefox (not to mention Apple probably doesn't even grant non-Apple apps access to entitlements, but that's just guesswork).

- Netflix and other DRM content. A lot of people went to Chrome back in ye olde days when getting Netflix to run in HD resolutions (or at all) was a nightmare on everything sans Chrome (and Internet Explorer), and thanks to inertia (see above) they stayed on Chrome. And I'm not even wishing to fault Mozilla's management for resisting DRM for as long as they did, but in the end customers voted with their download buttons for convenience.

- The desktop users that do switch their desktop browser switch mostly to Chrome because Google blasts out tons of ads to switch to Chrome, not to mention website developers suggesting their users to move to Chrome or outright announcing that bugs involving browsers other than Chrome won't get addressed.

The last thing is undoubtedly the biggest issue - it is impossible to counteract the advertising and other financial firepower of Google. In ye olde times, regulatory agencies should have stepped in long ago to ban the cross-promotion that Google did (similar to the MS judgements), but they didn't and now we're living in a browser duopoly that is rapidly devolving into WebKit monopoly.

I agree there's no single point of failure, but IMO what made Firefox (and Mozilla before it) different was that it was different.

they played catch-up against Chrome with the result that they did not gain new users and lost many of the older ones

I still use Firefox on desktop, but on mobile first they removed the extensions from their mobile browser, then announced they would only support WebExtensions API, removing a ton of features from existing extensions, then they started purging "controversial" extensions (as in controversial in the eyes of Google) from their addons web site, that basically made Firefox a worse Chrome.

The nails in the coffin for me have been laying off the entire devtools, MDN and servo development teams and the ads in the search bar.

All of this started happening soon after Eich left.

I'm not saying Eich alone could save Firefox, he's also a person I dislike on a human level and he's probably more troubles than he's worth for a company, but my opinion is that Firefox "new" mindset post Eich disappointed its true fans that were mainly developers and you don't recover from that.

EDIT: I understand the need to make money, but are Pocket Premium or reselling VPNs the right way for a browser vendor?

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

I repeat it: I don't like Eich, I don't like his opinions, but he never laid off entire dev teams, he used his personal money to support his personal world view, it has nothing to do with what people at Mozilla could or couldn't do.

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

Is it better if your righteous new CEO fires you?

Because someone supports creating new laws for other kinds of marriage than traditional doesn't mean that they hate or want to limit the rights of some groups.

Eich donated significant sums of money to LGBT organizations both before and after the voter referendum.

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

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

Different design priciples

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.

But the "embedding gecko is hard, embedding chromium is easy" explanation certainly seems to be wrong, in terminology at least.

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

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?

I'd like to see citations on that - AFAIK (my opinion is as baseless as yours) FF is plenty fast on desktop, and there is nothing inherently less secure about it than Chrome.

I do use Vivaldi (based on Chromium) on Android, but I consider Firefox Mobile and Desktop to be separate products.

Good news is, there is research that finds the Rust components of Firefox have much less memory safety bugs. Bad news, moco is not investing in Rust very much at all, anymore.

How can it be less secure and the browser you choose for privacy reasons only?

Not the guy but a quick search pulls up a press release for that day which was the release of Firefox v4.0 and mentions the 'new' rapid release cycle. I'm assuming it was this last that they were referring to.

Link: https://blog.mozilla.org/press-uk/2011/06/21/mozilla-deliver...

That's not what "viral" means. MPLv2 cannot "infect" your own code like the GPL can just by virtue of using the library.

The only condition is if you want to make modifications to MPLv2 licensed code files, you do have to retain the license on all contributions.

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

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.

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.

Quick googling (not any in-depth knowledge) tells me that WebKit is for Linux too, I cannot find out anything about Windows.

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.

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.

Even the former CEO of Mozilla who left and created the Brave browser decided to go with Chromium.

Right now- the only browser engines seeing a lot of action are Chromium and WebKit. Every browser is being built on one of these two engines.

I suspect even Firefox will switch over to gain the benefits of one of those engines and the number of people working on them.

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?

This would mean that there is only one engine that needs to keep up to date with the html/JavaScript spec and then browsers would then be competing on features rather than if a web site will render correctly.

It’s a bit easier nowadays but still in no way portable for suitable embedded use.

Great for woke bs, not so great for actually funding and developing browser.

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

It died when XulRunner died, and none of the followon attempts survived.