Getting started with NodeGUI, a Qt-based library for desktop applications(hibbard.eu)
hibbard.eu
Getting started with NodeGUI, a Qt-based library for desktop applications
https://hibbard.eu/node-gui/
55 comments
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.
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
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
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.
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."
"Pot, I'd like to introduce you to kettle."
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.
> 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...
People have been complaining for a fair amount of time.
https://lists.gnu.org/archive/html/directory-discuss/2017-12...
Is this a FUD based comment about node?
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.
The point, in my estimation, would be to have all of the Javascript libraries you have accessible in node (which you use already on other projects, and are very familiar with) accessible while also having access to a full desktop GUI in that environment.
This is a reasonable alternative to Electron, without requiring you to have another copy of Chromium on your machine for every Javascript-based desktop application you write.
I suspect it will perform much better than Electron also, assuming the author has done a decent job integrating Qt's API with node.
All of that being said, I have not tried Node-GUI, so I don't know how well it works.
EDIT: I have also not looked at QT's built-in Javascript support in a long time, and was not aware that later versions support ES6. I have never written a Qt app using javascript, I've only used C++, and a small amount of python. It would be interesting to explore the implications of having the node ecosystem available to a Qt app, and how that compares to the built-in Javascript support alone.
This is a reasonable alternative to Electron, without requiring you to have another copy of Chromium on your machine for every Javascript-based desktop application you write.
I suspect it will perform much better than Electron also, assuming the author has done a decent job integrating Qt's API with node.
All of that being said, I have not tried Node-GUI, so I don't know how well it works.
EDIT: I have also not looked at QT's built-in Javascript support in a long time, and was not aware that later versions support ES6. I have never written a Qt app using javascript, I've only used C++, and a small amount of python. It would be interesting to explore the implications of having the node ecosystem available to a Qt app, and how that compares to the built-in Javascript support alone.
What I don't understand is comments like this. Be nicer. Don't automatically assume a project is worthless from a surface level understanding. You don't know what led to its creation.
As far as I know QML still only supports ES5. That’s not very appealing if you’ve been working with Typescript or Babel for awhile. Plus all the node libraries people may be used to working with would be available.
According to the docs (https://doc.qt.io/qt-5/whatsnew512.html):
"The JavaScript engine now supports ECMAScript 7. This includes an upgrade to ECMAScript 6"
and:
"ECMAScript modules can now be loaded directly with QJSEngine::importModule() [ https://doc.qt.io/qt-5/qjsengine.html#importModule] and imported in .qml files when using the .mjs file extension."
Although, it looks like the ECMAScript 7 support might be incomplete, with Promises perhaps being buggy and arrow functions perhaps not working: https://forum.qt.io/topic/100526/what-parts-of-ecmascript-7-...
Looks like transpiling with Babel works fairly well for a lot of things
relevant discussion: https://bugreports.qt.io/browse/QTBUG-47735
"The JavaScript engine now supports ECMAScript 7. This includes an upgrade to ECMAScript 6"
and:
"ECMAScript modules can now be loaded directly with QJSEngine::importModule() [ https://doc.qt.io/qt-5/qjsengine.html#importModule] and imported in .qml files when using the .mjs file extension."
Although, it looks like the ECMAScript 7 support might be incomplete, with Promises perhaps being buggy and arrow functions perhaps not working: https://forum.qt.io/topic/100526/what-parts-of-ecmascript-7-...
Looks like transpiling with Babel works fairly well for a lot of things
relevant discussion: https://bugreports.qt.io/browse/QTBUG-47735
With QML/QtQuick, can you do all things you can do with C++ and Qt widgets?
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 [1] https://doc.qt.io/qt-5/qtquick-codesamples.html [2] https://doc.qt.io/qt-5/qtquickcontrols2-examples.html [3] https://doc.qt.io/qt-5/examples-widgets.html
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 [1] https://doc.qt.io/qt-5/qtquick-codesamples.html [2] https://doc.qt.io/qt-5/qtquickcontrols2-examples.html [3] https://doc.qt.io/qt-5/examples-widgets.html
Actually you can do even more, because Qt considers Widgets done and all new APIs are mostly focused on QML/QtQuick.
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/
> 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.)
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.)
A small recent thread: https://news.ycombinator.com/item?id=20706163
Reminds me a bit of React-Native-Desktop, which also uses Qt.
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?
Have you had any experience with react-native-desktop?
Sorry, no. Just React-Native on mobile/web.
React Native uses UWP on Windows.
https://www.microsoft.com/developerblog/2016/05/26/creating-...
https://www.microsoft.com/developerblog/2016/05/26/creating-...
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.
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.
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.
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.
interesting project. I found and had a play with pyqt just recently and quite liked it. https://github.com/pyqt/examples
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.
Honestly, this doesn't make sense to me at all.
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.
I would rather have any native alternative to electron than any electron app any day.
That's clearly not the "whole point", given the number of node-based applications that do not have a matching website.
That also does not make sense to me.
I already have a browser installed and PWAs are a thing.
I already have a browser installed and PWAs are a thing.
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.
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.
There are also hosted web apps / progressive web apps. It's like Electron but without Node.JS.
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.
There is also qt/qml for javascript.
> 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.
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.
>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.
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.
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.
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).
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).
Ok, we've changed the title to use language closer to how the project describes itself.
Submitted title was "Node-GUI Qt-Based Alternative to Electron"
Submitted title was "Node-GUI Qt-Based Alternative to Electron"
[deleted]
Next step - get rid of Node/JS and use plain old Qt natively, e.g. with C++.
Next step - just go use windows forms. Ammirite guys?!?!?!
Who doesn't love outdated frameworks that artificially limit my options and dev resources!
Who doesn't love outdated frameworks that artificially limit my options and dev resources!
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.
To talk about outdated frameworks, first provide tooling at the same feature level.
MSFT did get their tooling right. That's what developers liked early on and became somewhat dependent on was their tools.
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, ...
Be it Borland, Microsoft, Google, Apple, Oracle, OutSystems, Adobe, Qt, ...
That would kinda defeat the purpose of this 'Node-GUI' project.
[EDIT] This project literally brings Node/JS/CSS on top of Qt - Node-GUI without Node/JS is, you guessed it - Qt.
[EDIT] This project literally brings Node/JS/CSS on top of Qt - Node-GUI without Node/JS is, you guessed it - Qt.
Qt already supports JavaScript out of the box, no need for node.
Yes, but it may be important to some folks to have the node runtime available for an application they would like to be desktop based.
I agree, though, that it would be important to decide if the built-in Javascript support fills the need before considering a solution like NodeGUI.
I agree, though, that it would be important to decide if the built-in Javascript support fills the need before considering a solution like NodeGUI.
Shhhhhh. That's blasphemy here.