Qbrt – Cross-platform HTML/JS desktop apps using the Firefox Gecko runtime | Hacker News Reader

Qbrt – Cross-platform HTML/JS desktop apps using the Firefox Gecko runtime

mykzilla.org

165 pointsroryisok92 comments

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

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

How important is binary size for desktop apps, though?

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

And every qbrt app is the same way. If there are two apps 'one' and 'two' written as node modules, and both have qbrt x.x.x in their dependencies, then installing both will leave you with two identical but independent runtimes. There's no sharing going on.

A runtime that can't run the app it's supposed to (because of breaking changes across runtime versions) is also not a very useful runtime, shared or not.

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

Is Gecko better than Chromium in certain cases?

> "Is Gecko better than Chromium in certain cases?"

Yes, in certain cases. However, I don't think it's worth another flame war about this. Even if I posted some benchmarks all you'd have is a stream of people sharing their anecdata trying to confirm or deny the accuracy of the benchmarks. Can we nip this in the bud before it begins and just be glad that Electron has some competition to help push it forward?

Agreed. I'm not a fan of web apps/wrappers in general, but they're here and they're clearly not going away any time soon, so it's important that they don't become steeped in a Blink-based monoculture. Competition is healthy.

my thoughts exactly. mozilla arguably set the ball rolling on this stuff with the Prism project, which allowed turning web-pages into chromeless browser window apps, with their own desktop icons and everything

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

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?

hm... maybe providing something like a VC++ runtime installer? if it's about portable exes, then I'd like to know more :)

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.

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

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.

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

and electron:

https://github.com/electron-userland/electron-prebuilt

But your distributed applications certainly do not use those installed by npm, right?

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

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.

You may bundle the Electron runtime in an app or not. An app is started by "electron main.js", so once Electron is installed you have just to download an app and create an icon. Example with https://github.com/Scriptol/Advanced-Editor

> One difference (Don't know if its a benefit) is that it uses a common runtime.

You keep saying this. It's not mentioned in the post, and it doesn't match how qbrt is actually doing things. Where are you seeing it?

In theory the app could actually be cross platform for every platform that supports nodejs and gecko instead of being only cross platform for the platforms that the developer wants to support. You'd have a generic build where native libraries are compiled with webassembly and then specialised builds for each supported platform for more performance.

Good point. If you don't have to build for architecture it could run anywhere

is this a potential electron competitor/alternative?

Edit: Electron really needs a competitor/alternative

Not exactly, but there was an Electron-compatible prototype for a bit, called Positron.

Myk wrote about taht as well: https://mykzilla.org/2017/03/08/positron-discontinued/

Well on second thought I guess qbrt is more or less trying to solve the same problem as Electron, without being compatible as it is "simplifying the process of developing and packaging a desktop app using web technologies."

There is nw.js:

https://nwjs.io/

I used it to port a frontend for an application that requires multiple toplevel windows and found its API way easier for that particular problem.

Edit: also a rather informative statement by the author on the relationship between nw.js (which used to be node-webkit) and Electron:

https://groups.google.com/forum/#!topic/nwjs-general/LIrC7zH...

+1 for nw.js...Electron is just a bloated version of nw.js

Actually I tested both with a hello world app just this week and nw.js used more RAM than electron

Electron apps display misleading RAM statistics in Task Manager, at least on Windows. There are multiple content processes that you have to compare paths to find.

> Electron really needs a competitor/alternative

http://sciter.com - single dll/so of 5mb - embeddable HTML/CSS engine designed specifically for running desktop UIs.

Never heard of this. I wonder why it's not more popular?

Probably licensing + pricing.

not open source, for one. looks interesting, and it might be a pragmatic choice if you're a company developing a desktop app, but for a hobbyist programmer i see no real appeal in a closed source framework.

https://sciter.com/prices/. It has a free binary-only tier. Not entirely sure what the restrictions are. I also don't quite get their renewal pricing - it's not cheap at all.

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.

HTA?

https://en.m.wikipedia.org/wiki/HTML_Application

That's it, thanks.

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.

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

It is called Qt, wxWidgets, JavaFX, Xamarin.Forms,....

You forgot GTK. I think he meant that electron had dominated the JavaScript-on-the-desktop scene

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.

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

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.

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?

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://blog.mozilla.org/addons/2017/02/16/the-road-to-firef...

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

There are plans to rewrite Thunderbird because of this issue.

https://news.ycombinator.com/item?id=14156251

It's probably a little late on this discussion, but I've just discovered that qbrt can also run XUL

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

https://en.wikipedia.org/wiki/Q*bert

I had assumed that was intentional...

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.

is this like the broadway backend for gtk?

https://vimeo.com/21062117

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.

This is being worked on by Mozilla https://github.com/mozilla/spidernode

Reply on news.ycombinator.com