5 ms·

I've done both and the real answer is "it depends". If performance is all that matters, the yes, it's Qt hands down. But Qt is also significantly harder to deve

by kbart 9y ago

I've done both and the real answer is "it depends". If performance is all that matters, the yes, it's Qt hands down. But Qt is also significantly harder to develop and maintain, especially if you want optimized application for minimal hardware.

asterius 9y ago
Maybe this was the case with Qt4, but Qt5 (that is, QML) is a dream.
- IshKebab 9y ago
  I disagree. QML is a nice idea but incomplete: * There still isn't a way to have any text in your custom widgets (e.g. labels on a graph) - last time I checked anyway. * The built in text editor widgets have an anorexic API. I wrote a serial port monitoring program and to remove the first line of text from the output window I had to record the lengths of all the lines in a JavaScript array and then remove that number of characters. And it was very slow. And selection was buggy. * The ID scope rules are weird. Honestly I never fully worked them out. It seems like every ID is accessible from anywhere - even child components can directly access IDs in their parents. You can imagine the kind of spaghetti code that leads to.
tjoff 9y ago
If you want an optimized application for minimal hardware then surely HTML isn't an alternative anyway? Not sure I agree that QT is harder to develop and maintain, it depends on what you are used to.
- kbart 9y ago
  "If you want an optimized application for minimal hardware then surely HTML isn't an alternative anyway?" That was the question on linked article. These days HTML becomes viable even on low-end hardware, it's even standard on some appliances (i.e. home routers) and this question is very common. "Not sure I agree that QT is harder to develop and maintain, it depends on what you are used to." General census is that writing clean C++ (QML was still lacking the last time I used Qt, though it might have changed since then) is a bit harder than creating HTML page.
  - tjoff 9y ago
    I think you are confused, home routers don't even render HTML but let the insanely powerful client do the actual work. Javascript isn't exactly known for maintainability and clean code either. I'd much prefer C++ for proper applications.
    - kbart 9y ago
      Yes, router was not the best example, it was to illustrate that writing HTML interface is already common, not necessarily GUI. But there are plenty of devices that use HTML for GUI as well, some new PoS terminals comes to mind[0]. 0. https://ingenico.us/smart-terminals/telium-tetra/payment-terminals/lane-series/lane-5000.html https://ingenico.us/smart-terminals/telium-tetra/payment-ter...
      - ahartmetz 9y ago
        I did not find any video on YouTube showing it reacting to user input, go figure... Its CPU is underpowered for any UI that isn't highly optimized native code, and this looks like it's struggling to serve up the few pixels of its relatively low resolution display: https://youtu.be/hI-gYmwL9hQ?t=1m19s https://youtu.be/hI-gYmwL9hQ?t=1m19s However they had to use some kind of software rendering due to lack of GPU, and QML with software rendering isn't that fast either.
        kbart 9y ago
        I have played a little with it live. It uses mixed GUI of legacy graphic sub-system and HTML5. And yes, on HTML5 "apps" it's noticeably slow..
  - tyfon 9y ago
    Anecdotally. When I play youtube videos in my browser I'm getting about 1/3 of the view time before the battery is out compared to using mpv with youtube-dl on my laptop. It's not just about being able to run it at all but run it efficiently. These days anything on the web feels really sluggish and I miss the days when optimisation was a priority. Also for me, I vastly prefer writing C++ code over html and the few times recently where I had to write webpages I used libwt[1] in C++. It's almost like using QT but for html. [1] https://www.webtoolkit.eu/wt https://www.webtoolkit.eu/wt
- Iv 9y ago
  As a C++ developer who finds javascript painful to work with, I know I am orders of magnitude more productive on Qt.
lnsru 9y ago
Qt is really easy to start with. You can have primitive crosscompiled touchscreen application in couple days without prior experience.
- kbart 9y ago
  It might be easy for programmer, but try to explain cross-compilation and hardware specific optimizations for your designer or front-end developer. HTML, on the other hand, is reasonably easy for everyone.
  - beojan 9y ago
    Your designer shouldn't be doing any development. If your front-end developer doesn't understand cross-compilation, they're a web designer, and you need to hire someone else to do the development.
- raverbashing 9y ago
  Yes, but compare that to hours in HTML5 Also consider a QT app is much harder to style and make it look good People with HTML5 experience is much easier to find I'm not against QT, quite the contrary, but it's a technology that has a higher entry barrier and fewer people with experience on it
  - beojan 9y ago
    HTML5 is easier if you already know HTML / CSS / JS. Qt Quick is easier otherwise. If you're developing for the desktop, Qt Widgets is definitely the way to go. No, you can't (easily) style it in your own weird, custom, way. Please don't, I want it to fit in with all the other applications on my desktop.
w0utert 9y ago
>> But Qt is also significantly harder to develop and maintain, especially if you want optimized application for minimal hardware. If by that you mean it's easier to hack together some awful JS+HTML compared to hacking together a Qt application, I agree. If you want to build a maintainable, reliable and efficient solution, I don't think there is that much difference between the two. Qt has bindings to many languages, and even if you are forced to use C++ because of hardware constraints, the fact that the Qt front end API is a million times better (easier, better documented) than whatever JS frontend, offsets the language overhead. I'm not really sure anyone could say React or Bootstrap or whatever is 'easy to use' if you are not familiar with it. Easy to get a button on the screen, maybe, but that hardly makes a user interface.
- sime2009 9y ago
  Just a side note, but if you are building a commercial/serious product then your language options for Qt shrink down to just C++ and Python. Qt doesn't have many mature and maintained bindings to other languages.
  - ahartmetz 9y ago
    This is true for desktop applications. On embedded, even PyQt or PySide could be difficult, depending on the amount of application logic required.
- ahartmetz 9y ago
  I can sort of confirm this. Disclaimer: I work with C++ and Qt and only know some basic HTML and JS. I have worked on a project where we reimplemented an HTML5... application (information omitted to protect possible secrets). We did it in a quarter of the time with IIRC a tenth of the staff from the original, according to those who did the HTML5 version. Line count was also lower. Of course not having to redo high-level design and some lower level services was a massive benefit for us, and HTML5 frameworks weren't as good at the time. Perhaps the most important point is that while they got a skeleton up in reasonable time, things slowed down greatly from there. The HTML5 / JS code was kind of hard to understand due to callback hell, and getting smooth performance took a huge amount of work. In the Qt version, we implemented it following some best practices and performance was great right away.

by kbart 9y ago

asterius 9y ago

Maybe this was the case with Qt4, but Qt5 (that is, QML) is a dream.

IshKebab 9y ago
I disagree. QML is a nice idea but incomplete: * There still isn't a way to have any text in your custom widgets (e.g. labels on a graph) - last time I checked anyway. * The built in text editor widgets have an anorexic API. I wrote a serial port monitoring program and to remove the first line of text from the output window I had to record the lengths of all the lines in a JavaScript array and then remove that number of characters. And it was very slow. And selection was buggy. * The ID scope rules are weird. Honestly I never fully worked them out. It seems like every ID is accessible from anywhere - even child components can directly access IDs in their parents. You can imagine the kind of spaghetti code that leads to.

tjoff 9y ago

If you want an optimized application for minimal hardware then surely HTML isn't an alternative anyway? Not sure I agree that QT is harder to develop and maintain, it depends on what you are used to.

kbart 9y ago
"If you want an optimized application for minimal hardware then surely HTML isn't an alternative anyway?" That was the question on linked article. These days HTML becomes viable even on low-end hardware, it's even standard on some appliances (i.e. home routers) and this question is very common. "Not sure I agree that QT is harder to develop and maintain, it depends on what you are used to." General census is that writing clean C++ (QML was still lacking the last time I used Qt, though it might have changed since then) is a bit harder than creating HTML page.
- tjoff 9y ago
  I think you are confused, home routers don't even render HTML but let the insanely powerful client do the actual work. Javascript isn't exactly known for maintainability and clean code either. I'd much prefer C++ for proper applications.
  - kbart 9y ago
    Yes, router was not the best example, it was to illustrate that writing HTML interface is already common, not necessarily GUI. But there are plenty of devices that use HTML for GUI as well, some new PoS terminals comes to mind[0]. 0. https://ingenico.us/smart-terminals/telium-tetra/payment-terminals/lane-series/lane-5000.html https://ingenico.us/smart-terminals/telium-tetra/payment-ter...
    - ahartmetz 9y ago
      I did not find any video on YouTube showing it reacting to user input, go figure... Its CPU is underpowered for any UI that isn't highly optimized native code, and this looks like it's struggling to serve up the few pixels of its relatively low resolution display: https://youtu.be/hI-gYmwL9hQ?t=1m19s https://youtu.be/hI-gYmwL9hQ?t=1m19s However they had to use some kind of software rendering due to lack of GPU, and QML with software rendering isn't that fast either.
      - kbart 9y ago
        I have played a little with it live. It uses mixed GUI of legacy graphic sub-system and HTML5. And yes, on HTML5 "apps" it's noticeably slow..
- tyfon 9y ago
  Anecdotally. When I play youtube videos in my browser I'm getting about 1/3 of the view time before the battery is out compared to using mpv with youtube-dl on my laptop. It's not just about being able to run it at all but run it efficiently. These days anything on the web feels really sluggish and I miss the days when optimisation was a priority. Also for me, I vastly prefer writing C++ code over html and the few times recently where I had to write webpages I used libwt[1] in C++. It's almost like using QT but for html. [1] https://www.webtoolkit.eu/wt https://www.webtoolkit.eu/wt
Iv 9y ago
As a C++ developer who finds javascript painful to work with, I know I am orders of magnitude more productive on Qt.

lnsru 9y ago

Qt is really easy to start with. You can have primitive crosscompiled touchscreen application in couple days without prior experience.

kbart 9y ago
It might be easy for programmer, but try to explain cross-compilation and hardware specific optimizations for your designer or front-end developer. HTML, on the other hand, is reasonably easy for everyone.
- beojan 9y ago
  Your designer shouldn't be doing any development. If your front-end developer doesn't understand cross-compilation, they're a web designer, and you need to hire someone else to do the development.
raverbashing 9y ago
Yes, but compare that to hours in HTML5 Also consider a QT app is much harder to style and make it look good People with HTML5 experience is much easier to find I'm not against QT, quite the contrary, but it's a technology that has a higher entry barrier and fewer people with experience on it
- beojan 9y ago
  HTML5 is easier if you already know HTML / CSS / JS. Qt Quick is easier otherwise. If you're developing for the desktop, Qt Widgets is definitely the way to go. No, you can't (easily) style it in your own weird, custom, way. Please don't, I want it to fit in with all the other applications on my desktop.

w0utert 9y ago

>> But Qt is also significantly harder to develop and maintain, especially if you want optimized application for minimal hardware. If by that you mean it's easier to hack together some awful JS+HTML compared to hacking together a Qt application, I agree. If you want to build a maintainable, reliable and efficient solution, I don't think there is that much difference between the two. Qt has bindings to many languages, and even if you are forced to use C++ because of hardware constraints, the fact that the Qt front end API is a million times better (easier, better documented) than whatever JS frontend, offsets the language overhead. I'm not really sure anyone could say React or Bootstrap or whatever is 'easy to use' if you are not familiar with it. Easy to get a button on the screen, maybe, but that hardly makes a user interface.

sime2009 9y ago
Just a side note, but if you are building a commercial/serious product then your language options for Qt shrink down to just C++ and Python. Qt doesn't have many mature and maintained bindings to other languages.
- ahartmetz 9y ago
  This is true for desktop applications. On embedded, even PyQt or PySide could be difficult, depending on the amount of application logic required.
ahartmetz 9y ago
I can sort of confirm this. Disclaimer: I work with C++ and Qt and only know some basic HTML and JS. I have worked on a project where we reimplemented an HTML5... application (information omitted to protect possible secrets). We did it in a quarter of the time with IIRC a tenth of the staff from the original, according to those who did the HTML5 version. Line count was also lower. Of course not having to redo high-level design and some lower level services was a massive benefit for us, and HTML5 frameworks weren't as good at the time. Perhaps the most important point is that while they got a skeleton up in reasonable time, things slowed down greatly from there. The HTML5 / JS code was kind of hard to understand due to callback hell, and getting smooth performance took a huge amount of work. In the Qt version, we implemented it following some best practices and performance was great right away.