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?
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...
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.
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.
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...
[2] https://archlinux.org/packages/extra/x86_64/js78/
[3] https://www.linuxfromscratch.org/blfs/view/svn/general/js78....
Aside from thread-wrangling I thought it was trvial to embed.
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.
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.
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.
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?
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)
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.
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.
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.
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.
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:
> 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.
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'
Other than Ekioh’s Flow, I don’t know any other competitive attempts from companies building browser components from scratch.
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...
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.
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?
I’ve long resisted using a Chromium browser but Firefox has languished for far too long. I’ve been using Arc for maybe half a year now and I don’t plan on going back.
Without a team working on Servo, Mozilla is lost IMO.
Great for woke bs, not so great for actually funding and developing browser.
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".
First, why cannot we have a multi-platform single click, no chrome/ui with fullscreen capabilities, firefox launcher that has prepackaged web app that is self contained? You think Major Tech Dudes can’t implement this?
Second, it’s all probably to do with bureaucracy and politics. For all we know FAANG blocks such ad ventures otherwise its bully time.
It died when XulRunner died, and none of the followon attempts survived.
https://www.reddit.com/r/firefox/comments/m8cwdu/why_arent_t...
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.
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.
I would flip that and say Mozilla would be better off if they just adopted Chromium and made sure they provided builds without the controversial stuff.
They gave up on having a competitive rendering engine implementation when they abandoned Servo so why bother ?
Who is using FF for the rendering engine ? If anything it just breaks compatibility because few test for it anyway. They even fired the devtools team so developing for FF is worse than Chrome.
If they created a Chromium distro that was cleaned up for privacy it would probably be a better product than what they have right now.
