7 ms·

Back 5+ years ago Qt was my go-to framework for cross platform GUIs. You would get the kitchen sink, but the abstractions provided were quite sane. Signals and

by emcq 10y ago

Back 5+ years ago Qt was my go-to framework for cross platform GUIs. You would get the kitchen sink, but the abstractions provided were quite sane. Signals and slots, nice OpenGL and painting libraries, reasonable asthetic and layout options with snappy performance. A while ago I entered a hackathon visualization challenge using Qt painter for rendering. I expected C++ and Qt would slow me down but the rendering speed and expansive drawing primitives were valuable! They greatly reduced my iteration time and increased fun. Today I never create new frontend projects with Qt. I may use Qt creator with cmake for backend components, but the frontend is HTML and JavaScript with libraries like React, Three.js, D3, and bootstrap. The experience is still cross platform, but also one step away from launching as an internal portal. Distribution this way is much easier, but the tools are so flexible you need more diligence to keep the code maintainable over larger teams. I struggle to see where you would prefer Qt for frontend code if you don't need a native app.

joezydeco 10y ago
There are still a lot of us embedded developers that can't or won't implement a browser/JS engine on our target systems. We're becoming more rare these days (especially in the eyes of the Qt developers), but we still exist.
throwaway2016a 10y ago
Well, if you do need to distribute a desktop app, the frameworks that wrap web renderers like Electron can be quite heavy. Your distribution size would almost certainly be smaller with QT. With that said, I got into a debate a while back on HN that web technology is more expressive and miles ahead of desktop frameworks and I got buried for it. What would be nice is if someone ported ReactNative to compile to QT.
problems 10y ago
> I struggle to see where you would prefer Qt for frontend code if you don't need a native app. How about actual native UIs instead of ugly, non-intuitive, slow and massive Electron apps? I say this being a dev who works with both Qt and Electron on a daily basis. Electron has its place - but its place isn't good desktop and mobile apps. Qt is much better suited there. Electron is only well suited if your team is extremely familiar with web dev but nothing else and you have no ability to hire a good desktop team or you need to interact with a web-only frontend library. Just about everything in Qt is preferable - native look and feel, proper layouts, high performance rendering, small distribution size. I struggle to think of any way in which Electron is better except for perhaps library support these days.
- sho_hn 10y ago
  > Electron has its place Yeah, and it's called Hacker News - beyond that no one really cares, and uses Qt. This might sound like a troll, but the bubble effect on HN really is that strong. The community sometimes has a strong tunnel vision and doesn't realize how it's constrained by what's on the HN front page.
  - mumphster 10y ago
    Except for the millions of people using apps such as Slack or Discord or people using the new Keybase desktop offerings, or people using Atom, or VSCode. Electron (sadly imo) is being used in plenty of newly developed cross platform applications, a lot having users that have no clue what hackernews is.
    - sho_hn 10y ago
      Is Electron newsworthy? Sure. At the same time there's vastly more paid Qt devs than Electron devs at this time, and more apps by orders of magnitude, including many with millions of users, and big new ones every week. Along with many application domains Electron isn't even an option in. But you wouldn't know it from HN coverage.
    - deleted 10y ago
      [deleted]
    - problems 10y ago
      None of these apps feel quite right though. Even Atom still doesn't do DPI scaling properly. VSCode does, but opening 2 panes sometimes causes it to break. Sample problem (left pane blurry, right pane sharp - view at 1:1 scale on ~100dpi screen to notice it easiest, but it's quite visible to me with scaling even): https://i.imgur.com/Ju0UK2K.png https://i.imgur.com/Ju0UK2K.png
      - zer0t3ch 10y ago
        I've never had any issue with Discord feeling "not quite right".
pjmlp 10y ago
> I struggle to see where you would prefer Qt for frontend code if you don't need a native app. Specially on mobile. their decision to go with QML for mobile OS support, requiring devs to replicate native widgets, means it is a bigger effort to create multiple QML frontends, than it is to follow a MVVM architecture with as much code as possible in C++, while using native support directly, even if in different languages. Also for those targeting mobile OSes, Xamarin has a much support for the respective OS APIs than Qt, that usually requires the extra effort of manually wrapping many of them. As someone that prefers working on native apps to web ones, I kind don't understand their current roadmap, it appears that they are trying to spread between C++ and JavaScript devs in an attempt not to lose mind share.
- sho_hn 10y ago
  It sounds like https://blog.qt.io/blog/2017/02/06/native-look-feel/ https://blog.qt.io/blog/2017/02/06/native-look-feel/ is trying to address your needs.
  - pjmlp 10y ago
    I tried Qt 5.4 and wasn't happy with the result, ended up settling on a mix of Java, C++/CX and C++ for my mobile side projects. From your link it seems that by Qt 6, they might eventually get something that I already have with such setup today. Also I am planning to switch to Xamarin in future side projects.
- deleted 10y ago
  [deleted]
- n00b101 10y ago
  > I kind don't understand their current roadmap, it appears that they are trying to spread between C++ and JavaScript devs in an attempt not to lose mind share. And maybe losing both camps in the process.
- discreteevent 10y ago
  Why are electron or web apps acceptable but Qt with e.g. a material look not acceptable? I just don't get it. The Qt app will be faster, better looking, better integrated with OS apis much saner to develop (QML is really productive and what react would be if it could have is own DSL).
devwastaken 10y ago
Take Winamp vs Spotify for example. Spotify, even with much less features and a pretty simple interface, lags out every time I load it, for 10 seconds or so, and overall isn't very responsive. Thats on a pretty good system. Winamp does everything instantly. I see things like Electron as a form of debt in technology. You can build things cross-platform really quickly, but you're taking out a lot more debt to do it, the problem is that the app can become so popular that they never pay it back.
- modzu 10y ago
  you don't know that the difference is due to the two platforms though its certainly possible to make slow native apps and fast electron apps. whether yours is fast or slow, and whether you can build it quickly only depends on your skillset cf: winamp vs windows media player
  - devwastaken 10y ago
    >you don't know that the difference is due to the two platforms though When loading the UI takes 4 seconds. Pretty sure thats a problem, and its impossible to actually /prove/ its 'just their code', there is supporting evidence due to the technologies they chose and the nature of why they're used. >whether yours is fast or slow, and whether you can build it quickly only depends on your skillset The software you are using matters a lot, too. You can't just throw any tech at a problem and it'l solve it. Your skillset is dependent upon what you know, and how you know to use it, but is limited based upon what is available and readily possible. Chromium and node.js have overhead, and are very good at some things, and other things they are much worse for than a native app. Add ontop the crazy environment of JS and its inneficiencies for performance in comparison, and you get a big pile of mud. Useful, if you need to create something quickly, like many startups.
    - modzu 10y ago
      for sure, its uncontroversial that there is overhead with JS and that when top performance is required this overhead can be too costly. but is this the reason for a desktop music player to be lagging on a "pretty good system"? no way -- there's no real excuse for that. its just a shitty app. perhaps electron gives teams the impression they can just type npm in front of some stuff to turn their website into a performant desktop app -- not quite so ;)
jeena 10y ago
In the embeded world, we're using it in cars.

by emcq 10y ago

joezydeco 10y ago

There are still a lot of us embedded developers that can't or won't implement a browser/JS engine on our target systems. We're becoming more rare these days (especially in the eyes of the Qt developers), but we still exist.

throwaway2016a 10y ago

Well, if you do need to distribute a desktop app, the frameworks that wrap web renderers like Electron can be quite heavy. Your distribution size would almost certainly be smaller with QT. With that said, I got into a debate a while back on HN that web technology is more expressive and miles ahead of desktop frameworks and I got buried for it. What would be nice is if someone ported ReactNative to compile to QT.

problems 10y ago

> I struggle to see where you would prefer Qt for frontend code if you don't need a native app. How about actual native UIs instead of ugly, non-intuitive, slow and massive Electron apps? I say this being a dev who works with both Qt and Electron on a daily basis. Electron has its place - but its place isn't good desktop and mobile apps. Qt is much better suited there. Electron is only well suited if your team is extremely familiar with web dev but nothing else and you have no ability to hire a good desktop team or you need to interact with a web-only frontend library. Just about everything in Qt is preferable - native look and feel, proper layouts, high performance rendering, small distribution size. I struggle to think of any way in which Electron is better except for perhaps library support these days.

sho_hn 10y ago
> Electron has its place Yeah, and it's called Hacker News - beyond that no one really cares, and uses Qt. This might sound like a troll, but the bubble effect on HN really is that strong. The community sometimes has a strong tunnel vision and doesn't realize how it's constrained by what's on the HN front page.
- mumphster 10y ago
  Except for the millions of people using apps such as Slack or Discord or people using the new Keybase desktop offerings, or people using Atom, or VSCode. Electron (sadly imo) is being used in plenty of newly developed cross platform applications, a lot having users that have no clue what hackernews is.
  - sho_hn 10y ago
    Is Electron newsworthy? Sure. At the same time there's vastly more paid Qt devs than Electron devs at this time, and more apps by orders of magnitude, including many with millions of users, and big new ones every week. Along with many application domains Electron isn't even an option in. But you wouldn't know it from HN coverage.
  - deleted 10y ago
    [deleted]
  - problems 10y ago
    None of these apps feel quite right though. Even Atom still doesn't do DPI scaling properly. VSCode does, but opening 2 panes sometimes causes it to break. Sample problem (left pane blurry, right pane sharp - view at 1:1 scale on ~100dpi screen to notice it easiest, but it's quite visible to me with scaling even): https://i.imgur.com/Ju0UK2K.png https://i.imgur.com/Ju0UK2K.png
    - zer0t3ch 10y ago
      I've never had any issue with Discord feeling "not quite right".

pjmlp 10y ago

> I struggle to see where you would prefer Qt for frontend code if you don't need a native app. Specially on mobile. their decision to go with QML for mobile OS support, requiring devs to replicate native widgets, means it is a bigger effort to create multiple QML frontends, than it is to follow a MVVM architecture with as much code as possible in C++, while using native support directly, even if in different languages. Also for those targeting mobile OSes, Xamarin has a much support for the respective OS APIs than Qt, that usually requires the extra effort of manually wrapping many of them. As someone that prefers working on native apps to web ones, I kind don't understand their current roadmap, it appears that they are trying to spread between C++ and JavaScript devs in an attempt not to lose mind share.

sho_hn 10y ago
It sounds like https://blog.qt.io/blog/2017/02/06/native-look-feel/ https://blog.qt.io/blog/2017/02/06/native-look-feel/ is trying to address your needs.
- pjmlp 10y ago
  I tried Qt 5.4 and wasn't happy with the result, ended up settling on a mix of Java, C++/CX and C++ for my mobile side projects. From your link it seems that by Qt 6, they might eventually get something that I already have with such setup today. Also I am planning to switch to Xamarin in future side projects.
deleted 10y ago
[deleted]
n00b101 10y ago
> I kind don't understand their current roadmap, it appears that they are trying to spread between C++ and JavaScript devs in an attempt not to lose mind share. And maybe losing both camps in the process.
discreteevent 10y ago
Why are electron or web apps acceptable but Qt with e.g. a material look not acceptable? I just don't get it. The Qt app will be faster, better looking, better integrated with OS apis much saner to develop (QML is really productive and what react would be if it could have is own DSL).

devwastaken 10y ago

Take Winamp vs Spotify for example. Spotify, even with much less features and a pretty simple interface, lags out every time I load it, for 10 seconds or so, and overall isn't very responsive. Thats on a pretty good system. Winamp does everything instantly. I see things like Electron as a form of debt in technology. You can build things cross-platform really quickly, but you're taking out a lot more debt to do it, the problem is that the app can become so popular that they never pay it back.

modzu 10y ago
you don't know that the difference is due to the two platforms though its certainly possible to make slow native apps and fast electron apps. whether yours is fast or slow, and whether you can build it quickly only depends on your skillset cf: winamp vs windows media player
- devwastaken 10y ago
  >you don't know that the difference is due to the two platforms though When loading the UI takes 4 seconds. Pretty sure thats a problem, and its impossible to actually /prove/ its 'just their code', there is supporting evidence due to the technologies they chose and the nature of why they're used. >whether yours is fast or slow, and whether you can build it quickly only depends on your skillset The software you are using matters a lot, too. You can't just throw any tech at a problem and it'l solve it. Your skillset is dependent upon what you know, and how you know to use it, but is limited based upon what is available and readily possible. Chromium and node.js have overhead, and are very good at some things, and other things they are much worse for than a native app. Add ontop the crazy environment of JS and its inneficiencies for performance in comparison, and you get a big pile of mud. Useful, if you need to create something quickly, like many startups.
  - modzu 10y ago
    for sure, its uncontroversial that there is overhead with JS and that when top performance is required this overhead can be too costly. but is this the reason for a desktop music player to be lagging on a "pretty good system"? no way -- there's no real excuse for that. its just a shitty app. perhaps electron gives teams the impression they can just type npm in front of some stuff to turn their website into a performant desktop app -- not quite so ;)

jeena 10y ago

In the embeded world, we're using it in cars.