While this does read a bit like an ad I find the points to be valid. I also think interface quality can be achieved to be better with Qt Quick than with HTML.
Unfortunately there is a somewhat higher entry barrier, but that shouldn't be a problem for a company this large.
I am glad one company didn't follow the hype of putting web technology everywhere (though the cost of doing so will probably drop).
- Maintainability: Who will maintain a Qt application once it's deployed? How fast can a Qt application become modified?
- Cost for/of developers/development: How easy is it to find good Qt frontend developers/maintainers?
- System upgrades: How will HAM upgrade its appliances?
I assume he's talking about HAM as BSH (Bosch and Siemens Home Appliances). They're currently heavily researching IoT for their appliances. Looking at certain planned features, I guess their appliances will soon be equipped with more powerful embedded systems anyway...
Moving on from the same tired argument that pops up in every thread concerning this topic... if the Qt crowd really cares about this (be it memory usage, etc), you'd think they'd do more to say, make React Native just compile down to Qt.
There's even project(s, or at least one) out there that seem to have had this idea (https://github.com/status-im/react-native-desktop), but few people working on them. I would be 100% unsurprised to see no Electron people doing this, so if you really want to see an alternative, and are looking for cool open source projects to devote time to, maybe something worth considering. It's not an easy feat at all - this thread alone (https://github.com/status-im/ideas/issues/34) kind of explains why.
In my opinion, this is unlikely to ever take off in any serious form, and Qt will continue to generally be the "it exists but nobody really considers it unless Electron is 100% out of the question" option. There's simply too much momentum in terms of new UI components/capabilities/what-have-you that the browser runtime brings to the table that Qt (be it SDK or community built components) cannot match.
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.
>> 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.
Unfortunately, that is usually understood as what is easier for the front-end engineer who only knows js/html/css and doesn't want to learn other tech.
How about the user experience?
As someone said "make it harder for the database, easier for the user".
As a user I prefer products which are joy to use, not which required minimum development effort. Also, I do not normaly use the same product on different platforms.
Like in everything, the more precisely you define your software, the faster it will run, but it will have a higher development cost.
So either pay in programming hour, or in hardware. Often you just do something in html, make some compromise because programming hours are much more expensive than hardware, and hack you way through it.
I just wish wasm will even things out, because at the end of the day, Qt is also another hack to make some interface code work cross platform. Qt might be fast but it's not easy to come by since it's maintained by only one authority.
To absolutely nobody's suprise native code is more efficient and thus allows lower spec hardware. Going for native/QT totally makes sense for a fixed hardware target.
I've read through the comments but no one pointed out the main reason people go with Electron: availability of JavaScript / HTML frameworks for... everything.
Oh, you want a sortable editable grid with custom rendering: here, chose from these 3000 libraries. Oh, you want to do that with Qt? Here's a 7-year old forum question with some vague responses that no longer apply to the latest version and only solve 10% of the requirements. Good luck with that!
I can see a professional company with a large development team (and custom solutions / framework) going with Qt. But for a casual developer (or even a startup) there's no way they'd tie themselves to that boulder.
Don't get me wrong, I love C++ and I hate how Electron craps all over my machine resources but when it comes to ease of development, bootstrap, and cost of iterations they're not even in the same ballpark. I wish ReactNative became an actual thing (with proper mac / win32 bindings, and lots of community support for frameworks / libraries), but alas, we're not there yet.
I've been a full-stack web developer for many years but the last two years I've switched to C++ & Qt development and god is it a pleasure to work with. I only work with Qt Widgets, but I've always wanted to fiddle with QML/QtQuick, although I find the official tutorials lacking.
Any good resources to start working with QML/QtQuick?
It's easy as pie, start with qmlscene and a QML Rect, add some MouseArea and change the rect's color when you click, later follow some QML / C++ binding tutorials.
Some best practices: Still do your nontrivial models and other application logic in C++, don't try to solve every UI state problems with states and transitions - they are overkill for simple situations and underpowered when it gets really difficult. Also you'll learn to, and how to, avoid imperative code in JS over time.
Do use the QML profiler to investigate performance.
Good luck getting any serious technical support with Qt. At least with HTML5 there's a huge amount of users and technical resources. I was never able to get answers to any technical questions that weren't trivial.
You're being downvoted by people who... actually think you should pay Qt for support, rather than enjoy the mountain of information that HTML5/Electron/etc has with a simple Google search.
Even setting aside the argument that, sure, it'd be nice if people paid one another for good work... that's just a hellaciously slow turnaround time. The greater mindshare in the web ecosystem makes dodging a bunch of issues much easier.
This article purely concentrates on mobile - keep that in mind. There is no debate the native is better than web apps - but now we have React Native so... I am not sure what the point is here.
from what I understand it talks about embedded devices (a screen on a fridge or in an airplane). It doesn't say which one is better - it makes an argument based on cost.
Apart from requiring everything but the blood type to read the whitepaper, the whitepaper itself is trash. Self-aggrandizing and condescending even if there are grains of truth here and there.
You mean if they don't comply with the GPL3.0 portion of their licensing [1].
It's pretty disingenuous to say that complying with the GPL is more expensive and restrictive. Purchasing a comparable closed source software suite, or developing it in house, might be less feature complete and more expensive. It's "restrictive" in the sense you need to comply with the GPL which probably gives much more freedom than most closed source licensing terms [2].
Regarding deployment, you'll need an HTML engine adapted for your embedded platform. That is actually not trivial. Have you done it, or are you just extrapolating from desktop applications? Not a rhethorical question, there may be some Chromium embedded thing...
> Ideally we would have UI framework that can target both web and native.
What is ideal about that?
Ideally we would have a vehicle that can target both trips to the local shop and a vacation to Morocco. What? I like having a separate bicycle and airplane.
However, even with styling, you cannot deform the widgets and layouts entirely. Which is a good thing in my book, but appears to hurt designers' feelings.
[+] [-] solarkraft|8 years ago|reply
While this does read a bit like an ad I find the points to be valid. I also think interface quality can be achieved to be better with Qt Quick than with HTML. Unfortunately there is a somewhat higher entry barrier, but that shouldn't be a problem for a company this large.
I am glad one company didn't follow the hype of putting web technology everywhere (though the cost of doing so will probably drop).
[+] [-] donjoe|8 years ago|reply
- Maintainability: Who will maintain a Qt application once it's deployed? How fast can a Qt application become modified?
- Cost for/of developers/development: How easy is it to find good Qt frontend developers/maintainers?
- System upgrades: How will HAM upgrade its appliances?
I assume he's talking about HAM as BSH (Bosch and Siemens Home Appliances). They're currently heavily researching IoT for their appliances. Looking at certain planned features, I guess their appliances will soon be equipped with more powerful embedded systems anyway...
[+] [-] Klonoar|8 years ago|reply
There's even project(s, or at least one) out there that seem to have had this idea (https://github.com/status-im/react-native-desktop), but few people working on them. I would be 100% unsurprised to see no Electron people doing this, so if you really want to see an alternative, and are looking for cool open source projects to devote time to, maybe something worth considering. It's not an easy feat at all - this thread alone (https://github.com/status-im/ideas/issues/34) kind of explains why.
In my opinion, this is unlikely to ever take off in any serious form, and Qt will continue to generally be the "it exists but nobody really considers it unless Electron is 100% out of the question" option. There's simply too much momentum in terms of new UI components/capabilities/what-have-you that the browser runtime brings to the table that Qt (be it SDK or community built components) cannot match.
[+] [-] kbart|8 years ago|reply
[+] [-] w0utert|8 years ago|reply
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.
[+] [-] tjoff|8 years ago|reply
Not sure I agree that QT is harder to develop and maintain, it depends on what you are used to.
[+] [-] lnsru|8 years ago|reply
[+] [-] asterius|8 years ago|reply
[+] [-] ktpsns|8 years ago|reply
[+] [-] qwerty456127|8 years ago|reply
[+] [-] zerr|8 years ago|reply
[+] [-] rimliu|8 years ago|reply
[+] [-] jokoon|8 years ago|reply
So either pay in programming hour, or in hardware. Often you just do something in html, make some compromise because programming hours are much more expensive than hardware, and hack you way through it.
I just wish wasm will even things out, because at the end of the day, Qt is also another hack to make some interface code work cross platform. Qt might be fast but it's not easy to come by since it's maintained by only one authority.
[+] [-] gerdusvz|8 years ago|reply
To absolutely nobody's suprise native code is more efficient and thus allows lower spec hardware. Going for native/QT totally makes sense for a fixed hardware target.
[+] [-] gigel82|8 years ago|reply
I can see a professional company with a large development team (and custom solutions / framework) going with Qt. But for a casual developer (or even a startup) there's no way they'd tie themselves to that boulder.
Don't get me wrong, I love C++ and I hate how Electron craps all over my machine resources but when it comes to ease of development, bootstrap, and cost of iterations they're not even in the same ballpark. I wish ReactNative became an actual thing (with proper mac / win32 bindings, and lots of community support for frameworks / libraries), but alas, we're not there yet.
[+] [-] omegote|8 years ago|reply
Any good resources to start working with QML/QtQuick?
[+] [-] ahartmetz|8 years ago|reply
Some best practices: Still do your nontrivial models and other application logic in C++, don't try to solve every UI state problems with states and transitions - they are overkill for simple situations and underpowered when it gets really difficult. Also you'll learn to, and how to, avoid imperative code in JS over time.
Do use the QML profiler to investigate performance.
[+] [-] akandiah|8 years ago|reply
[+] [-] mjburgess|8 years ago|reply
Who's voting?
[+] [-] Raed667|8 years ago|reply
[+] [-] agborkowski86|8 years ago|reply
[+] [-] TeeWEE|8 years ago|reply
[+] [-] IshKebab|8 years ago|reply
[+] [-] TwoBit|8 years ago|reply
[+] [-] Klonoar|8 years ago|reply
Even setting aside the argument that, sure, it'd be nice if people paid one another for good work... that's just a hellaciously slow turnaround time. The greater mindshare in the web ecosystem makes dodging a bunch of issues much easier.
[+] [-] bb88|8 years ago|reply
https://www.qt.io/
I would expect that they would know everything about qt.
[+] [-] asterius|8 years ago|reply
[+] [-] _pdp_|8 years ago|reply
[+] [-] mxschumacher|8 years ago|reply
[+] [-] dmitriid|8 years ago|reply
[+] [-] kabes|8 years ago|reply
[+] [-] abetusk|8 years ago|reply
It's pretty disingenuous to say that complying with the GPL is more expensive and restrictive. Purchasing a comparable closed source software suite, or developing it in house, might be less feature complete and more expensive. It's "restrictive" in the sense you need to comply with the GPL which probably gives much more freedom than most closed source licensing terms [2].
[1] https://en.wikipedia.org/wiki/Qt_(software)#Licensing
[2] http://www.binpress.com/page/licensing
[+] [-] bb88|8 years ago|reply
[+] [-] Tempest1981|8 years ago|reply
[+] [-] singularity2001|8 years ago|reply
[+] [-] ahartmetz|8 years ago|reply
[+] [-] krzat|8 years ago|reply
Or maybe some kind of next gen HTML that is targeted for maximum performance (like webassembly is to javascript).
[+] [-] dotancohen|8 years ago|reply
What is ideal about that?
Ideally we would have a vehicle that can target both trips to the local shop and a vacation to Morocco. What? I like having a separate bicycle and airplane.
[+] [-] noway421|8 years ago|reply
[+] [-] jlebrech|8 years ago|reply
[+] [-] majewsky|8 years ago|reply
However, even with styling, you cannot deform the widgets and layouts entirely. Which is a good thing in my book, but appears to hurt designers' feelings.