7 ms·

The case for an embeddable Gecko

57 points by cpeterso 11y ago

wldcordeiro 11y ago
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 11y ago
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 11y ago
  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 11y ago
    > endemic lack of resources. Funny, the number of "labs" projects mozilla undertakes and eventually abandons doesn't suggest such a thing.
- carussell 11y ago
  It was actually a big part of the original goals in the AOL days. That changed with Firefox.
vmorgulis 11y ago
I think the hope is in Servo. NetSurf and Dillo are missing from the timeline.
chc4 11y ago
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.
- bobajeff 11y ago
  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.
- steveklabnik 11y ago
  > 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/ 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
- Manishearth 11y ago
  Yeah, embedding is an explicit goal for us. If a Servo browser UI ever happens (one prospect is https://github.com/mozilla/browser.html/ 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)
- fabrice_d 11y ago
  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.
  - bobajeff 11y ago
stirner 11y ago
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 11y ago
  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 11y ago
    I see. Thanks for correcting me.
thewitness 11y ago
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 11y ago
  > legacy software that barely works Did you create a new user account just to spew that shit?
  - thewitness 11y ago
    I'm being very pessimistic here, but even with e10s improvements Gecko is clearly dying.
    - ndesaulniers 11y ago
      I find your lack of faith disturbing. https://mo.github.io/2015/11/04/browser-engines-active-developers-and-commit-rates.html https://mo.github.io/2015/11/04/browser-engines-active-devel...
kitsunesoba 11y ago
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.
siteshwar 11y ago
Jolla's Sailfish Browser is based on Gecko http://blog.idempotent.info/posts/whats-behind-sailfish-browser.html 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/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

57 points by cpeterso 11y ago

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 11y ago

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 11y ago
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 11y ago
  > endemic lack of resources. Funny, the number of "labs" projects mozilla undertakes and eventually abandons doesn't suggest such a thing.
carussell 11y ago
It was actually a big part of the original goals in the AOL days. That changed with Firefox.

vmorgulis 11y ago

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

chc4 11y ago

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.

bobajeff 11y ago
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.
steveklabnik 11y ago
> 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/ 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
Manishearth 11y ago
Yeah, embedding is an explicit goal for us. If a Servo browser UI ever happens (one prospect is https://github.com/mozilla/browser.html/ 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)
fabrice_d 11y ago
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.
- bobajeff 11y ago

stirner 11y ago

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 11y ago
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 11y ago
  I see. Thanks for correcting me.

thewitness 11y ago

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 11y ago
> legacy software that barely works Did you create a new user account just to spew that shit?
- thewitness 11y ago
  I'm being very pessimistic here, but even with e10s improvements Gecko is clearly dying.
  - ndesaulniers 11y ago
    I find your lack of faith disturbing. https://mo.github.io/2015/11/04/browser-engines-active-developers-and-commit-rates.html https://mo.github.io/2015/11/04/browser-engines-active-devel...

kitsunesoba 11y ago

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.

siteshwar 11y ago

Jolla's Sailfish Browser is based on Gecko http://blog.idempotent.info/posts/whats-behind-sailfish-browser.html 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/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