Myk Melez, a former Mozilla engineer, writes about embedding Gecko, Node.js and Firefox tooling, including the discontinued Positron project.
HN commenters link his post on Positron's discontinuation when discussing Electron-like apps on Firefox and Gecko, and some say they want it rebooted.
> Why can't XUL vs DOM just be the same data with a fast C++ API and a slow JS API?
This is a great question! I'm not really qualified to answer it, but I'll give it a try.
My understanding is that the XUL tree is fast because it implements the XPCOM C++ nsITreeView[0][1][2] interface.
If you're writing a XULRunner program ...
(Firefox "is distributed as the combination of a Gecko XUL runtime — libxul, other shared libraries, and non-browser-specific resources like those in toolkit/ — plus a Firefox XUL application — mostly just the files in Contents/Resources/browser/, plus the 'firefox' stub executable that loads Gecko and points it at a XUL application", see [3])
..., XPCOM[4] allows you invoke those implemented interface methods directly from JavaScript.
XPCOM is a technology that, since the removal of XUL/XPCOM addons, is inaccessible to everyone except for Mozilla devs and those who write XULRunner programs using `firefox --app /path/to/application.ini`.
So, some XUL elements (like <tree>) implement an XPCOM interface that invokes native C++ (or rust, python, java, etc.) code, which is statically compiled directly into the Gecko XUL runtime.
Modern HTML5 elements, in general, must utilize the native interpreted browser DOM/JavaScript and cannot choose to implement/satisfy an arbitrary internal XPCOM interface. While I'm sure that Mozilla has figured out a way to make these elements fast (C++, Rust, I have no idea), you are always bounded by the limitations of…
The issue with this is that the more deeply customisable a fork would be the further it would stray from upstream (and by extension the more dev resources it would require to maintain).
> I keep hearing the Firefox codebase isn't very modular and makes it hard to pursue such a project, and I don't doubt it. But aren't there enough of "us" out there to make a concerted effort?
There's been plenty of people making such an effort, but yeah it does appear to be "hard". If you're interested in following previous work, some relevant links:
- Overview of Myk Melez's efforts in this space https://mykzilla.org/2017/03/08/positron-discontinued/
- https://mozilla.github.io/geckoview/ (official but Android-only)
- https://github.com/mozilla/qbrt
It may also be worthwhile reading about CEF which has become something of a defacto standard: https://en.wikipedia.org/wiki/Chromium_Embedded_Framework
As I understand it, Gecko is much harder to work with, so it would take a lot of time to make something like brave compatible with both Chromium and Gecko/Firefox's APIs (or to even only move to Gecko/FF). See the following comment from [0]:
> More significantly, in my book: it’s difficult to use Gecko and Firefox in these ways. Even the simplest app requires substantial and arcane boilerplate. And the docs are comprehensive but outdated. The platform may be powerful, but it’s hard to use.
There's also now qbrt[1], but the readme itself recommends not using it, and it was last updated 7 months ago. If this matures to a usable state, I can see Brave developers considering it.
0: https://mykzilla.org/2017/03/08/positron-discontinued/
1: https://github.com/mozilla/qbrt
They tried:
"This project is an Electron-compatible app shell for creating desktop apps based on Gecko, the rendering engine used in Firefox."
https://github.com/mozilla/positron
but they failed:
"As noted in the blog post Positron Discontinued [1], this project has been discontinued. The source remains available, and you're welcome to reuse it."
[1] https://mykzilla.org/2017/03/08/positron-discontinued/
Yes. There was an experimental project called Positron [0]: "a experimental, Electron-compatible runtime on top of Gecko". It was discontinued in 2017 [1].
AFAIK the only thing around nowadays is GeckoView [2] for Android.
[0]: https://github.com/mozilla/positron
[1]: https://mykzilla.org/2017/03/08/positron-discontinued/
[2]: https://mozilla.github.io/geckoview/
There was a project to do this, Positron.
https://mykzilla.org/2017/03/08/positron-discontinued/
Revolving door management that has no clue what initiatives the previous management started and wants to start all their own initiatives really hurt Mozilla in the last 5 years.