IMHO, 2.5 good engines are enough (webkit, blink, gecko - in the sense that webkit and blink are very similar). We just need more really good browsers which use gecko.
We certainly need more really good browsers which use gecko.
But for that to happen, Mozilla needs to up their effort to pull apart the components, decouple them from their own integration (firefox, thunderbird) and treat them as first-class projects, whose sole focus is to provide browser-builders and such with the components and tools to integrate the pieces.
Purely technical, it's still easier to build around "chrome" components. Which is why everything from electron, via "webviews" to the oculus browser or that webview-thing in your fridge, uses chrome tech and not mozilla. Edit: in an ideal world, it would be a no-brainer for e.g. Meta to pick Mozilla components to build a browser for their VR headset. Or for VW when they develop an in-car screen. Or for an app-builder to add some web-rendering of their in-app help.
But IMO this stems from a fundamental problem with Mozilla. Their cash-cow is firefox. So if they spend time and money making tech that then makes competing with firefox easier, they lose twice. So they will never truly commit to this.
Even if that would, IMO, be one of the most impactful things for Mozillas' manifesto of a "free internet".
It's notable that there's no real nodejs equivalent running on Mozilla tech. I'd love for someone closer to the tech to explain why there's not a rich ecosystem behind spidermonkey, etc.
I am not sure about the current state. But "back then" all the components in Firefox were tightly coupled and almost impossible to extract on their own.
"Back then" being, IIRC, 2012 or so, when I briefly worked on the web and CMS side of a project that used HTML + CSS (and a tiny bit of JS) to render the UI of a media-box. The OS was basically a thing that could boot a "browser" and handle network stuff. Firefox was not an option, as it was near impossible to even remove things like the address bar, tab handling and all that. But the hardware was so underpowered, that a full browser was not an option.
Yet "yet another khtml" wrapped in the most basic "executable" did just fine.
But this is a while ago, and only one project that chose not to use Firefox/gecko.
Their loss lies in the fact that this would enable people to build competitors to firefox, as they would basically make a box of components to do exactly that.
Yet Firefox, the product, is what brings in money. Not the underlying tech.
I remember the good old times when Mozilla had a project named Chrome (yes) to (if my memory serves me correct) make building apps with gecko easier.
edit: Probably misremembering, now that I searched for it. Yes "chrome" was (and still is?) used to describe the non-webview parts of the FF but apparently I totally made up the project part.
Because IIRC in old Mozilla Chrome was a project name that was the UI layer of Firefox. Chromeless basically just mean Firefox without UI for other applications to built on top.
Oh, thanks for the update. I assumed it'd be an incremental departure and that things couldn't have changed so much in 12 years (given the complexity of the browser engines). Now that I've read more about the fork, I learned that the codebases were already significantly different at the time they declared it officially as a fork. Interesting, because it feels like they are very compatible when I'm testing stuff as a developer (apart from their support of new stuff obviously).
