
Qbrt – Cross-platform HTML/JS desktop apps using the Firefox Gecko runtime - roryisok
https://mykzilla.org/2017/03/15/introducing-qbrt/
======
carussell
> Also, qbrt doesn’t yet support runtime version management (i.e. being able
> to specify which version of Gecko to use, and to switch between them). At
> the time you install it, it downloads the latest nightly build of Firefox.

This doesn't sound so good, and is the opposite of what I think people have
come to expect. It's seems like the most straightforward solution is to
hardcode a specific version of the runtime into the package, so that
installing qbrt XX.0.0 gets you the runtime that corresponds to Firefox
version XX.

~~~
roryisok
It has an upside though. If all apps share a runtime they're tiny in size.
Every electron app installs its own version of chromium

~~~
nevir
How important is binary size for desktop apps, though?

~~~
roryisok
It's not that big a deal, but it all adds up eventually. I wouldn't want every
.net or java app to install their own versions of .net and java. Sure, my
laptop hd probably has enough space for that, but its unnecessary

------
cocktailpeanuts
What's the benefit of using this instead of Electron? Genuinely curious about
the benefit.

Is Gecko better than Chromium in certain cases?

~~~
roryisok
One _difference_ (Don't know if its a benefit) is that it uses a common
runtime. Two qbrt apps would use the same installed version of Firefox
Nightly, so app download sizes would be smaller. If you read these electron
threads this is something that comes up a lot.

Firefox's latest build made significant RAM usage improvements [1],
leapfrogging Chrome when it came to multiple tabs.

[1][[http://www.techradar.com/news/firefoxs-blazing-speed-with-
hu...](http://www.techradar.com/news/firefoxs-blazing-speed-with-huge-numbers-
of-tabs-leaves-chrome-in-the-dust)]

~~~
jancsika
If I package up my app and ship for Windows, and you package up your app and
ship for Windows, how do the two apps use a common runtime?

~~~
rtpg
the same way that the JVM works, at least in theory.

You have the base virtual machine installed, and then the app just needs to
ship the code itself.

You could even ship with an "install script header", like "if this isn't
installed, offer to download and install it". I imagine a lot of us have seen
these kinds of installers before.

~~~
jancsika
I don't understand how that would be different than Electron or nw.js.

For example, if there were a Debian package for either of those, all apps
leveraging them would just declare that same package a dependency and you'd
have a single system-wide install for the large binary everyone keeps
complaining about. (AFAICT there is no such deb package for any of the above.)

~~~
Crespyl
Electron is designed to be bundled into your app, I'm not aware of any
distros/package tools that allow Electron apps to share a runtime.

The JVM (and apparently qbrt) is designed to be shared, apps are expected to
use the installed system version of the VM, though if the packager wants they
can include a specific version to use.

I _wish_ it were easy/possible to get Electron apps to share things, it
bothers me that Chrome, Discord, and Slack almost certainly could share most
of their hundreds of megabytes.

~~~
jancsika
It appears both electron and nw.js can be installed through npm (though the
electron one is more up-to-date than the nw.js one:

[https://www.npmjs.com/package/nwjs](https://www.npmjs.com/package/nwjs)

and electron:

[https://github.com/electron-userland/electron-
prebuilt](https://github.com/electron-userland/electron-prebuilt)

~~~
roryisok
You can install electron globally but if you package your app to target
electron prebuilt you'd have to require the use to have installed both it and
nodejs already.

It's not completely bonkers. It could be possible to make a web installer that
checks for node and electron and downloads them if necessary. Nobody seems to
do that though. Every electron app bundles electron. At least every one I've
seen

~~~
rtpg
Part of the problem here is that the entire JS ecosystem is built around local
copies of things, so there might not be a lot of institutional knowledge in
that corner of OSS to pull off the "shared env" thing quite well.

That plus scarring from browser differences over N years.

Of course it's still totally possible, but there are probably gotchas that
aren't obvious if you're mainly a web developer.

------
Zekio
is this a potential electron competitor/alternative?

Edit: Electron really needs a competitor/alternative

~~~
roryisok
There's a little known Microsoft framework that allows html and JavaScript to
be compiled into an exe using ie, but its so obscure I couldn't find it after
five minutes of googling. And obviously it's not cross platform.

~~~
pjmlp
Maybe Microsoft should re-market it to the Electron generation, and eventually
bring back Active Desktop as well.

You cannot find much about it, because it was an IE 6.0 based technology, when
"Electron apps" were the IE ActiveX engine bundled as .exe.

~~~
roryisok
I actually liked active Desktop. You could have animated wallpapers and system
information embedded on your Desktop back in windows 98, it was a shame it got
removed. Nowadays you have to use rain meter if you want to do any of that
stuff

------
z3t4
Instead of using the system API you should start a nodejs process and have the
web app communicate with it using websockets, and use the system api in the
nodejs app. That way it will be easy to port your "native" app to different
systems and you can use the same code on both web and native! You don't even
need the runtime, just launch Firefox with the "-chrome" argument, or
"\--app=" in Chrome or "-k" in IE.

------
zerr
I wonder what's the state of XUL, if anyone using it in the wild (besides
Mozilla)...

~~~
ZenoArrow
There were a few popular non-Mozilla apps that were built using XULRunner back
in the day, but considering Mozilla has made it clear that XUL development
will soon stop, I don't think it's likely to be a technology that grows in
popularity.

~~~
zerr
Did they? At least so far they are heavily invested in XUL (Firefox,
Thunderbird). Do they plan to switch these and other apps to another
framework?

~~~
ZenoArrow
Yes, they plan to switch away from XUL. I'm not sure about the situation with
Thunderbird, but I believe Firefox will be dropping XUL this year or early
next year.

There are two sides to this migration. The main Firefox UI is being rewritten
(how much of XUL remains after this rewrite is unclear), and extensions
developed in XUL are being dropped.

[https://www.neowin.net/news/mozilla-is-working-on-a-new-
ui-f...](https://www.neowin.net/news/mozilla-is-working-on-a-new-ui-for-
firefox-57)

[https://blog.mozilla.org/addons/2017/02/16/the-road-to-
firef...](https://blog.mozilla.org/addons/2017/02/16/the-road-to-
firefox-57-compatibility-milestones/)

~~~
482794793792894
The new UI for Firefox 57 is still written in XUL. It's just the XUL extension
API that is being deprecated in favor of WebExtensions with Firefox 57.

This deprecation of XUL extensions could prove problematic for Thunderbird, as
it means that Mozilla can now move a lot faster and make breaking changes
without having to worry about mass-breakages in extensions, therefore making
it more likely that they'll leave Thunderbird behind at some point, but XUL
itself isn't yet being deprecated.

There are some long-long-term plans to maybe eventually replace XUL with
HTML/CSS/JS, but they need much better performance still before that becomes
viable. There are some efforts into that direction already[0], building a
framework for it as well, and those mostly focus around Servo, as that will
have the necessary performance, so I'd guess at least a couple of years still.

[0][https://github.com/browserhtml/browserhtml](https://github.com/browserhtml/browserhtml)

------
muterad_murilax
"Qbrt" makes me think of the classic arcade game:

[https://en.wikipedia.org/wiki/Q*bert](https://en.wikipedia.org/wiki/Q*bert)

~~~
bluejekyll
I had assumed that was intentional...

------
oblib
Well the low level details are over my head but the discussion is certainly
interesting and enlightening and I do want to play with this.

------
appleflaxen
is this like the broadway backend for gtk?

[https://vimeo.com/21062117](https://vimeo.com/21062117)

------
frik
Like 3 years ago I proposed a Nodejs implementation based on Gecko instead of
V8. Two Mozilla devs mentioned they don't care and see no need. In the
meantime even MS is trying with their Chakra.

~~~
houli
This is being worked on by Mozilla
[https://github.com/mozilla/spidernode](https://github.com/mozilla/spidernode)

