There's not many votes, it's just that the front page algorithm likes to freshen up its listings once in a while. While I'm not really sure of the specifics, I know for a fact that posts with low votes and low engagement make it onto the front page with seemingly no reason (source: this happened to my first blog post, but eventually got a number of votes and comments)
Edit 2: scrolling through, I found this gem of a quote:
"Even with static linking, Web executables will
be five times bigger than Qt executables. Hence, Web
applications will take five times longer to load than Qt
applications."
That's completely false. Program load time is not directly correlated with size of the executable in a 1:1 ratio. The correct answer is "it depends."
Edit 3: on page 10, they don't acknowledge that HTML/CSS/JS is easier to learn than C++, and also they don't acknowledge HW acceleration for animations in CSS (thus smooth animations).
Well there have been some other articles that talk about using Qt, python's built in browser or Python+GTK over electron/HTML5 apps. There are a lot of people out here sick of things like Slack/Discord/Atom which each have the entire Electron framework that weigh in at 80 ~ 150MB.
I'd be all for using GTK or QT if there were just better well supported bindings, with good documentation and examples, for languages like Python, Ruby, Rust, Scala, etc. I know some people love C++ and the newer C++11/14 seem to have cleaned up a lot of cruft (although GTK is in C unless you use Gtkmm), but I think the barrier to entry would be easier if their other language bindings had better docs.
All that being said, this does feel very ad-like. Qt is commercial. I wonder if they're trying to push this stuff and make it look organic.
I've been wondering for a while now why Electron isn't separate from the application bundle itself. Having an app simply declare its supported version of Electron and downloading one version for all apps to use would make a lot more sense in terms of disk space.
I guess disk space is considered one of those "commodities" nowadays. I disagree (typing this from a 64GB SSD Mac) and HATE Electron apps for this reason. (Xcode, too, because it eats up disk space, but that's talk for another day)
I used to call Qt ".Net for people who can't have anything better".
When you code in Qt you rarely, if ever, are exposed to the hairy parts of C/C++. If anything, it feels like coding in C#. Nesides UI there are a gazillion helper and utility classes for everything from networking to threading to string handling. And with QML there's even less C++ :)
I actually just migrated a small Rust application to C++ with Qt because I have to use DBus and Qt has a very nice DBus library, which Rust has not. (In general, DBus hates runtime environments that don't have an event loop.)
It's pretty hard to have asynchronous calls without an event loop ;)
Using DBus synchronously is, strictly speaking, wrong unless you can PROVE that there can be no deadlocks; talking to the DBus daemon itself synchronously is generally safe though. Unfortunately QtDBus encourages synchronous calls. Maybe you remember desktop hangs in early KDE 4 related to global shortcuts - that was me not knowing that rule at the time.
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.
Wanting to learn other tech is mostly a question of how much effort will you have to invest in it before you get reasonably fluent. I don't really know about Qt but if learning it is a matter of a weekend (provided you already know a compatible programming language and have experience in UI design) then I don't think it's a problem. But I doubt it is this easy with Qt. I have had an idea of developing a KDE5 desktop plasmoid widget so I have taken a look at other plasmoids QML source codes and they didn't look easy to me, it felt like HTML is more intuitive (although I am not a web developer actually).
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.
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.
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.
"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.
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].
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:
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.
> writing clean C++ is a bit harder than creating HTML page
False analogy. The counterpart of HTML in the Qt world is QML, not C++. C++ is the counterpart of JS (or whatever backend language the web application uses).
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.
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.
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.
* 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.
>> 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.
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.
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.
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.
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...
That's about right. Yet, I think BSH (HAM) will continue to maintain their GUIs on a daily basis since they will want to keep older devices up to date with their IoT ecosystem, too. In the past, once a UI for appliances was written, it stayed the same until the appliance broke down. In a world of IoT, code will become updated on a regular basis. That's why I was questioning the initial development costs vs. maintaining an application's GUI until its EOL.
I wonder Espruino was not mentioned so far. Their approach could speed up dev time by a lot.
I don't have concrete data on this, but can't imagine updating a Qt app to be very difficult. The Qt folks usually tailor well to clients and are pretty supportive.
And licensing. Qt is LGPL or commercial. HTML is (in practice) more liberally licensed.
(Edit: not GPL, but LGPL. Which is almost as bad for embedded systems as GPL itself is. How do you let the user relink Qt or replace Qt with their own version, in the field? Nightmare. Just pay up. Qt LGPL is (or was) fine for desktop apps pre app stores. Now, not so much.)
GPLv3 section 6 requires you to to provide instructions that allow the user to replace GPL-licensed software on a device, unless there is no upgrade functionality at all (so if you have an upgrade mechanism, you must open it to the user, if you burn the software to unchangeable ROM you don't have to replace that with writeable memory just to enable user replacement)
LPGLv3 section 4 modifies this for LGPL-licensed software, requiring you to allow replacement of LGPL-licensed parts of software under the same mechanisms.
This is commonly known as the "anti-tivoisation provisions".
There is an API for creating one yourself, I did, not hard at all. Now it might not have a dictionary and other fancy features but it was adapted to our needs and it didn't take long at all to implement.
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.
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.
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.
For all of the hardware, yes. For the incremental cost of better hardware versus development cost, it makes sense to spend more on development to save hardware between 10k and 100k units.
I have worked on embedded projects for extremely expensive hardware selling in moderate numbers with underpowered SOCs that could not produce smooth UIs. Bad hardware decisions.
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].
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.
> 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.
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.
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...
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.
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.
87 comments
[ 2.0 ms ] story [ 168 ms ] threadWho's voting?
Edit: anyone who wants to read the (largely uninformative and unsubstantial) white paper/advert, here's a non-infowalled (is that a word?) link: http://content.cdntwrk.com/files/aT05NDQwMzEmdj0xJmlzc3VlTmF...
Edit 2: scrolling through, I found this gem of a quote: "Even with static linking, Web executables will be five times bigger than Qt executables. Hence, Web applications will take five times longer to load than Qt applications."
That's completely false. Program load time is not directly correlated with size of the executable in a 1:1 ratio. The correct answer is "it depends."
Edit 3: on page 10, they don't acknowledge that HTML/CSS/JS is easier to learn than C++, and also they don't acknowledge HW acceleration for animations in CSS (thus smooth animations).
I'd be all for using GTK or QT if there were just better well supported bindings, with good documentation and examples, for languages like Python, Ruby, Rust, Scala, etc. I know some people love C++ and the newer C++11/14 seem to have cleaned up a lot of cruft (although GTK is in C unless you use Gtkmm), but I think the barrier to entry would be easier if their other language bindings had better docs.
All that being said, this does feel very ad-like. Qt is commercial. I wonder if they're trying to push this stuff and make it look organic.
I guess disk space is considered one of those "commodities" nowadays. I disagree (typing this from a 64GB SSD Mac) and HATE Electron apps for this reason. (Xcode, too, because it eats up disk space, but that's talk for another day)
When you code in Qt you rarely, if ever, are exposed to the hairy parts of C/C++. If anything, it feels like coding in C#. Nesides UI there are a gazillion helper and utility classes for everything from networking to threading to string handling. And with QML there's even less C++ :)
Using DBus synchronously is, strictly speaking, wrong unless you can PROVE that there can be no deadlocks; talking to the DBus daemon itself synchronously is generally safe though. Unfortunately QtDBus encourages synchronous calls. Maybe you remember desktop hangs in early KDE 4 related to global shortcuts - that was me not knowing that rule at the time.
Also, QML has bindings for a lot of languages if you're not comfortable with either javascript or C++ for your backend.
Not sure I agree that QT is harder to develop and maintain, it depends on what you are used to.
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.
Javascript isn't exactly known for maintainability and clean code either. I'd much prefer C++ for proper applications.
0. https://ingenico.us/smart-terminals/telium-tetra/payment-ter...
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.
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
False analogy. The counterpart of HTML in the Qt world is QML, not C++. C++ is the counterpart of JS (or whatever backend language the web application uses).
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
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.
* 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.
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.
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.
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.
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...
I wonder Espruino was not mentioned so far. Their approach could speed up dev time by a lot.
(Edit: not GPL, but LGPL. Which is almost as bad for embedded systems as GPL itself is. How do you let the user relink Qt or replace Qt with their own version, in the field? Nightmare. Just pay up. Qt LGPL is (or was) fine for desktop apps pre app stores. Now, not so much.)
Where in the GPL or LGPL is this stated?
LPGLv3 section 4 modifies this for LGPL-licensed software, requiring you to allow replacement of LGPL-licensed parts of software under the same mechanisms.
This is commonly known as the "anti-tivoisation provisions".
And if you need on-screen keyboard, there’s no LGPL option available. You have to pay them significant amount of money, and also per-device fee.
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.
https://www.qt.io/
I would expect that they would know everything about qt.
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.
I have worked on embedded projects for extremely expensive hardware selling in moderate numbers with underpowered SOCs that could not produce smooth UIs. Bad hardware decisions.
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
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.
Or maybe some kind of next gen HTML that is targeted for maximum performance (like webassembly is to javascript).
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.
Also I would prefer my flying car with autopilot over airplane.
Alternatively, there would be smart browser engine which can strip itself from unused modules during deployment.
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.
Any good resources to start working with QML/QtQuick?
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.
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.