[GeneralMaximus]

I've always wondered why Mozilla doesn't make it easier to embed Gecko everywhere it possibly can. If Electron was built with Gecko, it would go a huge way towards preventing Chrome from becoming the de-facto way of accessing the Web.

As you said, this is too little, too late. I'm a Firefox user, but Chrome has pretty much won the browser wars. The only thing preventing it from achieving complete market dominance is the existence of Mobile Safari.

[roca]

Supporting embedding well is a lot of work, both to create the APIs and then deal with their constraints as the browser evolves. Mozilla has always been under-resourced compared to the competition (IE, then Chrome) and taking people off improving Firefox/Gecko to work on embedding never made the cut. I don't really regret those decisions.

What made it extra unappealing for Mozilla was that we knew the Firefox/Gecko architecture needed lots of work that would destabilize an embedding API. Not much point in supporting an API that assumes single-process while you're moving to multi-process, or that exposes XUL which you know is a dead end, or that isn't compatible with off-main-thread rendering or GPU rendering, etc. Things are much better now that a lot of that debt has been paid off.

[asiachick]

There's nothing stopping a 3rd party from making an Gecko version of Firefox. Electron is not run by Google nor the Chromium team. It's run by github (which only recently became Microsoft)

That said, I'm not sure what the point is. I believe (but could be wrong) that Chromium has more features that Gecko doesn't? So if you're choosing one over the other I'm only guessing most people would choose Electron

[sanxiyn]

"Electron for Gecko" was in fact done. See Positron discussion below.

[roca]

I don't have any direct insight into why the Atom people chose Chromium but I can see a few reasons that are more likely than "features":

-- Chromium was faster. (For Electron apps you don't really care about Web compat, where Firefox was ahead of Chromium for a while, but you do care about performance.)

-- Chromium was already multiprocess and had some other architectural advantages where Gecko was still catching up. So, less upcoming architectural churn.

-- Chromium had Google's resources committed to it. (Google's shine has worn off a bit since then but it's still a powerful effect.)

[pcwalton]

Yep, and even now, the Fission (site isolation) work is still causing a ton of architectural churn everywhere.

[smnthermes]

> Mozilla has always been under-resourced compared to the competition (IE, then Chrome) and taking people off improving Firefox/Gecko to work on embedding never made the cut.

Yeah, sure, imitating your competition is the right way to handle that. /s

References:

1. https://www.dedoimedo.com/computers/firefox-addons-future.ht...

2. https://www.dedoimedo.com/computers/firefox-disable-australi...

3. https://www.dedoimedo.com/computers/firefox-29-sucks.html

4. https://www.dedoimedo.com/computers/firefox-suckfest.html

[roca]

Moving away from the unsustainable XUL extensions model ("no stable API boundary, just feel free to poke the internals of Firefox any way you like") was another piece of architectural churn that had to happen.

[jefftk]

> If Electron was built with Gecko, it would go a huge way towards preventing Chrome from becoming the de-facto way of accessing the Web.

People coding specifically to Chrome when writing Electron apps is way less harmful to the web than people doing the same with web pages. The latter case specifically hurts other browsers, because people who don't use Chrome can't use the site.

Additionally, each Electron app represents a (smallish group of) developers. They're a very small number compared to all the developers writing public-facing websites that (should!) work in all commonly used browsers.

[thawaway1837]

It makes a difference though. The fact that Chromium is Electron’s backend is why MS picked Chromium to base Edge off. It’s likely they would have chosen something else if that wasn’t the case (or maybe continued with their own web tech).

[jefftk]

> It’s likely they would have chosen something else if that wasn’t the case

Brave is run by ex-Mozilla folks and started with Gecko, but switched to Blink very early on. [1] Their reasons didn't include Electron, so Microsoft's may not have either.

[1] Collection of tweets, and a response from someone at Brave: https://www.reddit.com/r/BATProject/comments/9jpqde/brave_br...

(Disclosure: I work for Google, though not on Chrome. Speaking only for myself.)

[roca]

> The fact that Chromium is Electron’s backend is why MS picked Chromium to base Edge off.

What evidence do you have for this?

AFAIK the main reason why Microsoft picked Chromium is that Web sites are pretty much guaranteed to work well in Chromium without Microsoft having to do any work.

[leeoniya]

> What evidence do you have for this?

they stated that their experience with CEF (Chromium Embedded Framework) was instrumental in their decision.

VSCode (built on electron) was probably the main PoC for them.

[roca]

OK. I doubt the absence of CEF would have changed their decision though.

[alibert]

Not strictly evidence but look like MS is working to have a shared base install of Electron on Windows.

https://docs.microsoft.com/en-us/microsoft-edge/hosting/webv...

[roca]

FWIW that is apparently for "rendering Web content" inside a Windows application, and that's what the examples do; not clear to me that it's exposing Electron.

[Ygg2]

Electron is nice for a quick and dirty app. Sadly, people think it's ok to use it for making apps that people are going to use.

What I mean by this - I can recognize a non-Elector vs Electron app by the amount of RAM it consumes. Is your simple color picker/text editor/REST caller/mouse config/ToDo app taking 1GB+ of RAM? It's an Electron app.

For the record, I doubt FF based app would face much better.

[bombela]

And the CPU usage spike as you type into a simple textbox. Without even looking at RAM usage. Text input lag and UI slowness gives it away at the first interaction.

At this point, I could almost tolerate the wasted RAM and CPU if interaction latency wasn't that bad.

[Ygg2]

Well you gotta shuffle those GBs.

[arghwhat]

Mostly because it is a lot of work and tends to lead to new and exciting compromises.

This is for example why Chrome decided to fork WebKit.

(I do believe that people messed around with Electron drop-in replacements, but it's probably hard to sell if it doesn't bring anything new to the table.)

[alexlarsson]

It is expensive, but also it is a competitive advantage (of sorts), as we can see with electron. At the end of the day its just a strategic decision Mozilla made to focus on the application itself.

[dhruvkar]

>> Chrome has pretty much won the browser wars

Probably the same could have been said about IE ~20 years ago.

This is less of a war, more of a never-ending race. Currently (temporarily?) Chrome is ahead.

[Scaevus]

Considering the potential performance issues of Electron apps, I am still hopeful that someone can come up with an Electron alternative with the right engine, but I don't know if that engine is Gecko or not.

[fouc]

It was funny when I realized that mobile-first also means safari-first for the iOS world.

[slightwinder]

> I've always wondered why Mozilla doesn't make it easier to embed Gecko everywhere it possibly can. If Electron was built with Gecko, it would go a huge way towards preventing Chrome from becoming the de-facto way of accessing the Web.

On desktop Mozilla did that: https://en.wikipedia.org/wiki/XULRunner

It was quite successful und I never understodd what happend for them to abonded it and let mozilla run down so deep into s* as it is now.

[duskwuff]

"Quite successful" is perhaps an exaggeration. Most of the projects using XULRunner were directly related to the Mozilla project (forks of Mozilla Navigator and Composer, Thunderbird, Chatzilla, etc). There are very few projects which independently chose to use XULRunner.

https://en.wikipedia.org/wiki/Category:Software_that_uses_XU...