
Qt or HTML5? A Million Dollar Question - syck
http://www.embedded-computing.com/industrial/qt-or-html5
======
solarkraft
Real link:
[http://content.cdntwrk.com/files/aT05NDQwMzEmdj0xJmlzc3VlTmF...](http://content.cdntwrk.com/files/aT05NDQwMzEmdj0xJmlzc3VlTmFtZT1xdC1vci1odG1sNSZjbWQ9ZCZzaWc9Njk1YTEwYzM3OWE0Y2Q5NDMyZjMxMmZkMGFlMjViMzE%25253D)

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
What I'm missing are some points regarding:

\- 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...

~~~
jacobush
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.)

~~~
mkl
Qt has been LGPL as well for years now.

~~~
jacobush
Ah, yes, true. See my edit though.

------
Klonoar
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](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](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
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.

~~~
w0utert
>> _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
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
This is true for desktop applications. On embedded, even PyQt or PySide could
be difficult, depending on the amount of application logic required.

------
ktpsns
Direkt link to the PDF behind the registration wall:
[http://content.cdntwrk.com/files/aT05NDQwMzEmdj0xJmlzc3VlTmF...](http://content.cdntwrk.com/files/aT05NDQwMzEmdj0xJmlzc3VlTmFtZT1xdC1vci1odG1sNSZjbWQ9ZCZzaWc9Njk1YTEwYzM3OWE0Y2Q5NDMyZjMxMmZkMGFlMjViMzE%25253D)

------
qwerty456127
As for me and for many businesses the most important question is what is
easier to engineer, support and run on different platforms.

~~~
zerr
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.

~~~
qwerty456127
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).

~~~
ahartmetz
Well, HTML does not contain any APIs for creating plasmoids... So of course
you have never seen that particular complexity in HTML.

------
jokoon
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.

------
gerdusvz
direct link via view source:
[http://content.cdntwrk.com/files/aT05NDQwMzEmdj0xJmlzc3VlTmF...](http://content.cdntwrk.com/files/aT05NDQwMzEmdj0xJmlzc3VlTmFtZT1xdC1vci1odG1sNSZjbWQ9ZCZzaWc9Njk1YTEwYzM3OWE0Y2Q5NDMyZjMxMmZkMGFlMjViMzE%25253D)

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
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.

------
omegote
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?

~~~
ahartmetz
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.

------
akandiah
The link reads like an advert.

~~~
mjburgess
Somewhat concerning this has so many votes. I dont see the hackernews crowd
being sympathetic with a pdf hidden behind a request for information.

Who's voting?

~~~
djsumdog
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.

~~~
dmitriid
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++ :)

~~~
majewsky
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.)

~~~
ahartmetz
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.

------
TeeWEE
What about Flutter? It will also have similar advantages over HTML as QT.

~~~
IshKebab
Yeah I would definitely choose this today. It has only recently become an
option though.

~~~
mamcx
The problem is only usable by dart.

------
TwoBit
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.

~~~
Klonoar
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.

------
_pdp_
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.

~~~
mxschumacher
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.

~~~
bb88
I will say that cost is largely the most important metric, especially when
building millions of devices.

------
dmitriid
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.

------
kabes
The article does seem to ignore the licensing side of things, where QT is more
expensive/restrictive if you're not developing open source projects.

~~~
bb88
The software is going to be cheaper than the hardware for any company
producing quantity of hardware >1000.

~~~
ahartmetz
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.

------
Tempest1981
How about accessibility, and other input methods? Is it hard to do with HTML5?
Do any web frameworks make it easier?

------
singularity2001
Html5: easier to develope and deploy

~~~
ahartmetz
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...

------
krzat
Ideally we would have UI framework that can target both web and native.

Or maybe some kind of next gen HTML that is targeted for maximum performance
(like webassembly is to javascript).

~~~
dotancohen
> 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.

~~~
krzat
The main enemy are Electron apps and this kind of framework would perhaps
eliminate them.

Also I would prefer my flying car with autopilot over airplane.

~~~
dotancohen
That's the problem: Electron _is_ the one-language-everywhere framework and
that's why a chat client or a text editor has a 200 MiB runtime.

~~~
krzat
Maybe I should have been more specific. Ideal UI framework would generate
HTML+webassembly for the web target, but native code for native targets.

Alternatively, there would be smart browser engine which can strip itself from
unused modules during deployment.

------
jlebrech
If QT could produce a "themable" web app where you can give the theme.css of
whatever it generates to a designer would be nice.

~~~
majewsky
Qt Widgets has supported CSS stylesheets for at least a decade:
[http://doc.qt.io/qt-5/stylesheet.html](http://doc.qt.io/qt-5/stylesheet.html)

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.

