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.
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)
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].
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).
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.
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:
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.
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.
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.
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.