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