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.

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.

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

Perhaps "vague" is too loaded a word? I did not mean it as an insult or complaint, I was just pointing out the fact that the reasons were unclear because they were mentioned but not described. Twitter's character limit is a perfectly valid reason for that. And the literal meaning of the word "vague" applies perfectly.

> Your "seeming enthusiasm for burning some bridges behind him" is bunk. On what did you base it?

> ...To suggest I did anything uneconomic out of spite is silly.

I was not suggesting that.

Sorry, it seems I did not describe myself well. "Burning bridges" was not a reference to making anti-Gecko technical decisions. It's about unrelated public postings that I object to, but I don't think that here is a place to get into it.

I am confident that the bases for your technical choices were well-founded and I have no reason to suspect that they were made out of spite.

Hi Steve, I read through

https://twitter.com/search?q=from%3A%40brendaneich%20mozilla...

and wondered which ones you meant. If I burned a bridge I should try to rebuild, let me know.

If you mean the ones about Mozilla holding back tracking protection while Monica Chew was there, or the ones about Mitchell's ridiculous salary, then we must disagree on "burning bridges". I'm not going back to Mozilla, and even if I hoped to, I see no reason to lie or self-censor about bad things they did after I left.

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.

I have heard the same from many moons ago that the blink/khtml/webkit engine was designed from the start to be embeddable.

I'm part of the team maintaining the "boot 2 gecko" aka b2g fork (we push it to 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.

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.

I haven't kept up to date. Is Chromium hostile towards ad blocking?

It started with this, but applies to other extensions also:

[1] https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-b...

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