
Getting started with NodeGUI, a Qt-based library for desktop applications - ausjke
https://hibbard.eu/node-gui/
======
rvz
> NodeGUI is a young project and unfortunately cross-platform support is not
> quite there yet. That is to say, if you need cross-platform builds, you have
> to run the packer in each of the different OS environments.

Don't all great projects start young and gain interested folks to make it
widely used? Also Qt (Which is a source-level cross-platform SDK) requires you
to be running the target you are compiling for each platform and that is no
different for compiling 'electron executables' targeting Windows, Mac and
Linux, but the source code itself is cross-platform. So I think NodeGUI does
qualify as an alternative.

Perhaps he is looking some form of compiled 'bytecode' bundle that can be
loaded into the VM and can call the Qt GUI shims no matter the platform? Maybe
WASI can do such a thing in the future for this project but for now, that
sounds a lot like the 'cross-platform Java' way which would be indeed truly
cross-platform.

~~~
pandalicious
>Don't all great projects start young and gain interested folks to make it
widely used?

The counterpoint to this is that making a robust cross-platform GUI library is
a massive endeavor and there is a veritable mountain of cross-platform gui
projects out there and overwhelmingly they end up as never-finished abandoned
projects. The exceptions like Qt and electron that actually succeeded tend to
have large organizations behind them.

------
sroussey
Hard to read the article after baseless FUD/BS privacy concerns about Electron
or anything from Google, and then jumps right into using node. WAT.

~~~
nocman
In my opinion, there is nothing FUD or BS about the statements made about
privacy concerns related to Google and Chromium.

He didn't say he absolutely knows that Chromium is phoning home "in some way
shape or form". He just said that he doesn't believe it can be trusted not to.
It's a legitimate concern that many people have, given Google's size and scope
of influence. You may not share his concern, but that doesn't make his
illegitimate.

If your objection is based on the fact that the project is using node, and
there are also plenty of "phoning home" opportunities there, well I can see
that too (npm/yarn being as they are), and I think it is something developers
need to consider also. npm, Inc has perhaps a lot more power to abuse than
many developers ever think about, but it is not near the scope of Google's.
Facebook develop's yarn, which comes with its own set of concerns, as well,
but you would not have to use yarn with NodeGUI (assuming you can, I haven't
looked).

Assuming your objections were based on node having it's own privacy concerns,
I guess rather than labeling the discussion of Google/Chromium privacy
concerns as "FUD/BS privacy concerns about Electron or anything from Google",
I would have just pointed out the concerns with node.

EDIT: oh, and of course, since V8 is Chromium's javascript engine, and that's
what node uses, well maybe NodeGUI dev just didn't think about that. :-D

~~~
weare138
Google Chrome? Yes, it is definitely a privacy concern but Chromium is open
source. Debian includes Chromium packages and if there were legitimate
concerns about Chromium it would have never been distributed in the official
Debian repositories. If the author knows there's something sketchy going on
with Chromium they should present their findings, otherwise it's just
unsupported conjecture.

~~~
johndubchak
You think relying on Debian as proof there isn't lies outside the bounds of
conjecture?

"Pot, I'd like to introduce you to kettle."

~~~
weare138
The author provided no evidence and it passed the Debian project auditing
process, among several other distribution audits. I specifically mentioned
Debian because their standards for privacy and open-source purism are just
_sightly_ below Richard Stallman level. Believe me, someone would have
complained about it by now.

~~~
jcelerier
> Believe me, someone would have complained about it by now.

People have been complaining for a fair amount of time.

[https://lists.gnu.org/archive/html/directory-
discuss/2017-12...](https://lists.gnu.org/archive/html/directory-
discuss/2017-12/msg00008.html)

------
hackcasual
This just seems like it's a well designed library for using Qt from Node. If
you're going to not using HTML for your UI, not sure it makes sense to market
this as an alternative for Electron.

~~~
nocman
That's not entirely true. Electron's target is desktop apps written in
Javascript. While it is true that the GUI is not written in HTML, you are
still writing the logic of the application in Javascript, so there is still a
large amount of overlap.

And if the application uses a _lot_ less RAM and performs way better (as I
suspect it may), then a lot of people would be willing to give up using HTML
for the GUI, so the app doesn't run like a dog and/or drain your battery. I
don't know how Node-GUI performs or how much RAM it uses, but being that Qt is
the GUI layer it is using, I suspect it will be a sizeable improvement over
Electron.

I understand where you are coming from. A lot of the selling point of Electron
is reusing GUI components from web applications (and also just using the same
tools to create GUIs that you use for web development). This tool obviously
won't give you that.

But I could see people using it as an alternative for Javascript apps on the
desktop (especially if they prove to be much less piggish than a lot of
Electron apps tend to be).

------
Barrin92
Given that Qt already supports declarative JS like UI development with QML
which I think is literally a stripped down JS and Python/C++ on the backend I
honestly don't really see the point of this.

~~~
kodablah
With QML/QtQuick, can you do all things you can do with C++ and Qt widgets?

~~~
HDevo
I'd say they have different use cases.

If you want to develop native-looking or information-dense UIs, Qt Widgets is
the way to go. If you want to create a more Electron-like UI or develop
something for mobile devices, I'd go with Qt Quick. It's also possible to
combine both by embedding a QQuickWidget[0] inside a Qt Widgets application.

If you want to get an idea about what both solutions provide, take a look at
the examples for Qt Quick[1] and Qt Widgets[2]. Especially Qt Quick
Controls[3] are useful to see what UI controls are available in Qt Quick.

I'm working on a desktop app in Qt Quick using QML and C++. Happy to elaborate
if there's interest.

[0]
[https://doc.qt.io/qt-5/qquickwidget.html](https://doc.qt.io/qt-5/qquickwidget.html)
[1] [https://doc.qt.io/qt-5/qtquick-
codesamples.html](https://doc.qt.io/qt-5/qtquick-codesamples.html) [2]
[https://doc.qt.io/qt-5/qtquickcontrols2-examples.html](https://doc.qt.io/qt-5/qtquickcontrols2-examples.html)
[3] [https://doc.qt.io/qt-5/examples-
widgets.html](https://doc.qt.io/qt-5/examples-widgets.html)

------
xvilka
Next step - get rid of Node/JS and use plain old Qt natively, e.g. with C++.

~~~
horsawlarway
Next step - just go use windows forms. Ammirite guys?!?!?!

Who doesn't love outdated frameworks that artificially limit my options and
dev resources!

~~~
pjmlp
Oh how I wish some frameworks would be half as capable as Windows Forms and
the third party vendors eco-system.

To talk about outdated frameworks, first provide tooling at the same feature
level.

~~~
johndubchak
MSFT did get their tooling right. That's what developers liked early on and
became somewhat dependent on was their tools.

~~~
pjmlp
I rather be dependent on vendors' tooling and enjoy productivity than dealing
with lower grade tooling for the greater good or whatever.

Be it Borland, Microsoft, Google, Apple, Oracle, OutSystems, Adobe, Qt, ...

------
sorenjan
If you want to use Qt and really need to use Javascript maybe Cutee would be
an option too. Disclaimer: I've never used it.
[https://cutetee.it/](https://cutetee.it/)

------
adontz
Why not QML then?!

~~~
detaro
Just one possible answer: Because Qt QML and Qt Widgets are not equally good
at different things.

------
jchw
> Google has become unbelievably data hungry in the past few years, and in my
> opinion Chromium cannot be trusted to not phone home in some way shape or
> form.

This is not a particularly Google-free solution as upstream Node.JS depends on
V8.

(Disclaimer: I am an employee of Google. I do not work on Chromium or V8. All
opinions expressed are my own and not those of my employer.)

------
dang
A small recent thread:
[https://news.ycombinator.com/item?id=20706163](https://news.ycombinator.com/item?id=20706163)

------
k__
Reminds me a bit of React-Native-Desktop, which also uses Qt.

~~~
Timothycquinn
Was also thinking of Proton-Native. Was hacking with proton recently and it
was not working correctly on a few fronts.

Have you had any experience with react-native-desktop?

~~~
k__
Sorry, no. Just React-Native on mobile/web.

------
markandrewj
This is an interesting project, that I could see being useful, but it's not an
alternative to Electron if it can't cross compile.

------
gambler
Enough with ducktape. Just use a fucking Smalltalk already. Cuis, Squak,
Pharo. If you want to ship a runtime environment with your apps you might as
well ship a good one. They have good UI development tools, fast VM and have
(from my experience) much better cold startup time than anything based on
Electron or Java.

~~~
scroot
I would like to do this for my next project, but unfortunately appearance
matters to clients. It is far easier to make something that looks "modern"
using something like Electron than it is any of the open source Smalltalk
systems.

The Pharo team are doing excellent work to try to change this. In particular,
Spec2 promises to deliver multiple backends including GTK. I think that can
really change things for Smalltalk users. But for now it's just not there. I
wish appearances didn't matter. But they do.

------
byteface
interesting project. I found and had a play with pyqt just recently and quite
liked it. [https://github.com/pyqt/examples](https://github.com/pyqt/examples)

------
d--b
Er. The whole point of electron is to use the same code as your website to
generate a desktop app.

Honestly, this doesn't make sense to me at all.

~~~
kgraves
My screaming 4GB of RAM laptop would like to have a word with you.

I would rather have any native alternative to electron than any electron app
any day.

------
chodeboy
This is kind of the reverse of what I would want.

I want to use html/css/js to create my front-end, Although it is more resource
intensive then Qt, it is simply more flexible and has a much richer eco-system
to rely on.

Meanwhile the usage of chrome as a run-time is one of the worst parts of
electron as every app consumes a lot more memory than a "native" application
would need. These days Chrome is so highly sophisticated by now you could
easily call it an OS. It comes with a lot of baggage from a Driverstack for
Sound, Joysticks and Accelerometers to a whole suite of debugging tools.

Don't get me wrong. Electron is good for what it is: a way to easily write
portable apps which can share codebase with a SaaS-Platforms. I would just
wish developers would have just taken a different approach e.g. using a more
striped down version of chrome or maybe even use Firefox/Servo.

~~~
chrisco255
Node and Chrome are both built on V8, so the synergy between the two is
significant. I agree though, it would be interesting to see a Servo-based app
framework, but I suppose Electron already has first-mover advantage at this
point.

------
z3t4
There is also qt/qml for javascript.

