9 ms·

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

165 points by roryisok 9y ago

deleted 9y ago
[deleted]
carussell 9y ago
> 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 9y ago
  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 9y ago
    How important is binary size for desktop apps, though?
    - roryisok 9y ago
      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
  - carussell 9y ago
    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.
oblib 9y ago
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.
Zekio 9y ago
is this a potential electron competitor/alternative? Edit: Electron really needs a competitor/alternative
- rhelmer 9y ago
  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/ https://mykzilla.org/2017/03/08/positron-discontinued/
  - rhelmer 9y ago
    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."
- jancsika 9y ago
  There is nw.js: https://nwjs.io/ 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/LIrC7zHtQdo https://groups.google.com/forum/#!topic/nwjs-general/LIrC7zH...
  - pupdogg 9y ago
    +1 for nw.js...Electron is just a bloated version of nw.js
    - roryisok 9y ago
      Actually I tested both with a hello world app just this week and nw.js used more RAM than electron
      - 9y ago
cocktailpeanuts 9y ago
What's the benefit of using this instead of Electron? Genuinely curious about the benefit. Is Gecko better than Chromium in certain cases?
- ZenoArrow 9y ago
  > "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?
  - kitsunesoba 9y ago
    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.
    - roryisok 9y ago
      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
- roryisok 9y ago
  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-huge-numbers-of-tabs-leaves-chrome-in-the-dust http://www.techradar.com/news/firefoxs-blazing-speed-with-hu...]
rxlim 9y ago
No offence, but please write your desktop "apps" as native programs or don't write them at all, we have enough of this slow and bloated web shit on desktop already. Sorry.
- pitaj 9y ago
  So you;d rather have fewer useful GUI programs? That's a very unpopular opinion. What incentive does any developer have to do as you say?
  - Endy 9y ago
    The writing of non-interpreted code (i.e. assembler, binary, etc), smaller programs that work longer, and less overall dumbing-down of computer use?
    - dungle6 9y ago
      Don't forget better UX. The whole practice of UX is utter hogwash. Comparisons between 3 or 4 (or 100) solutions that are shitty at baseline is not honest at all.
  - userbinator 9y ago
    So you;d rather have fewer useful GUI programs? If they are of higher quality, yes. In fact, there are plenty of useful and native applications which many just haven't discovered --- you could argue they spent far more effort on the product than marketing it. Related: https://news.ycombinator.com/item?id=14748924 https://news.ycombinator.com/item?id=14748924 What incentive does any developer have to do as you say? I'm not the one you're replying to, but as developer myself I don't want to have to put up with "this slow and bloated web shit on desktop" either. IMHO increasing the combined computing resource consumption of all your users significantly just so you can make your product a little more easily is the complete opposite of being a good developer. The argument about it being "easier" might be questionable too --- I've been programming native GUI apps for over a decade and for the type of functionality that a lot of these web-app-packaged-with-browser monstrosities are doing, it'd probably take me far less time to write something in pure Win32 and X than download and figure out how to use Electron. Some may argue that the initial learning curve is steeper, but then after that you're a "real native coder" instead of a "web apper" and will be making far more efficient applications for everyone.
deleted 9y ago
[deleted]
zerr 9y ago
I wonder what's the state of XUL, if anyone using it in the wild (besides Mozilla)...
- ZenoArrow 9y ago
  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 9y ago
    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 9y ago
      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-for-firefox-57 https://www.neowin.net/news/mozilla-is-working-on-a-new-ui-f... https://blog.mozilla.org/addons/2017/02/16/the-road-to-firefox-57-compatibility-milestones/ https://blog.mozilla.org/addons/2017/02/16/the-road-to-firef...
      - 482794793792894 9y ago
        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
frik 9y ago
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 9y ago
  This is being worked on by Mozilla https://github.com/mozilla/spidernode https://github.com/mozilla/spidernode
muterad_murilax 9y ago
"Qbrt" makes me think of the classic arcade game: https://en.wikipedia.org/wiki/Q*bert https://en.wikipedia.org/wiki/Q*bert
- bluejekyll 9y ago
  I had assumed that was intentional...
z3t4 9y ago
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.
appleflaxen 9y ago
is this like the broadway backend for gtk? https://vimeo.com/21062117 https://vimeo.com/21062117

165 points by roryisok 9y ago

deleted 9y ago

[deleted]

> 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 9y ago
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 9y ago
  How important is binary size for desktop apps, though?
  - roryisok 9y ago
    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
- carussell 9y ago
  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.

oblib 9y ago

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.

Zekio 9y ago

is this a potential electron competitor/alternative? Edit: Electron really needs a competitor/alternative

rhelmer 9y ago
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/ https://mykzilla.org/2017/03/08/positron-discontinued/
- rhelmer 9y ago
  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."
jancsika 9y ago
There is nw.js: https://nwjs.io/ 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/LIrC7zHtQdo https://groups.google.com/forum/#!topic/nwjs-general/LIrC7zH...
- pupdogg 9y ago
  +1 for nw.js...Electron is just a bloated version of nw.js
  - roryisok 9y ago
    Actually I tested both with a hello world app just this week and nw.js used more RAM than electron
    - 9y ago

cocktailpeanuts 9y ago

What's the benefit of using this instead of Electron? Genuinely curious about the benefit. Is Gecko better than Chromium in certain cases?

ZenoArrow 9y ago
> "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?
- kitsunesoba 9y ago
  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.
  - roryisok 9y ago
    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
roryisok 9y ago
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-huge-numbers-of-tabs-leaves-chrome-in-the-dust http://www.techradar.com/news/firefoxs-blazing-speed-with-hu...]

rxlim 9y ago

No offence, but please write your desktop "apps" as native programs or don't write them at all, we have enough of this slow and bloated web shit on desktop already. Sorry.

pitaj 9y ago
So you;d rather have fewer useful GUI programs? That's a very unpopular opinion. What incentive does any developer have to do as you say?
- Endy 9y ago
  The writing of non-interpreted code (i.e. assembler, binary, etc), smaller programs that work longer, and less overall dumbing-down of computer use?
  - dungle6 9y ago
    Don't forget better UX. The whole practice of UX is utter hogwash. Comparisons between 3 or 4 (or 100) solutions that are shitty at baseline is not honest at all.
- userbinator 9y ago
  So you;d rather have fewer useful GUI programs? If they are of higher quality, yes. In fact, there are plenty of useful and native applications which many just haven't discovered --- you could argue they spent far more effort on the product than marketing it. Related: https://news.ycombinator.com/item?id=14748924 https://news.ycombinator.com/item?id=14748924 What incentive does any developer have to do as you say? I'm not the one you're replying to, but as developer myself I don't want to have to put up with "this slow and bloated web shit on desktop" either. IMHO increasing the combined computing resource consumption of all your users significantly just so you can make your product a little more easily is the complete opposite of being a good developer. The argument about it being "easier" might be questionable too --- I've been programming native GUI apps for over a decade and for the type of functionality that a lot of these web-app-packaged-with-browser monstrosities are doing, it'd probably take me far less time to write something in pure Win32 and X than download and figure out how to use Electron. Some may argue that the initial learning curve is steeper, but then after that you're a "real native coder" instead of a "web apper" and will be making far more efficient applications for everyone.

deleted 9y ago

[deleted]

zerr 9y ago

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

ZenoArrow 9y ago
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 9y ago
  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 9y ago
    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-for-firefox-57 https://www.neowin.net/news/mozilla-is-working-on-a-new-ui-f... https://blog.mozilla.org/addons/2017/02/16/the-road-to-firefox-57-compatibility-milestones/ https://blog.mozilla.org/addons/2017/02/16/the-road-to-firef...
    - 482794793792894 9y ago
      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

frik 9y ago

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 9y ago
This is being worked on by Mozilla https://github.com/mozilla/spidernode https://github.com/mozilla/spidernode

muterad_murilax 9y ago

"Qbrt" makes me think of the classic arcade game: https://en.wikipedia.org/wiki/Q*bert https://en.wikipedia.org/wiki/Q*bert

bluejekyll 9y ago
I had assumed that was intentional...

z3t4 9y ago

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.

appleflaxen 9y ago

is this like the broadway backend for gtk? https://vimeo.com/21062117 https://vimeo.com/21062117