4 ms·

I've built with Qt and Electron combined for over a dedcade. Electron has entire libraries that are portable cross-OS. It is literally write once, deploy on Ub

I've built with Qt and Electron combined for over a dedcade. Electron has entire libraries that are portable cross-OS. It is literally write once, deploy on Ubuntu, Mac, Win10. I've never had an issue, even using serial ports and USB interfaces. Qt is just a GUI, you will still need to write native hardware interface code. As a bonus, with Electron you also get ALL of the modern frameworks and templates. If you choose Qt you will always feel "behind". EDIT: Based on this thread I need to re-examine Qt. They now have cross-platform USB endpoint classes that are of interest. But I'm not giving up my frameworks.

laurent123456 5y ago
In Qt, isn't it just a matter of finding a cross-platform C++ lib for whatever hardware support you need? Just like you'd look for an npm package for Electron?
- deleted 5y ago
  [deleted]
- SXX 5y ago
  C++ still don't have ecosystem anywhere as easy-to-use compared to npm. There are two package managers with a lot of libraries (Vcpkg and MinGW / MXE), but: * Only very popular libraries actually available. * Sometimes they break on package manager and no one notice for months since test coverage is often limited. * Each extra library might cause tons of little issues and make your build system more and more complex. * Libraries often don't support all OS equally well. * Most of mature C++ projects avoid those libraries and package managers. So much often than with npm you will have to test each library on your own and what worse you might only learn that something fundamentally broken (on specific OS or architecture) inside it much much later. And with C++ it's just harder to do refactoring to replace said library with something else.
slobotron 5y ago
Last time I used Qt, it had classes to abstract hardware. Stuff like QSerialPort worked fine across platforms for my usage. YMMV
Nicksil 5y ago
>But I'm not giving up my frameworks. Why would you dig your heels in if you've found a superior alternative fulfilling all your requirements?
- SavantIdiot 5y ago
  Because I'm a rational human being. If something comes along that is better, I'll jump ship. If Qt native meets my USB needs I'll move to the next barrier: frameworks. If Qt solves that hurdle, why stay with Electron? I was being funny but you took it seriously.
  - Nicksil 5y ago
    I understood your statement as saying you are not giving up Electron if you found Qt fulfills your requirements (USB). That's was I was questioning: Why continue to use Electron if Qt does all the things you need to do. Perhaps I misunderstood; text isn't the best medium to convey tone.
    - SavantIdiot 5y ago
      Yes, sorry. Communication mishap indeed!! I was sort-of implying that now that I learned Qt offers USB support, one of my two reasons for not using Qt was dismantled, as if I was now worried that I made a mistake picking Electron and boy this sure sounds less and less funny as I type it out...

laurent123456 5y ago

In Qt, isn't it just a matter of finding a cross-platform C++ lib for whatever hardware support you need? Just like you'd look for an npm package for Electron?

deleted 5y ago
[deleted]
SXX 5y ago
C++ still don't have ecosystem anywhere as easy-to-use compared to npm. There are two package managers with a lot of libraries (Vcpkg and MinGW / MXE), but: * Only very popular libraries actually available. * Sometimes they break on package manager and no one notice for months since test coverage is often limited. * Each extra library might cause tons of little issues and make your build system more and more complex. * Libraries often don't support all OS equally well. * Most of mature C++ projects avoid those libraries and package managers. So much often than with npm you will have to test each library on your own and what worse you might only learn that something fundamentally broken (on specific OS or architecture) inside it much much later. And with C++ it's just harder to do refactoring to replace said library with something else.

slobotron 5y ago

Last time I used Qt, it had classes to abstract hardware. Stuff like QSerialPort worked fine across platforms for my usage. YMMV

Nicksil 5y ago

>But I'm not giving up my frameworks. Why would you dig your heels in if you've found a superior alternative fulfilling all your requirements?

SavantIdiot 5y ago
Because I'm a rational human being. If something comes along that is better, I'll jump ship. If Qt native meets my USB needs I'll move to the next barrier: frameworks. If Qt solves that hurdle, why stay with Electron? I was being funny but you took it seriously.
- Nicksil 5y ago
  I understood your statement as saying you are not giving up Electron if you found Qt fulfills your requirements (USB). That's was I was questioning: Why continue to use Electron if Qt does all the things you need to do. Perhaps I misunderstood; text isn't the best medium to convey tone.
  - SavantIdiot 5y ago
    Yes, sorry. Communication mishap indeed!! I was sort-of implying that now that I learned Qt offers USB support, one of my two reasons for not using Qt was dismantled, as if I was now worried that I made a mistake picking Electron and boy this sure sounds less and less funny as I type it out...