7 ms·

Why are most open source browsers based chromium as opposed to gecko? I would think much of the OSS community would be opposed to using google owned software.

sequence7 5y ago
I suspect the answer is because of compatibility. Chromium has become the industry standard, everyone tests only on Chrome (and Safari for mobile) so you can expect fewer issues if you're based on chromium.
- graderjs 5y ago
  But I think it's a valid question. Because for a niche browser (which most of these alternate projects are), mainstream compatibility for all websites doesn't seem like it would be the most important thing. I think the idea of using Gecko[0] is a solid one. :P ;) xx [0]: https://github.com/mozilla/gecko-dev https://github.com/mozilla/gecko-dev
  - sequence7 5y ago
    I agree it's a valid question and it seems my suspicion is not the main reason. Based on the other replies to the parent it seems that choosing Gecko requires more work.
mavroprovato 5y ago
If I'm not greatly mistaken, there is no way to embed Gecko in a desktop application right now
jmercouris 5y ago
We are not based on Chromium, we are engine agnostic. As to why no Gecko support? Mozilla does not make it easy!
- servilio 5y ago
  Have you looked at Servo instead?
  - dijit 5y ago
    I have, I was working on replacing QtWebEngine(chromium) for Qutebrowser with Servo. It is very far from ready, most websites do not render correctly and JavaScript is very hit/miss with regards to updating the rendered view. Simply put: Servo is not possible to use as a daily driver.
    - lufte 5y ago
      Interesting. Do you have that work available anywhere?
      - dijit 5y ago
        Unfortunately since it was a non-starter I didn’t package the work nicely. Can probably package it up if you really want it. But like I said: the rendering engine was not usable. The overwhelming majority of websites did not function.
  - hawski 5y ago
    Servo is not done.
  - shakow 5y ago
    Servo is not yet ready for everyday use. Moreover, Mozilla fired most of its team working on it, so notable progress is not to be expected in the short term :(
pojntfx 5y ago
If I remember correctly, it is much harder to use Firefox's components outside of Firefox than it is to do with Chromium/Blink. There is a reason why there is no relevant Electron alternative based on Firefox/Gecko. On Android the situation is different but not on any other platform: https://mozac.org/ https://mozac.org/
- HeckFeck 5y ago
  Is/Has there been much interest in doing this at Mozilla? More people using their renderer is good for them in the long run.
  - 0x_rs 5y ago
    Not since the days of XULRunner, which is ancient nowadays.
    - smazga 5y ago
      Conkeror (basically Nyxt on xulrunner…exactly what the upper comment is asking about) used to be my browser of choice. It was baffling to me when they deprecated xulrunner. Like, why? There was supposed to be an alternate way to do it (running with ‘firefox -app’ or something), but it was poorly documented and constantly breaking in new versions, so I eventually gave up.
      - donio 5y ago
        RIP conkeror, miss you dearly
      - JasonFruit 5y ago
        I loved Conkeror, but I think this one might be even better, once I've gotten used to its quirks. I'm kinda stoked right now.
  - e3bc54b2 5y ago
    Historically, Firefox has been the only moneymaker for Mozilla. It is possible they didn't want to make it easy to embed so anyone can create second FF on top of their work and compete without paying dues. Electron and single applications built fully on top of browser engine alone is relatively new, and possibily out of Mozilla's field of vision back then. But, that is speculation, and I have no proof whatsoever other than tangential conclusions from Mozilla's blunders in recent years.
ginko 5y ago
What I'd like to see would be more projects picking up Servo.
- nvrspyx 5y ago
  Perhaps when it's production-ready. There's still quite a lot of work to be done before then.
BenoitEssiambre 5y ago
Imo, browsers need to have a standard specification and one that includes an open source versioned controlled reference implementation of the core parts. It seems chromium has become that standard (chromium is open source afaik, not owned by google). I often argue against purely natural language specifications in favor code based specs. I just don't think human language is nearly precise enough to write an adequate specification. Natural language words are incredibly polysemic and contextual. Look, for example, at how many meanings the word "break" has: https://www.merriam-webster.com/dictionary/break https://www.merriam-webster.com/dictionary/break Kolmogrov has long ago suggested that fully specified information distills down to a computer program: https://en.wikipedia.org/wiki/Kolmogorov_complexity https://en.wikipedia.org/wiki/Kolmogorov_complexity, https://en.wikipedia.org/wiki/Minimum_description_length https://en.wikipedia.org/wiki/Minimum_description_length The ideal language for a pure specification might be a mix of natural language and pseudo code with a pseudo test suit. However, if you are writing that, you might as well go one step further and write working testable code. I like the concept of Literate Programming (https://en.wikipedia.org/wiki/Literate_programming https://en.wikipedia.org/wiki/Literate_programming) and its descendants of having code with extractable inline comments that auto generate documentation. I would argue that modern pull request based workflows that tie discussions to version controlled code changes are also the progression of this line of thought. A cleaned up version of these might make sense for a specification. And I get some of the concerns. While natural language under specifies, reference implementations over specify. This is more of a problem with low level languages however. Modern high level languages are getting fairly close to a form of pseudo code. I fully agree that the reference implementations shouldn't contain or should hide, low level optimizations. I also understand that reference implementations can unduly tie specs to specific hardware, OSs and platforms. But to me, over-specification is less of a problem than under-specification and it can be mitigated by labeling particular functions or blocks of code as implementation specific and not part of the spec. Without spec written in code, the different implementations always have subtle incompatibilities. I see egregious versions of under-specification in government where horrendously vague specs are created in order to issue RFPs for getting software built. They usually end up with non working software at mind blowing cost. People have this weird misconception that you are contracting out to build software. You are not. Building software is really easy. You press the build button or type the compile command. Building software has been fully automated for a while now. What is difficult is designing software and specifying what it must do. This is because there is a vast jungle of protocols, business flows, hardware and software platforms that need to be interacted in different ways for different needs. This is what needs to be specified and only computer code can do it adequately. I wish that Mozilla adopted the chromium core. We really need a well funded non-profit managed release of the reference browser.
fmakunbound 5y ago
IIRC, Mozilla killed off embedded gecko years ago.

sequence7 5y ago

I suspect the answer is because of compatibility. Chromium has become the industry standard, everyone tests only on Chrome (and Safari for mobile) so you can expect fewer issues if you're based on chromium.

graderjs 5y ago
But I think it's a valid question. Because for a niche browser (which most of these alternate projects are), mainstream compatibility for all websites doesn't seem like it would be the most important thing. I think the idea of using Gecko[0] is a solid one. :P ;) xx [0]: https://github.com/mozilla/gecko-dev https://github.com/mozilla/gecko-dev
- sequence7 5y ago
  I agree it's a valid question and it seems my suspicion is not the main reason. Based on the other replies to the parent it seems that choosing Gecko requires more work.

mavroprovato 5y ago

If I'm not greatly mistaken, there is no way to embed Gecko in a desktop application right now

jmercouris 5y ago

We are not based on Chromium, we are engine agnostic. As to why no Gecko support? Mozilla does not make it easy!

servilio 5y ago
Have you looked at Servo instead?
- dijit 5y ago
  I have, I was working on replacing QtWebEngine(chromium) for Qutebrowser with Servo. It is very far from ready, most websites do not render correctly and JavaScript is very hit/miss with regards to updating the rendered view. Simply put: Servo is not possible to use as a daily driver.
  - lufte 5y ago
    Interesting. Do you have that work available anywhere?
    - dijit 5y ago
      Unfortunately since it was a non-starter I didn’t package the work nicely. Can probably package it up if you really want it. But like I said: the rendering engine was not usable. The overwhelming majority of websites did not function.
- hawski 5y ago
  Servo is not done.
- shakow 5y ago
  Servo is not yet ready for everyday use. Moreover, Mozilla fired most of its team working on it, so notable progress is not to be expected in the short term :(

pojntfx 5y ago

If I remember correctly, it is much harder to use Firefox's components outside of Firefox than it is to do with Chromium/Blink. There is a reason why there is no relevant Electron alternative based on Firefox/Gecko. On Android the situation is different but not on any other platform: https://mozac.org/ https://mozac.org/

HeckFeck 5y ago
Is/Has there been much interest in doing this at Mozilla? More people using their renderer is good for them in the long run.
- 0x_rs 5y ago
  Not since the days of XULRunner, which is ancient nowadays.
  - smazga 5y ago
    Conkeror (basically Nyxt on xulrunner…exactly what the upper comment is asking about) used to be my browser of choice. It was baffling to me when they deprecated xulrunner. Like, why? There was supposed to be an alternate way to do it (running with ‘firefox -app’ or something), but it was poorly documented and constantly breaking in new versions, so I eventually gave up.
    - donio 5y ago
      RIP conkeror, miss you dearly
    - JasonFruit 5y ago
      I loved Conkeror, but I think this one might be even better, once I've gotten used to its quirks. I'm kinda stoked right now.
- e3bc54b2 5y ago
  Historically, Firefox has been the only moneymaker for Mozilla. It is possible they didn't want to make it easy to embed so anyone can create second FF on top of their work and compete without paying dues. Electron and single applications built fully on top of browser engine alone is relatively new, and possibily out of Mozilla's field of vision back then. But, that is speculation, and I have no proof whatsoever other than tangential conclusions from Mozilla's blunders in recent years.

ginko 5y ago

What I'd like to see would be more projects picking up Servo.

nvrspyx 5y ago
Perhaps when it's production-ready. There's still quite a lot of work to be done before then.

BenoitEssiambre 5y ago

Imo, browsers need to have a standard specification and one that includes an open source versioned controlled reference implementation of the core parts. It seems chromium has become that standard (chromium is open source afaik, not owned by google). I often argue against purely natural language specifications in favor code based specs. I just don't think human language is nearly precise enough to write an adequate specification. Natural language words are incredibly polysemic and contextual. Look, for example, at how many meanings the word "break" has: https://www.merriam-webster.com/dictionary/break https://www.merriam-webster.com/dictionary/break Kolmogrov has long ago suggested that fully specified information distills down to a computer program: https://en.wikipedia.org/wiki/Kolmogorov_complexity https://en.wikipedia.org/wiki/Kolmogorov_complexity, https://en.wikipedia.org/wiki/Minimum_description_length https://en.wikipedia.org/wiki/Minimum_description_length The ideal language for a pure specification might be a mix of natural language and pseudo code with a pseudo test suit. However, if you are writing that, you might as well go one step further and write working testable code. I like the concept of Literate Programming (https://en.wikipedia.org/wiki/Literate_programming https://en.wikipedia.org/wiki/Literate_programming) and its descendants of having code with extractable inline comments that auto generate documentation. I would argue that modern pull request based workflows that tie discussions to version controlled code changes are also the progression of this line of thought. A cleaned up version of these might make sense for a specification. And I get some of the concerns. While natural language under specifies, reference implementations over specify. This is more of a problem with low level languages however. Modern high level languages are getting fairly close to a form of pseudo code. I fully agree that the reference implementations shouldn't contain or should hide, low level optimizations. I also understand that reference implementations can unduly tie specs to specific hardware, OSs and platforms. But to me, over-specification is less of a problem than under-specification and it can be mitigated by labeling particular functions or blocks of code as implementation specific and not part of the spec. Without spec written in code, the different implementations always have subtle incompatibilities. I see egregious versions of under-specification in government where horrendously vague specs are created in order to issue RFPs for getting software built. They usually end up with non working software at mind blowing cost. People have this weird misconception that you are contracting out to build software. You are not. Building software is really easy. You press the build button or type the compile command. Building software has been fully automated for a while now. What is difficult is designing software and specifying what it must do. This is because there is a vast jungle of protocols, business flows, hardware and software platforms that need to be interacted in different ways for different needs. This is what needs to be specified and only computer code can do it adequately. I wish that Mozilla adopted the chromium core. We really need a well funded non-profit managed release of the reference browser.

fmakunbound 5y ago

IIRC, Mozilla killed off embedded gecko years ago.