
The case for an embeddable Gecko - cpeterso
http://chrislord.net/index.php/2016/02/24/the-case-for-an-embeddable-gecko/
======
kitsunesoba
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.

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

~~~
kodablah
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](https://news.ycombinator.com/item?id=9541721)

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

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

~~~
Manishearth
Using Servo to build apps is an explicit goal, and part of the browser.html
project
([https://github.com/browserhtml/browserhtml](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.

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

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

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

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

~~~
qewrffewqwfqew
> endemic lack of resources.

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

------
siteshwar
Jolla's Sailfish Browser is based on Gecko
[http://blog.idempotent.info/posts/whats-behind-sailfish-
brow...](http://blog.idempotent.info/posts/whats-behind-sailfish-browser.html)

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

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

~~~
ndesaulniers
> legacy software that barely works

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

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

~~~
ndesaulniers
I find your lack of faith disturbing.

[https://mo.github.io/2015/11/04/browser-engines-active-
devel...](https://mo.github.io/2015/11/04/browser-engines-active-developers-
and-commit-rates.html)

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

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

~~~
stirner
I see. Thanks for correcting me.

