Qt or HTML5? A Million Dollar Question
embedded-computing.com
embedded-computing.com
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.)
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.
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".
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.
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.
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.
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).
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.
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.
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 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.
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.
Who's voting?
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)
Also, QML has bindings for a lot of languages if you're not comfortable with either javascript or C++ for your backend.
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.
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).
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 would expect that they would know everything about qt.
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].
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.
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.
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.