Hacker News Reader

Comment by cxr | Hacker News Reader

The undue focus and almost wistful romanticization/fetishization of Servo is frankly weird, especially when it comes from people with only a tenuous grasp of (let alone hands-on relationship with) browser engine internals. I'm talking about tech news writers and kind-of-but-not-really technical commenters on e.g. Reddit who confabulate their own lore in the spirit of those press accounts, etc.

Firefox uses Gecko as its browser engine. The worthwhile parts of Servo are already in Firefox by way of Gecko. Servo is not The Answer to all of life's problems.

Or, to answer your question more bluntly: "No. Stop asking."

View on HN

> Firefox uses Gecko as its browser engine. The worthwhile parts of Servo are already in Firefox by way of Gecko.

And Gecko has been notoriously unembeddable. Which kinda helped the whole CEF spread.

Not to mention Mozilla basically kneecapped Servo and Firefox by firing most of its devs in a purge.

Mozilla needs to hear this more often.

There is only one browser, because browsers need to be embeddable, and Firefox isn't.

Interesting to work through that

On its face, it's a tough sustainability position for an org of Mozilla's size b/c browser revenue - today - is from controlling the search bar (and maybe now payments APIs?). By making Firefox embeddable, Mozilla gives that revenue to whoever is doing the embedding. Ex: Brave <> Chrome engine.

Building for embedding developers can be super distracting if no sustainability, which isn't a problem for Google: They still make money from embedding by owning the embedding environments like Android. AFAICT, Mozilla failed to land in sizeable markets there. They tried to own & partner in the embedding envs -- e.g., FirefoxOS -- so maybe the trick is to get a more generous rev share for phone vendors wanting to break free of Google? Historically didn't seem to really work out, but maybe genAI w/ consumer/prosumer-grade UIs is reopening that door.

Evolutions like that in turn may take quite an engineering & culture rethink as well, not easy to turn such a big & decentralized ship. I'll keep rooting for them!

I’m not well-versed on the internals of FirefoxOS, but I’m not sure it really counts as embedding because to my understanding, the entirety of the user-facing UI was built with Gecko. Embedding entails usage of the engine with unrelated toolkits, e.g. AppKit/UIKit or GTK.

If that’s true, then Mozilla wouldn’t have been making money from Gecko’s ability to embed with FirefoxOS unless the project took a sharp corner and changed UI toolkits.

The FirefoxOS scenario would be Gecko embedding in FirefoxOS, so Mozilla is their own customer, and makes $ by being the controller of FirefoxOS - OS search, and configuration of browser search

It's less likely the handset manufacturer would be able to change search bar defaults in those scenarios, at least without a stronger profit sharing negotiation, as they'd probably be already negotiating a more careful licensing & teaming agreement

I was part of Mozilla back then. I think we were already talking about making Gecko embeddable in __2003__.

But then… looot of things happened, other priorities, competition, bad decisions, etc etc.

Arguably neither is Chrome. Electron, CEF and WebView2 are all forks of it. Google has no interest in a supported official embedding API.

I'm struggling to see the logical throughline that connects your comment to mine, or even how it relates to itself.

Gecko was originally conceived to be embeddable by design. TPTB decided this was a handicap. It's not an accident that it's hard to work with outside the context that is its modern raison d'être; it is now unembeddable, if not "by design" then certainly by choice.

Servo is not a product, and there is no product for which Servo is an integral component. Servo was an R&D project. It succeeded. Mozilla laid off a bunch of Servo developers, partly because of COVID, and partly because it was (past) done; it doesn't make sense to keep paying for R&D at Servo's stage. It's debatable whether it's even R&D at that point—more like wankery/noodling (i.e. what most programmers want to do, but that the world already has enough of).

> Gecko was originally conceived to be embeddable by design

Which part? And… what do you mean by embeddable in that context?

XULRunner?

XULRunner was not Gecko embed. It was Gecko embedding stuff.

There was never a proper embeddable gecko.

There has been an attempt for a gtk widget, but it never matured.

"There was never a proper embeddable gecko" is both (a) a strong claim which with some difficulty we might be able adjudicate, but not especially important whether we do or not because, crucially, it is (b) not the same thing as saying/proving that "Gecko was not originally conceived to be embeddable" (or proving that its negation is untrue).

Gecko was not, at the time that Servo was conceived, supposed to be easy to embed. Gecko had, by the time that Servo was conceived, undergone refactoring that knowingly made it more difficult to embed. It would be accurate to say that, at the time that Servo was conceived, embeddability of Gecko was an explicit non-goal.

This is exactly why I raised the issue of the logical throughline of the other comment—what is the point of mentioning Gecko's embeddability in this discussion? All right, Gecko is "notoriously unembeddable". So what? It's a complete nonsequitur, and it risks catching anyone off guard if they're not playing close enough attention and they mistake it for a salient retort of... something not actually stated or argued here

I have a very difficult time parsing your words. I'm sorry.

I'm just saying gecko was not embeddable and was never designed to be so. There has been some efforts, and all failed.

As far as I know! … so I'd be happy to be corrected, I'd love to hear more about the history of gecko.

And you seem to know things I don't know, so I'm just asking what you are referring to. Out of curiosity.

> Gecko had, by the time that Servo was conceived, undergone refactoring that knowingly made it more difficult to embed

What kind of refactoring are you talking about?

And back to your original statement:

> Gecko was originally conceived to be embeddable by design

What are you talking about here?

I respect you and your contributions to Mozilla and the Web, but you're wrong. These two sentences aren't even logically consistent:

> I'm just saying gecko was not embeddable and was never designed to be so. There has been some efforts, and all failed.

Aside from that, sorry, but I have a huge distaste for the XKCD-style just-make-a-claim-on-the-internet-and-wait-for-someone-to-correct-you strategy of factfinding. It's reckless and annoying.

Anyone who's curious about this subject has more than enough information from this thread alone to turn up the relevant details on their own by now. I'm not going to do any archeology at this point in the discussion, because my patience and the amount of resources I'm willing to put into this topic have by now been exhausted. The only thing I'll say is that the Components.classes[`@mozilla.org/embedding/${...}`] namespace didn't exist for no reason.

Alright, you don't have to engage. I thought maybe I missed something before my time.

For others and historians :) … some efforts were made I think around 2008 (by Brad L. and/or Mark F. … I don't remember so well). A shortlived GTK widget was attempted at some point.

But this lead to nowhere because… well, it's hard to bend Gecko that way, because, again, Gecko was not designed to be embedded. And also because leadership was not pushing into that direction.

About the "not designed that way", what I mean is this:

We had many abstractions for sure to make it multi-platform (and that was amazing achievement, really) but embedding requires mechanisms to hook the event loop and the rendering pipeline into the embedder, in an agnostic way. Which is the part that was missing in Gecko.

Webkit had a proper, well designed, embedding story.

We didn't.

K-Meleon used the Gecko rendering engine but with a native chrome and no SpiderMonkey. It also powers Thunderbird and the SeaMonkey browser. I'm sure it turned up elsewhere before it was too 'baked in' to Firefox.

In the case of Thunderbird and seamonkey, Gecko was not embedded, but was the "embedder".

For a short time, there was some attempts (native cocoa and gtk widget) to embed gecko, but it was really not meant to be, it was really hacky and never matured.

Gecko was never designed to be embedded. Really.

Throughline is unwanted fetishization/romantizadion of Servo.

I'd argue Servo's promise was never realized - embedding.

Another part of it is losing people in the purge. People fired weren't hired to work on Servo exclusively, some were long time developers of FF, including the MDN docs team.

So it's not like they started Servo, hired bunch of people to work on it, then fired them after R&D was done.

I remember Mozilla Prism as a "site specific browser"or what one calls it back in the days.

If only one could Boot2Gecko

Reply on news.ycombinator.com