The case for an embeddable Gecko | Hacker News Reader

The case for an embeddable Gecko

chrislord.net

57 pointscpeterso28 comments

I was deeply saddened when Gecko embedding got the axe, because that action was responsible for the death of Camino, one of my favorite browsers in its era. It was really great to have two fully native Cocoa browsers for OS X (Safari + Camino). Between the two there was little need for anything more.

If you want 100% native modern browser on the Mac desktop today you’re stuck with Safari. The Mac version of Firefox has always felt somewhat like a kludge. Chrome is closer, but it opts to do its own UI drawing, text editing, spellchecking, etc instead of using Cocoa-provided facilities which is likely at least partially responsible for it being less battery-friendly than Safari.

It’s my personal opinion that web engines should take a “webkit” stance in regards to interoperability; they should be UI-agnostic at their core and offer rich plain C APIs for any language and UI toolkit combination to easily bolt onto. A developer shouldn’t be forced into using any particular technology to take advantage of something so versatile and ubiquitous as a web rendering engine — this is the chief reason I dislike Chromium/Electron/Node-WebKit: they mandate how I write my UI and what it’s written in, which (to me) is highly unappealing.

Mozilla's research render engine Servo sounds like the best bet, rather than redesigning all of Gecko's API space. It already implements the CEF, and was built specifically for embedding. The fact that it's an order of magnitude faster than all other rendering engines can't hurt, either.

That what I was thinking. Gecko had it's time. Servo would serve mobile devices better as a technology too.

I also imagine Mozilla's legacy will live on in Servo after Firefox has lost its remaining market share.

  > The fact that it's an order of magnitude faster than all
  > other rendering engines can't hurt, either.

For some recent citations on this, check the first half hour of https://air.mozilla.org/bay-area-rust-meetup-february-2016/

  > There is essentially no webpage out there that it cannot
  > get through at multiple hundreds of frames-per-second

Yeah, embedding is an explicit goal for us.

If a Servo browser UI ever happens (one prospect is https://github.com/mozilla/browser.html/), it would probably be developed separately, with a minimal API surface between the two. (At least, I hope so)

Yes Servo is the future. But it's far from being ready as a web runtime that you can use for your day to day browsing. The web is a large, and moving, target...

So in the meantime it would still be interesting to get a nice embedding for Gecko. I like the Electron approach a lot, and this looks like a moderate size effort to bring something like that to Gecko.

What would be the advantages of using Gecko over Webkit or Chromium/Blink today?

Would it run faster? Would it be more compatible? Is it more familiar to Devs? Is the code base easier to understand?

At least with Servo the answer to some of those questions would be a definite yes.

It's possible that Servo replaces Gecko incrementally, from the inside out. Mozilla recently landed support for writing Gecko code in Rust and is importing bits of Servo's CSS system:

https://bugzil.la/oxidation

https://bugzil.la/stylo

I don't think CEF API compat is good enough. Look at other Chromium based applications in Electron or nw.js. They use up multiple processes and are bulky. What is needed is a low level embedding API that does not have IPC and process forking baked in. Sadly we are on the path to losing a lot of that...even the Servo devs said that while they expect it to work at that low of a level, multi process is all they are concerned about supporting[1].

1 - https://news.ycombinator.com/item?id=9541721

I think, like Patrick said there, there's not much reason for Servo to stop working single process (in fact, we still are single process by default?) aside from cruft buildup and lack of interest. If there's a need for maintaining a single process mode that's not too much effort.

I would love to be able to embed Servo with this approach. With the serious lack of cross-platform AND cross-language UI toolkits available these days, everyone is turning to embedded browsers (I am looking at 7 Slack processes averaging 40MB each, though the Slack devs may deserve blame). I think bit rot is what has made --single-process for Chromium no longer viable.

Heck, I'd say even making it easily embeddable before feature complete would still get adopters due to app devs knowing what they need to support unlike the open web. Granted I cannot really put my money/skills where my mouth is here so it's just wishful thinking on my part. I am not familiar w/ where Servo stands on the embedding front today, I have not looked in a while.

Using Servo to build apps is an explicit goal, and part of the browser.html project (https://github.com/browserhtml/browserhtml) includes developing a privileged set of APIs and other things ("Graphene") that work in Servo and let you build applications. This is more towards creating standalone applications (no need for actual embedding) that use Servo, though.

As far as the embedding story is concerned we do support the CEF API (if you need something more there, please file an issue and we'll look into it), and we do want to eventually make it into a webview-esque thing which you can embed in Android and elsewhere.

I didn't say that multiprocess is all we care about supporting. I said that we'd support single process mode as long as there's interest and a maintainer.

My apologies for mis-summarizing. In general I think there would be interest (as far as actionable interest in the form of a maintainer I am not as sure).

I think the hope is in Servo. NetSurf and Dillo are missing from the timeline.

I would really like to see Gecko and Spidermonkey in a more embeddable format as well. Being able to run as a "backend" for Node or Electron Shell, so that you don't have to be on V8 and Chromium would be absolutely great.

I have always thought it a shame that Mozilla didn't aim for a better embeddable engine. Embedded browser engine seems like such an obvious part of their mission.

It's not a priority for them. The first comment explains the endemic lack of resources.

It's a bit like Google and their appliance. It's better to have a vertical product with no leaf and build on top like they tried with FirefoxOS.

> endemic lack of resources.

Funny, the number of "labs" projects mozilla undertakes and eventually abandons doesn't suggest such a thing.

It was actually a big part of the original goals in the AOL days. That changed with Firefox.

Jolla's Sailfish Browser is based on Gecko http://blog.idempotent.info/posts/whats-behind-sailfish-brow...

It uses custom APIs to embedd Gecko with Qt : https://github.com/tmeshkova/qtmozembed https://github.com/tmeshkova/embedlite-components https://github.com/tmeshkova/gecko-dev

Why would anyone choose embeddable Gecko over Electron?

Spending time on this is a waste of Mozilla's resources. The real competitor is clearly Servo (once it actually works with real pages than just Wikipedia and GitHub) because it is actually faster and is not legacy software that barely works.

> legacy software that barely works

Did you create a new user account just to spew that shit?

I'm being very pessimistic here, but even with e10s improvements Gecko is clearly dying.

I find your lack of faith disturbing.

https://mo.github.io/2015/11/04/browser-engines-active-devel...

This post reads like the author has never heard of Servo, but it seems unlikely that someone who has done this much research wouldn't come across it or mention it. It's planned to deprecate Gecko, it's faster, and it's designed as a drop-in replacement for embedded Chromium.

Chris Lord is well aware of Servo. He's a Mozilla Corp employee. He's been a part of Mozilla since at least as far back as when HTML5 video was first starting to become a thing and Firefox was integrating WebM, which was first announced at Google IO 2010.

He focuses on Gecko here because Mozilla's relationship with it is something that will continue for some time.

I see. Thanks for correcting me.

Reply on news.ycombinator.com