5 ms·

>Why are there not more successful forks of Firefox? [...] What's preventing other forks from taking off Some of the replies to your question state "money" but

by jasode 5y ago

>Why are there not more successful forks of Firefox? [...] What's preventing other forks from taking off Some of the replies to your question state "money" but there are also more fundamental reasons of choosing Chromium over Gecko: technical functionality and performance (especially on mobile). You'd think an ex-Firefox programmer and Mozilla co-founder such as Brendan Eich would have chosen Gecko for Brave but he didn't. He explains in a previous comment why he switched from Gecko to Chromium: https://news.ycombinator.com/item?id=22062636 https://news.ycombinator.com/item?id=22062636 So the "hidden" reason people are not comfortable saying (except maybe Brendan Eich) is that Gecko isn't as good as Chromium as a foundation for forking. That's why you get a bunch of companies independently choosing Chromium instead of Gecko such as : - Github Electron based on Chromium - Qt QtWebEngine uses Chromium - Opera Vivaldi switches from Presto to Chromium - Microsoft Edge switches from Trident to Chromium - Brave switches from Gecko to Chromium Some speculate Gecko's MPL license instead of Chromium's BSD might also be a factor.

severine 5y ago
I'm a longtime Firefox user and advocate, but this feels mostly right.
LargoLasskhyfv 5y ago
I neither want nor need DRM to work. I'd rather have the ability of ad-blocking and similar extensions to work on a deeper level, instead of crippling them, like on chromium-based browsers. What about mono-culture and the risk there of? edit: Availability of working DRM is what it all boils down to.
- dmos62 5y ago
  I haven't kept up to date. Is Chromium hostile towards ad blocking?
  - LargoLasskhyfv 5y ago
    It started with this, but applies to other extensions also: [1] https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-best-on-Firefox https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-b...
sfink 5y ago
If you read that tweet, it mainly says that they made the choice based on DRM licensing. Well, plus a vague "it lost on many dimensions in a head to head comparison enumerating gaps vs. Chrome". Which I can't argue, because there are no specifics to disagree with. That said, I work on Gecko and it is indeed an old crufty codebase with numerous issues. From what I've seen of Blink, it seems surprisingly similar (overall; the specific problem areas are different). And Gecko has a surprising willingness to rewrite or revamp core aspects of the codebase -- by some metrics, it appears to be more nimble than Blink (eg, site isolation to separate processes was a massive project for both codebases, and it looks like although Gecko started and finished later, the elapsed time is a couple years less.) On the other hand, Eich was pretty well in touch with the Gecko codebase, so his opinion should carry some weight. (Somewhat counterbalanced by his seeming enthusiasm for burning some bridges behind him, but that gets into very speculative territory.) I tend to agree that Gecko isn't as good as Chromium as a foundation for forking, though. I think working with the Mozilla development community is actually quite a bit better than working with Chromium's, but Gecko is pretty unapologetically focused on Mozilla's product needs and Mozilla doesn't have the resources to properly support external embedders or forks.
- toyg 5y ago
  The continuous struggle to get Gecko used by any non-Mozilla project should also carry weight: there are many reasons why Apple went with the arguably-inferior KHTML engine when they started their own browser, and why the resulting library was quickly adapted all over the world - when arguably Gecko had had by then a headstart of a decade or so. Reportedly, embedding WebKit in one's codebase was basically trivial, whereas with Gecko was almost impossible.
  - stjohnswarts 5y ago
    I have heard the same from many moons ago that the blink/khtml/webkit engine was designed from the start to be embeddable.
- BrendanEich 5y ago
  DRM was not the main issue we faced, just one of many. I wasn't vague, Twitter limits size to 280 chars. We developed a decision spreadsheet with the data in almost all the rows weighing against Gecko. Your "seeming enthusiasm for burning some bridges behind him" is bunk. On what did you base it? Again, we started Brave based on Gecko (multiprocess sandboxed embedding via Graphene, which was developed for FirefoxOS). We did not just jump to Chromium upon founding. A startup is a no-BS/little-room-for-error setting with scarce capital. To suggest I did anything uneconomic out of spite is silly.
fabrice_d 5y ago
I'm part of the team maintaining the "boot 2 gecko" aka b2g fork (we push it to https://github.com/kaiostech/gecko-b2g https://github.com/kaiostech/gecko-b2g) so I have some experience building a non-firefox product on top of gecko, and maintaining a non-upstream platform (the "android without java" stack called Gonk). At some point we compared gecko with a blink port on Gonk, maintaining both while we were doing performance comparison on low end mobile devices. We were looking both at memory usage and page loading speed. I was expecting to see blink way ahead of gecko, but that was not the case at all. For some content blink was a bit better, for some it was gecko, but never with a large gap either. Maintenance of the blink product was not easy, with barely documented internals changing a lot (it's very different to build a new product on top of blink compared to just fork an existing one like chromium). I'm not blaming the blink team, that makes sense in the context of what they do, and we were not as familiar with blink code base as with gecko. Finally we stayed on gecko because this was the best choice for us (eg. including team velocity and the amount of non standard apis to rewrite). In my opinion if you want to start on a new browser product, the main Chromium benefits for a commercial project are: - web compat, which unfortunately is self sustaining. - licensing. The MPL vs. BSD doesn't matter for open source projects, but many companies (especially VC funded) are adverse to copyleft licenses. Gecko's xpcom architecture was actually not a bad fit with the MPL, since you can ship new xpcom components without publishing their code if you don't want, but that didn't make much of difference (some chipset vendors used the capability for FirefoxOS to replace the implementation of telephony apis with closed source ones). But you need to be comfortable being subject to the whims of google (and a little bit MS now). For instance, consider the changes to web extension resource blocking capabilities with the "manifest v3": some forks plan to keep the resource blocking api working, but it's very unclear if they will be able to do so in the long term without a growing complexity of their fork that may become too high. If you are an open source project, please don't cement Google's dominance of the web by using chromium. Gecko deserves to have a future - it may just not be Mozilla's corp current leadership that is the best for that to happen.

by jasode 5y ago

severine 5y ago

I'm a longtime Firefox user and advocate, but this feels mostly right.

LargoLasskhyfv 5y ago

I neither want nor need DRM to work. I'd rather have the ability of ad-blocking and similar extensions to work on a deeper level, instead of crippling them, like on chromium-based browsers. What about mono-culture and the risk there of? edit: Availability of working DRM is what it all boils down to.

dmos62 5y ago
I haven't kept up to date. Is Chromium hostile towards ad blocking?
- LargoLasskhyfv 5y ago
  It started with this, but applies to other extensions also: [1] https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-best-on-Firefox https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-b...

sfink 5y ago

If you read that tweet, it mainly says that they made the choice based on DRM licensing. Well, plus a vague "it lost on many dimensions in a head to head comparison enumerating gaps vs. Chrome". Which I can't argue, because there are no specifics to disagree with. That said, I work on Gecko and it is indeed an old crufty codebase with numerous issues. From what I've seen of Blink, it seems surprisingly similar (overall; the specific problem areas are different). And Gecko has a surprising willingness to rewrite or revamp core aspects of the codebase -- by some metrics, it appears to be more nimble than Blink (eg, site isolation to separate processes was a massive project for both codebases, and it looks like although Gecko started and finished later, the elapsed time is a couple years less.) On the other hand, Eich was pretty well in touch with the Gecko codebase, so his opinion should carry some weight. (Somewhat counterbalanced by his seeming enthusiasm for burning some bridges behind him, but that gets into very speculative territory.) I tend to agree that Gecko isn't as good as Chromium as a foundation for forking, though. I think working with the Mozilla development community is actually quite a bit better than working with Chromium's, but Gecko is pretty unapologetically focused on Mozilla's product needs and Mozilla doesn't have the resources to properly support external embedders or forks.

toyg 5y ago
The continuous struggle to get Gecko used by any non-Mozilla project should also carry weight: there are many reasons why Apple went with the arguably-inferior KHTML engine when they started their own browser, and why the resulting library was quickly adapted all over the world - when arguably Gecko had had by then a headstart of a decade or so. Reportedly, embedding WebKit in one's codebase was basically trivial, whereas with Gecko was almost impossible.
- stjohnswarts 5y ago
  I have heard the same from many moons ago that the blink/khtml/webkit engine was designed from the start to be embeddable.
BrendanEich 5y ago
DRM was not the main issue we faced, just one of many. I wasn't vague, Twitter limits size to 280 chars. We developed a decision spreadsheet with the data in almost all the rows weighing against Gecko. Your "seeming enthusiasm for burning some bridges behind him" is bunk. On what did you base it? Again, we started Brave based on Gecko (multiprocess sandboxed embedding via Graphene, which was developed for FirefoxOS). We did not just jump to Chromium upon founding. A startup is a no-BS/little-room-for-error setting with scarce capital. To suggest I did anything uneconomic out of spite is silly.

fabrice_d 5y ago

I'm part of the team maintaining the "boot 2 gecko" aka b2g fork (we push it to https://github.com/kaiostech/gecko-b2g https://github.com/kaiostech/gecko-b2g) so I have some experience building a non-firefox product on top of gecko, and maintaining a non-upstream platform (the "android without java" stack called Gonk). At some point we compared gecko with a blink port on Gonk, maintaining both while we were doing performance comparison on low end mobile devices. We were looking both at memory usage and page loading speed. I was expecting to see blink way ahead of gecko, but that was not the case at all. For some content blink was a bit better, for some it was gecko, but never with a large gap either. Maintenance of the blink product was not easy, with barely documented internals changing a lot (it's very different to build a new product on top of blink compared to just fork an existing one like chromium). I'm not blaming the blink team, that makes sense in the context of what they do, and we were not as familiar with blink code base as with gecko. Finally we stayed on gecko because this was the best choice for us (eg. including team velocity and the amount of non standard apis to rewrite). In my opinion if you want to start on a new browser product, the main Chromium benefits for a commercial project are: - web compat, which unfortunately is self sustaining. - licensing. The MPL vs. BSD doesn't matter for open source projects, but many companies (especially VC funded) are adverse to copyleft licenses. Gecko's xpcom architecture was actually not a bad fit with the MPL, since you can ship new xpcom components without publishing their code if you don't want, but that didn't make much of difference (some chipset vendors used the capability for FirefoxOS to replace the implementation of telephony apis with closed source ones). But you need to be comfortable being subject to the whims of google (and a little bit MS now). For instance, consider the changes to web extension resource blocking capabilities with the "manifest v3": some forks plan to keep the resource blocking api working, but it's very unclear if they will be able to do so in the long term without a growing complexity of their fork that may become too high. If you are an open source project, please don't cement Google's dominance of the web by using chromium. Gecko deserves to have a future - it may just not be Mozilla's corp current leadership that is the best for that to happen.