6 ms·

What about good ol' QT?

drinchev 8y ago
Last time I checked the bindings of QT[1] for NodeJS were not updated since 6 years. I think they are still unmaintained and also are lacking the community around it. I think GitHub embracing Chrome-wrapped-apps was a significant move, since no other company did something similar for desktop javascript applications. Maybe we will need to wait a bit more, until some of the big tech companies realises that having better QT / GTK bindings and build tools, examples, proper documentation will benefit a lot the company and the community around it. Until then, we are stuck. [1] : https://github.com/arturadib/node-qt https://github.com/arturadib/node-qt
- rhodysurf 8y ago
  Then learn a new language? It shouldn’t be that hard to transition between languages for UI stacks
  - dspillett 8y ago
    > Then learn a new language? Learn a new language (Python/C++/other) in order to learn and use a different framework (Qt)? Thanks for your advice I'll down tools right now and get on with that using my time the way I want to. (Actually I've never developed anything using Electron yet, though some personal projects may get implemented that way in future should they ever get off the ground) I fully understand much of the criticism of Electron and similar: the results are rather bulky in terms of both package size and memory use (and if you aren't careful sometimes CPU use) which can add up to quite a performance hit if running a number of small apps/tools that are large because of the framework. For interactive (or script-called) non-resident utilities startup time can be a significant issue too. But there are a lot of entitled people out there who seem to be of a mind that because they don't like Electron (for those reasons or whatever else) they have the right to demand that developers stop using it. If you don't want to use an Electron driven application then the solution is to not use that Electron driven application. There are no doubt alternatives out there. If not then the deep knowledge you have that makes you an expert on why it would be better developed other ways should allow you to write your own and compete. This is true for both paid-for services like this (show them who is boss by collectively voting with your wallets) and free and/or open source options (in which case making demands of the creator/maintainer seems even more egregious IMO). </rant>
    - rhodysurf 8y ago
      Isn’t it just as entitled to refuse learning something because you will only use the language you want? Even if it’s forcing a square peg in a round hole? Cmon tho, any competent engineer can switch between languages without many issues.
      - dspillett 8y ago
        > Isn’t it just as entitled to refuse learning something because you will only use the language you want? Not really IMO. If users don't like it, they can usually use something else. A point I didn't make clear at all is "you have used Electron, eww" is a poor judgement. "It is too slow for my needs, look at this benchmark" or "it takes too much RAM, look at the problem this causes" or "it takes a while to load, look at this metric that shows the effect it has on me" are all valid and constructive criticisms. "I don't like part of what, to me as a user should be a black box, is made with" isn't (if it works for you, it works, if it doesn't for a practical reason then it doesn't, how it is made and how the maintainers might solve your issue if they chose to address it is their problem). If going from a fellow developers PoV then by all means give constructive critique but "you use Electron, you a stupid" (a tone I've seen a fair few times) isn't that, and as a developer if you want an X made a different way go make an X that way (or, back to user-land, go find one made that way, there will probably be other options). > Even if it’s forcing a square peg in a round hole? This can be a problem created by switching language (or framework, or other) without sufficient acclimation time: you end up using the new tools like they were your old tools, which might produce something that works badly because the new options are not optimal for that construction pattern or at least that pattern does not use the other tools to their best advantage. Have you never heard the pained yelps of "but... that just isn't Pythonic!" or similar? > Cmon tho, any competent engineer can switch between languages without many issues. Depending on experience level, that is rarely without at least some context switching cost even if you are already familiar with what you are switching to. Maybe you are a natural star engineer for whom this is as close to zero as makes no odds, but most of use are not quite that perfect!
      - hajile 8y ago
        The basics of switching to a language in the same/similar paradigm isn't that hard. Re-learning tooling, libraries, etc takes a very long time. I can rattle off reams of stuff in the languages I know, but I'd have to spend hours searching for that same stuff in other languages.
- solarkraft 8y ago
  But why would I want to use Node JS?
  - dspillett 8y ago
    The obvious answer to that is "because you are familiar and comfortable with JS and don't want to (or ATM don't have time to) learn the ins-and-outs of another language and its ecosystem." That seems to be one of the main drivers behind Electron's popularity, others being easier cross-platform support (or at least the perception of that) and the vote of confidence in its stability from the likes of MS using it in their products (primarily VSCode in MS's case). What would be your alternate suggestion, and why? (genuine question rather than a rhetorical dig: I plan to tinker with Electron for a couple of projects soon so if there is something better (or simply that is a suitable alternative to consider) out there I'm not aware of, I'd like to be made aware)
  - sime2009 8y ago
    * runs on a fast JIT * package management and modules actually work * huge ecosystem of packages * ability to use native code modules in needed * has webassembly too * runs a huge range of other languages. It can fill a role similar to the JVM and .Net runtimes in this respect.
    - JasonFruit 8y ago
      Okay, I'm going to jump on the "package management and modules actually work" thing; I'm not a noder, but I've considered using several tools that are built on Node, and every time — almost literally — `npm install whatever` fails. Linux, Windows, doesn't matter: I see the latest cool thing on Node, try to install it, and think, "If they can't even get installation to work, why should I bother?" Am I alone in this? I don't have that problem with other tools, so I don't think I'm unable to read and follow instructions. I'm disappointed, because there are a couple of toolkits for mobile development that I'd love to use, and there's a big Node roadblock in my way.
      - codefined 8y ago
- herbst 8y ago
  Pretty sure no one thinks 'js' when they think about slim desktop apps
sime2009 8y ago
The problem is that your language choice is very limited. You can choose C++, no thanks, or Python which is very slow. There are no good options for languages or VMs on Qt in the Java/C#/VM/Jit range of the language performance spectrum.
- danieldk 8y ago
  There are no good options for languages or VMs on Qt in the Java/C#/VM/Jit range of the language performance spectrum. Qt had pretty good Java support with Qt Jambi. But nobody cared and they cancelled the product. https://en.wikipedia.org/wiki/Qt_Jambi https://en.wikipedia.org/wiki/Qt_Jambi
  - sime2009 8y ago
    alas, there have been many attempts over the years for language bindings even to interesting targets like the JVM and mono/.Net, but none of them really gained "escape velocity", except for PyQt (which is great might I add).
- sametmax 8y ago
  Python and js apps have the same order of magnitude of speed. But pyqt apps are way faster than electron
  - sime2009 8y ago
    No they don't. JS running on a modern engine like V8 are easily 10x faster than CPython which PyQt uses. If you think Python and JS are about the same speed then it is because of Qt itself, but certainly not because of CPython.
    - yzmtf2008 8y ago
      > JS running on a modern engine like V8 are easily 10x faster than CPython which PyQt uses. Citation needed. As I've said numerous times before, saying one language is faster than another is pointless. You have to give a full context around it. What particular scenario is CPython slower than V8? While it's true that a pure CPython tight loop will be slower than one in V8, I have a hard time imagining that being the bottleneck of desktop applications.
mateuszf 8y ago
I'd have to use bad old C++ with it, so how about no.
- _o_ 8y ago
  Come on, what is bad and old on c++? :)
  - mateuszf 8y ago
    I like to Keep it simple - and it's very painfull to do that in C++. Yes, you can write simple code, but it's lot easier to do it in other languages.
    - AstralStorm 8y ago
      Untrue though Qt itself is not updated to take advantage of C++14 and newer features. I'll take slightly more complex syntax over untraceable dynamic weak typing of JS. How many times have you got random undefined?
    - adtac 8y ago
      Modern C++ is not simple, but modern JavaScript is?
      - mateuszf 8y ago
        Before you use modern c++ you have to learn all the "old" features to really understand what you're doing. Also I didn't say a thing about JavaScript.
  - whyever 8y ago
    Not sure it is a good idea to use a language that is not memory safe for GUI.
    - terminalcommand 8y ago
      We are all afraid of errors due to manual memory management, but it seems wrong to me to believe that every language that is "safe" from the memory perspective is safe. I'd argue that in some situations interpreted languages are much more dangerous compared to a simple compiled language like C. With new "safe" languages you do not encounter an error most of the time, but when you do see an error it is quite discouraging to see that your "safe" language fails and you don't have any idea why it fails. In order to be safe we need simplicity. We need to move the main part of the program to compilation time to have static checks. We need to write comprehensive tests on the parts we leave to the runtime. We need to check inputs at every stage. We need to be very very careful when using concurrency. In that matter I find the OpenBSD developers' use of C much more secure than any package on npm. OTOH C++ is a different beast, it is complex, it has many fine-points to master. I'd say programming in Go and using QT could be a good choice, if you're considering memory safety above all things.
Buttons840 8y ago
Both QT and GTK have more restrictive licensing, which is fair on its own, but when comparing to Electron you have to consider it a disadvantage.
- warkdarrior 8y ago
  Qt is licenseable under LGPLv3, Electron under the MIT license. There is practically little difference between the two types of licenses.

Last time I checked the bindings of QT[1] for NodeJS were not updated since 6 years. I think they are still unmaintained and also are lacking the community around it. I think GitHub embracing Chrome-wrapped-apps was a significant move, since no other company did something similar for desktop javascript applications. Maybe we will need to wait a bit more, until some of the big tech companies realises that having better QT / GTK bindings and build tools, examples, proper documentation will benefit a lot the company and the community around it. Until then, we are stuck. [1] : https://github.com/arturadib/node-qt https://github.com/arturadib/node-qt

rhodysurf 8y ago
Then learn a new language? It shouldn’t be that hard to transition between languages for UI stacks
- dspillett 8y ago
  > Then learn a new language? Learn a new language (Python/C++/other) in order to learn and use a different framework (Qt)? Thanks for your advice I'll down tools right now and get on with that using my time the way I want to. (Actually I've never developed anything using Electron yet, though some personal projects may get implemented that way in future should they ever get off the ground) I fully understand much of the criticism of Electron and similar: the results are rather bulky in terms of both package size and memory use (and if you aren't careful sometimes CPU use) which can add up to quite a performance hit if running a number of small apps/tools that are large because of the framework. For interactive (or script-called) non-resident utilities startup time can be a significant issue too. But there are a lot of entitled people out there who seem to be of a mind that because they don't like Electron (for those reasons or whatever else) they have the right to demand that developers stop using it. If you don't want to use an Electron driven application then the solution is to not use that Electron driven application. There are no doubt alternatives out there. If not then the deep knowledge you have that makes you an expert on why it would be better developed other ways should allow you to write your own and compete. This is true for both paid-for services like this (show them who is boss by collectively voting with your wallets) and free and/or open source options (in which case making demands of the creator/maintainer seems even more egregious IMO). </rant>
  - rhodysurf 8y ago
    Isn’t it just as entitled to refuse learning something because you will only use the language you want? Even if it’s forcing a square peg in a round hole? Cmon tho, any competent engineer can switch between languages without many issues.
    - dspillett 8y ago
      > Isn’t it just as entitled to refuse learning something because you will only use the language you want? Not really IMO. If users don't like it, they can usually use something else. A point I didn't make clear at all is "you have used Electron, eww" is a poor judgement. "It is too slow for my needs, look at this benchmark" or "it takes too much RAM, look at the problem this causes" or "it takes a while to load, look at this metric that shows the effect it has on me" are all valid and constructive criticisms. "I don't like part of what, to me as a user should be a black box, is made with" isn't (if it works for you, it works, if it doesn't for a practical reason then it doesn't, how it is made and how the maintainers might solve your issue if they chose to address it is their problem). If going from a fellow developers PoV then by all means give constructive critique but "you use Electron, you a stupid" (a tone I've seen a fair few times) isn't that, and as a developer if you want an X made a different way go make an X that way (or, back to user-land, go find one made that way, there will probably be other options). > Even if it’s forcing a square peg in a round hole? This can be a problem created by switching language (or framework, or other) without sufficient acclimation time: you end up using the new tools like they were your old tools, which might produce something that works badly because the new options are not optimal for that construction pattern or at least that pattern does not use the other tools to their best advantage. Have you never heard the pained yelps of "but... that just isn't Pythonic!" or similar? > Cmon tho, any competent engineer can switch between languages without many issues. Depending on experience level, that is rarely without at least some context switching cost even if you are already familiar with what you are switching to. Maybe you are a natural star engineer for whom this is as close to zero as makes no odds, but most of use are not quite that perfect!
    - hajile 8y ago
      The basics of switching to a language in the same/similar paradigm isn't that hard. Re-learning tooling, libraries, etc takes a very long time. I can rattle off reams of stuff in the languages I know, but I'd have to spend hours searching for that same stuff in other languages.
solarkraft 8y ago
But why would I want to use Node JS?
- dspillett 8y ago
  The obvious answer to that is "because you are familiar and comfortable with JS and don't want to (or ATM don't have time to) learn the ins-and-outs of another language and its ecosystem." That seems to be one of the main drivers behind Electron's popularity, others being easier cross-platform support (or at least the perception of that) and the vote of confidence in its stability from the likes of MS using it in their products (primarily VSCode in MS's case). What would be your alternate suggestion, and why? (genuine question rather than a rhetorical dig: I plan to tinker with Electron for a couple of projects soon so if there is something better (or simply that is a suitable alternative to consider) out there I'm not aware of, I'd like to be made aware)
- sime2009 8y ago
  * runs on a fast JIT * package management and modules actually work * huge ecosystem of packages * ability to use native code modules in needed * has webassembly too * runs a huge range of other languages. It can fill a role similar to the JVM and .Net runtimes in this respect.
  - JasonFruit 8y ago
    Okay, I'm going to jump on the "package management and modules actually work" thing; I'm not a noder, but I've considered using several tools that are built on Node, and every time — almost literally — `npm install whatever` fails. Linux, Windows, doesn't matter: I see the latest cool thing on Node, try to install it, and think, "If they can't even get installation to work, why should I bother?" Am I alone in this? I don't have that problem with other tools, so I don't think I'm unable to read and follow instructions. I'm disappointed, because there are a couple of toolkits for mobile development that I'd love to use, and there's a big Node roadblock in my way.
    - codefined 8y ago
herbst 8y ago
Pretty sure no one thinks 'js' when they think about slim desktop apps

sime2009 8y ago

The problem is that your language choice is very limited. You can choose C++, no thanks, or Python which is very slow. There are no good options for languages or VMs on Qt in the Java/C#/VM/Jit range of the language performance spectrum.

danieldk 8y ago
There are no good options for languages or VMs on Qt in the Java/C#/VM/Jit range of the language performance spectrum. Qt had pretty good Java support with Qt Jambi. But nobody cared and they cancelled the product. https://en.wikipedia.org/wiki/Qt_Jambi https://en.wikipedia.org/wiki/Qt_Jambi
- sime2009 8y ago
  alas, there have been many attempts over the years for language bindings even to interesting targets like the JVM and mono/.Net, but none of them really gained "escape velocity", except for PyQt (which is great might I add).
sametmax 8y ago
Python and js apps have the same order of magnitude of speed. But pyqt apps are way faster than electron
- sime2009 8y ago
  No they don't. JS running on a modern engine like V8 are easily 10x faster than CPython which PyQt uses. If you think Python and JS are about the same speed then it is because of Qt itself, but certainly not because of CPython.
  - yzmtf2008 8y ago
    > JS running on a modern engine like V8 are easily 10x faster than CPython which PyQt uses. Citation needed. As I've said numerous times before, saying one language is faster than another is pointless. You have to give a full context around it. What particular scenario is CPython slower than V8? While it's true that a pure CPython tight loop will be slower than one in V8, I have a hard time imagining that being the bottleneck of desktop applications.

mateuszf 8y ago

I'd have to use bad old C++ with it, so how about no.

_o_ 8y ago
Come on, what is bad and old on c++? :)
- mateuszf 8y ago
  I like to Keep it simple - and it's very painfull to do that in C++. Yes, you can write simple code, but it's lot easier to do it in other languages.
  - AstralStorm 8y ago
    Untrue though Qt itself is not updated to take advantage of C++14 and newer features. I'll take slightly more complex syntax over untraceable dynamic weak typing of JS. How many times have you got random undefined?
  - adtac 8y ago
    Modern C++ is not simple, but modern JavaScript is?
    - mateuszf 8y ago
      Before you use modern c++ you have to learn all the "old" features to really understand what you're doing. Also I didn't say a thing about JavaScript.
- whyever 8y ago
  Not sure it is a good idea to use a language that is not memory safe for GUI.
  - terminalcommand 8y ago
    We are all afraid of errors due to manual memory management, but it seems wrong to me to believe that every language that is "safe" from the memory perspective is safe. I'd argue that in some situations interpreted languages are much more dangerous compared to a simple compiled language like C. With new "safe" languages you do not encounter an error most of the time, but when you do see an error it is quite discouraging to see that your "safe" language fails and you don't have any idea why it fails. In order to be safe we need simplicity. We need to move the main part of the program to compilation time to have static checks. We need to write comprehensive tests on the parts we leave to the runtime. We need to check inputs at every stage. We need to be very very careful when using concurrency. In that matter I find the OpenBSD developers' use of C much more secure than any package on npm. OTOH C++ is a different beast, it is complex, it has many fine-points to master. I'd say programming in Go and using QT could be a good choice, if you're considering memory safety above all things.

Buttons840 8y ago

Both QT and GTK have more restrictive licensing, which is fair on its own, but when comparing to Electron you have to consider it a disadvantage.

warkdarrior 8y ago
Qt is licenseable under LGPLv3, Electron under the MIT license. There is practically little difference between the two types of licenses.