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

[toyg]

Yeah, WebKit really tilted the scale. KHTML had been built to be easily embeddable already (since it was supposed to be used across the whole KDE desktop, following what MS had done with "Active Desktop" in Windows 2000/XP), and Apple gave it the polish and popularity to make it the obvious choice. Any org or ecosystem who needed a rendering engine rushed to wrap WebKit, and that included Google.

[darklion]

> Then quite some time later, frustrated by Apple's control over the engine, Google forked WebKit and came out with Blink.

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

[magicalist]

> In other words, Google's main technical advantage would be baked into the browser engine itself and made available for everybody.

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

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

[toyg]

> Somewhat unobviously, this turned out not to be a great way to build a browser

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

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

[ameliaquining]

I think the suggestion being made here is that if somebody else did that work, they might be willing to merge it into their tree.

[staticassertion]

Has Mozilla showed any reason to bet on them in the last decade? It seems like leadership is happy to sink the company and take bonuses paid for by donations along the way.

I'd rather see a new player in the space. I have no confidence in Mozilla.

[tvanantwerp]

If a 501(c)(3) non-profit receives a donation for a specific project, by law they cannot direct the funds toward anything else unless the donor releases the funds for another purpose. This is more of a thing with large donations than, say, a recurring $10/month. If a small-dollar donor tried to restrict their funding, the non-profit would probably ignore the restriction because the donor has no leverage to find out if their instructions were followed.

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.

[eklavya]

This is the reason I stopped donating and stopped using Firefox. They won’t give up control and I don’t want a cent sent to anything but firefox/rust.

[drdec]

I think you would have to be funding a fork. I would point to LibreOffice and OpenOffice as an example.

[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

[nicoburns]

Including as a library rather than running as a complete program.