Qt QML v HTML5 – a practical comparison

Qt QML v HTML5 –

a praccal comparison

The Sequality boling demo applicaon

This white paper describes the development work needed to create

Qt and HTML5 versions of the same applicaon, and compares

the technologies from a technical and economic perspecve.

Sequality, 05/2017

SOFTWARE

ENGINEERING

From an end-user perspecve, the Qt QML version

behaved exactly as expected regardless of the browser

or screen being used to view it. This is because Qt-

based applicaons are compiled for the target, meaning

that in terms of user observaon, they behave exactly

the same no maer which plaorm they run on.

HTML5-based applicaons, on the other hand, run

on the browser of the target, for example Chrome,

meaning dierent plaorms can show dierent

behavior as the browser might use dierent rendering

engines depending on the plaorm.

In terms of the sustainability of the technology, Qt QML

is a mature technology (compared to most JavaScript

frameworks) that has been developed to ensure

backwards compability. The AngularJS framework for

HTML5 is relavely new, and a valid concern is whether

it will be replaced by a new framework in the future.

In contrast, QML is very likely to sll be supported in 5

years.

Overall, Sequality found that the development of the

applicaons was very dierent and one needs to carefully

consider the benets and drawbacks of each technology

before deciding which one to use.

If the outcome of such an evaluaon does not show

major advantages of a parcular technology, we would

recommend Qt over HTML5. In our showcase, the Qt-

based applicaon was generally faster, more responsive,

and easier to implement.

Background

Sequality is an Austrian soware engineering company

that creates industrial applicaons, user interfaces for

touch displays, and soware for embedded hardware

systems.

Over the past year, more and more customers had

been asking if they should use HTML5 or Qt using the

QML declarave UI language to develop soware for

embedded devices, and wanted to beer understand

the dierences in using the two technologies.

In order to give the most objecve advice to their

customers, Sequality decided set up a test: give the

same developer 160 hours to create a demo of an

embedded system using Qt and 160 hours to create

the demo using HTML5. These demos would show

exactly how the two technologies compare – in terms

of development, performance, and sustainability –

when used to create the same product. This white

paper describes the development work needed to

create the Qt and HTML5 demos, as well as the end

results.

The developer tasked with creang the demos was

experienced with using HMTL5 and C++, but had lile

experience creang user interfaces using Qt and QML.

The demos were created independently without any

vendor input.

Results

The demos showed that although the same amount

of development me was spent on both versions,

implementaon with Qt QMLdelivered a more

funconal and complete user interface than the

HTML5 version. The tesng and debugging process

was found to be more straighorward with Qt QML,

not least because it didn’t need tesng on mulple

browsers.

In general, the Qt QML version responded more quickly

and enabled features, like keyboard and mul-touch,

that were not supported by HTML5 without addional

implementaon.

Over the past year, more

and more customers had

been asking if they should use

HTML5 or Qt using the QML

declarave UI language to develop

soware for embedded devices,

and wanted to beer understand

the dierences in using the two

technologies”

Execuve summary

Sequality, 05/20172

Applicaon requirements

The boling demo applicaon represents a conal

boling plant supervisory control and data acquision

(SCADA) system. The dashboard-like user interface

contains most of the user interface (UI) elements that are

common in modern applicaons.

The applicaon was designed to visualize the process at

the boling plant. The following elements are shown in

the UI:

• Drink ingredients

• An animated bole lling process

• The bole labeling process

• Distribuon (stock, maps, etc.)

• Metadata (users, alerts, etc.)

The applicaon also required the following elements:

• Usability across mulple screens with adapve

design, including a 1024 x 600 touch screen, a 2560

x 1600 high-denion 10-inch tablet, and a 15-inch

1024 x 768 capacive touch screen

• The ability to compensate for the very high pixel

density on a high-denion tablet so that fonts and

icons are easily readable for average users

• A user interface with a at or minimalist design

• A slider panel for sengs similar to an iPhone

• Dierent color design themes switchable at run

me, for example a day and night design theme

• A UI with pop-overs and pin dialogs

• Icons for main menu items

• Fading animaons when switching screens and

changing the size of navigaon bars

• Round animated progress controls

Development approach

Qt demo

A developer who was quite experienced in C++ and

Qt but with lile QML experience implemented the

applicaon in 160 hours. The developer was able get

help from others with Qt and QML knowledge to get

things done more eciently.

HTML5 demo

Once the Qt demo was complete, the same developer

developed the HTML5 version of the boling demo.

The developer had knowledge of HTML5, but was not

experienced with AngularJS. 160 hours were also spent

developing this demo.

Implementaon details

of the Qt version

The applicaon uses QuickControls 2 with custom

styling. The user interface is wrien in QML with

models and logic implemented in C++ classes.

Temperature and pie indicators use a mixed approach

with graphics made with QPainter and wrapped into

QML components.

Overow animaon of progress bars and pie indicators

consists of two animaons being run depending on

value change:

• A simple NumberAnimaon running if the next value

is greater than the previous value

• A sequenal animaon consisng of two

NumberAnimaons otherwise:

• NumberAnimaon from previous value to

maximum value

• Unanimated reset of the current value to 0

• NumberAnimaon from 0 to the next value

The boling demo

Sequality, 05/20173

Implementaon details of the

HTML5 version

There are dierent ways to handle complex animaons

in HTML applicaons:

• jQuery/JavaScript approach. Although it provides

the best portability and enables complex animaons

easily, it was not used because it is outdated and very

slow

• CSS3 animaons:

• transion: acvates on property changes.

Used in simple animaons and corresponds to

NumberAnimaon in QML

• animaon with keyframes: can be used to

implement complex animaons

Overow animaon is not implemented in the HTML5

demo because there’s no easy way to reproduce complex

sequenal animaon from arbitrary value to arbitrary

value:

• CSS3 transions: it was necessary to animate from

the previous value to the max, then from 0 to the

next value. This would require at least two separate

animaons that must be watched to detect their

start and end. Another challenge was that the value is

changed but the animaon is incomplete

• CSS3 keyframes: the nature of keyframes requires

specifying stac to/from values to animate. This

was not possible within the scope because the

values are dynamic and there are at least 100 * 100

combinaons of values (for percentage indicators)

Hardware setup (both versions)

• Raspberry Pi 3

• 1.2GHz 64-bit quad-core ARMv8 CPU

• 1 GB RAM (50% shared with GPU)

• VideoCore IV 3D graphics core

• 15 inch capacive Touch-Display, 1024 x 768

Soware setup (both versions)

• 32-bit Raspbian Jessie (March 2017)

• Qt/QML Demo: Qt 5.7.0, the “vanilla” version, cross-

compiled for Raspberry Pi 3 without custom patches

• HTML5 Demo: stock Chromium browser from

Raspbian repositories

Results aer 160 hours

of development

Note: neither demo is a fully featured applicaon.

For example, some buons don’t work and with the

HTML5 demo there are bigger issues concerning

browser compability and touch gestures. However,

these demos clearly show the strengths and

weaknesses of the technologies.

Features comparison

Qt HTML5

Dynamic theme switching x x

Lists x x

Table view x x

Dynamic search x x

Swipe gestures x x

Map x

Virtual keyboard x

View a video comparing the Qt QML and HTML5

demos at hps://vimeo.com/207307640

Sequality, 05/20174

Performance

• The Qt QML UI was faster than the HTML5 UI

with our setup. The performance dierence is likely

due to the lack of proper OpenGL support by the

Chromium browser on Raspberry Pi, whereas the

Qt QML demo is rendered using OpenGL by the

nature of Qt Quick Scene Graph

• Usage of AngularJS didn’t aect performance in the

HTML5 demo since data binding or DOM generaon

is not used extensively. The whole DOM tree is

generated once at applicaon start, and there is a

small number of models watched by Angular engine

• Enabling GPU rendering on Chromium in chrome://

gpu doesn’t x the HTML5 demo’s performance

problem. In fact, the CPU is ulized even more, which

leads to overheang

Power consumpon

• The Qt QML UI used less power than the HTML5

demo – HTML5 is rendered on the CPU only and

therefore CPU ulizaon remains high

Browser engine

• Browser Engine Blink was the layout and rendering

engine used by the Chromium browser on Raspberry

Pi, Chrome browser on Android, and Chrome browser

on Windows Desktop and various Linux avors. The

HTML5 demo was tested on Chromium for Raspberry

Pi, Chrome on Android, and Chrome on Windows,

and the touch event processing varied on these three

plaorms. For example, the slider widget didn’t work

as expected on Raspberry Pi, but the same code works

well on Android and Windows. Moreover, Chrome on

iOS uses WebKit as the layout engine due to Apple

Store’s limitaons, meaning addional tesng eort is

required when targeng this plaorm

• Both demos use V8 as the JavaScript engine

Styling facilies

Qt QML approach

• QML applicaons do not oer any decoupling of

styling, layouts, and actual components

• The property binding mechanism helps to

implement model view-based architectures

• Colors, font faces, and styles must be specied

explicitly for each component without any property

inheritance

• Sizes are specied in pixels only, so implemenng

an applicaon that should run on devices with

dierent DPIs might be tricky, the property binding

mechanism is used to bind QML element sizes to

available pixel space

• Dynamic theming can be achieved using a singleton

object referenced by all other components. In this

case property binding helps to achieve dynamic

colors, font sizes, and faces

• Dynamic layout requires either instanang several

components/layouts or using components in

Loader. With a high degree of responsiveness in the

requirements, the applicaon structure might quickly

become confusing

• Code reuse might be achieved by nesng QML

objects or using C++ classes and class inheritance

HTML5/CSS3 approach

• HTML applicaons can be easily styled with CSS

• Very good decoupling of styling and markup is possible

• Support for CSS breakpoints and usage of Flex layout

enables the creaon of uid and responsive user

interfaces with lile overhead

• Important property inheritance (font face, size) works

automacally

• Sizes can be specied in relave units, which helps a

lot in displaying UIs on devices with dierent DPIs

• Dynamic theming or a totally dierent layout within

the same screen size can be achieved by loading

another CSS le

Comparison of the Qt QML

and HTML5 demos

Sequality, 05/20175

• Usage of external CSS authoring tools like Less or Sass

provide for a high degree of code reuse like variables,

funcons, and mixins

• CSS authoring tools usually contain funcons to

convert and manipulate color models, so it’s easy to

create dierent color schemes

Features comparison

Qt QML HTML5

Decoupling of styling and

components

Dynamic layout of

components

x x

Styling property inheritance x

Dynamic font faces x x

Relave units for sizes x

Code reuse x x

Manipulang color models x x

Project structure and

modularizaon

An important aspect of any project is keeping it

structured, comprehensible, and modularized. Project

parts should be decoupled as much as possible so that a

change in one module causes as few problems as possible

to other modules.

Some frameworks, like AngularJS, oer a project

structure model from the beginning. Some mature

programming languages like C++ have project structure

paerns that are used by most programmers.

Dening module interfaces in any way makes it easier

to wire project parts together. Singleton enes are

required in most data processing applicaons. Although

they might not be technically implemented (as a singleton

is considered an-paern) data models are a good

example of a semanc singleton enty.

Given the dependencies – for example, the fact that

Users must be instanated before Theming because

Theme depends on User – the task of maintaining a

singleton in an applicaon might become tricky.

C++/Qt/QML approach

• Implemenng logic in C++ and keeping views in QML

is a way of naturally modularizing a project

• C++ programmers tend to put C++ classes into two

les: a header and an implementaon

• QML sll doesn’t have any common paerns for

modularizaon adopted by most developers, so it’s not

uncommon to see dierent approaches from project

to project

• The interface of a component is dened by its

declared properes, slots, or Q_INVOKABLE

methods

• There is no concept of property visibility in QML

components per se, all exposed non-read-only

properes can be overwrien by component users

• QML oers many choices on code recycling: inline

components, components in separate les in the

project structure, libraries in import paths (can also be

manipulated from C++ code), or creang components

dynamically from a string

• Singleton enes can be exposed to QML in three

ways: registering a singleton type, seng a context

property, or declaring a QML component singleton in

qmldir

• All of them require special treatment if the object

being instanated has dependencies from other QML

or C++ objects, i.e. how to ensure in C++ code that

another QML singleton is instanated

• Developers tend to put all context properes and type

registraons to main.cpp or to plugin.cpp which leads

to enormous wiring of these les with dependencies

and prevents good decoupling of otherwise

independent modules

• Making a QML component singleton requires pung

it into a library

• QML nests scope by default and it can’t be turned o

– misuse leads to loss of readability very quickly

• Keeping QML parts of the project neat and

maintaining readability requires good discipline from a

programmer

• Working with actual data doesn’t require any extra

servers or applicaons, Qt oers networking, le I/O,

database drivers, etc

HTML5/CSS3/AngularJS approach

Note: AngularJS was chosen to implement this demo.

Other frameworks might require other techniques.

• With its direcves and components, Angular allows

the introducon of new tags to HTML markup,

eecvely incapsulang implementaon details

• Direcves and components require an HTML

template and a controller (a controller is oponal

for a direcve)

• Controllers, direcves, components, and HTML

templates are usually stored separately in separate

les

Sequality, 05/20176

• The interface of a component or direcve is dened

by its bindings. Bindings also declare data ow (two-

way or one-way in either direcon)

• Styling done in CSS is completely decoupled from all

other parts of the code, although maintaining good

readability and structure requires eort and external

tools

• Angular oers a convenient dependency injecon

mechanism

• Angular oers a single mechanism for singleton

enes

• Angular has a concept of scopes that oponally allows

the capture of data from parent scopes, though misuse

easily leads to loss of readability

• A special topic is managing separate component/

direcve/template les in AngularJS projects:

• in the most basic scenario, all these les must be

manually included in the index.html, which leads to

a radical increase in loading me

• in the more common scenario, these les are

processed by an external tool to produce a single

output le which is included in the index.html

• Actual data processing (working with a database,

le I/O, working with sensors) would require an

HTTP- or a WebSocket-Server that processes

upon request from the web interface. This

introduces addional complexity to the project

Features comparison

C++, Qt,

or QML

HTML5,

CSS3, or

AngularJS

Well-dened inial project

structure

x x

Code recycling using

components

x x

Managing component

dependencies

x x

Eort to maintain project

structure

x x

Working with data directly x

Tesng and debugging

Qt/QML

QML applicaons use a rendering engine provided with

Qt. Normally the Qt version required can be shipped

with the applicaon, which guarantees a consistent

environment for the applicaon.

HTML5/AngularJS

Generally, AngularJS applicaons consist of many

JavaScript sources that are concatenated together

(possibly with dependency resoluon) and loaded as a

single bundle by the browser. Usage of transpilers and

polylls (for example, wring in ES6 and transpiling it to

ES5 in the end product) increases debugging eort as the

produced code is partly not the same as the actual one.

Using source maps helps but they have to be correctly

placed and recognized by the browser. Typos or errors

in AngularJS code are oen silently ignored and have

to be invesgated very thoroughly. There is quite a

steep learning curve with AngularJS when it comes to

data bindings and manipulang DOM in components,

leading to increased development eorts for quite simple

interacons like swipes or drags.

AngularJS has encouraged test-driven development from

the beginning (see Google’s tutorials on AngularJS). QML

and Qt provide unit-tesng frameworks as well, although

do not push into using them. Overall, a TDD approach

might be extremely useful for end-product quality but

requires a lot of eort in the creaon and maintenance

of tests with good coverage. This eort oen not only

compares to, but also exceeds the eort of wring the

actual code that is being tested.

The fact that HTML5 applicaons can be executed

on a number of plaorms – and a number of browser

engines on each plaorm – mulplies the tesng

me correspondingly. Requiring a specic version

of a browser might not be an opon for tablets or

smartphones where updates are installed automacally.

Even on desktop computers, the default seng is

nowadays to install browser updates without any

interference from the user.

Sequality, 05/20177

Sustainability of the technology

Web applicaons

With the rapid development of web applicaons

in recent years, new client-side and server-side

frameworks are constantly emerging. Major new

versions of frameworks are released in short cycles

and adopt new paerns in web engineering. This might

discard backwards compability and support for older

versions, increasing maintenance costs. Projects with

a longer lifespan may use outdated frameworks and

libraries unl it becomes cheaper to write everything

from scratch using completely new technology and

architecture.

Moreover, the JavaScript language itself has undergone

revision in recent years. It now incorporates features

like scoped variables, classes, and modules (in

ECMAScript 6), leaving web developers to deal with

lack of support for all the features of the language in

major browsers. Supersets of ES6 like TypeScript are

acvely used as well, and are not directly supported by

browsers, forcing web engineers to use transpilaon to

the most portable old version of JavaScript. Luckily, the

new versions of the language are supersets of the older

versions and maintain backwards compability.

Apart from using exisng frameworks, there’s always

a temptaon to make your own in-house soluon to

exactly fulll the requirements of the project. This

might be considered feasible as long as the developers

working on it don’t leave the project, otherwise it

would be yet another framework to learn with most

probably non-existent or minimal documentaon and

no internet resources – creang the need to rewrite

the applicaon using exisng frameworks or invenng a

new one.

The nature of web engineering forces developers to

use a complex mul-step build process to produce a

working applicaon. Not only do frameworks change,

but the build tools change rapidly as well – like Grunt,

Gulp, webpack, etc.

Another queson to consider is the browser on the

client side. With mulple rendering engines on the

market, the applicaon has to be tested for all of them

and on all plaorms. With extremely short release

cycles of browsers (like Firefox) and seamless updates

(like Chrome or Edge), it’s virtually impossible to

keep up. Targeng older browser versions also brings

problems: they don’t support newer CSS/JavaScript

features and might behave dierently when rendering.

A supported version bump in the future doesn’t help

if some users keep the older version of their browsers

and are therefore unable to use the applicaon

anymore.

The ne granularity of popular frameworks forces

developers to use several frameworks in one project

to achieve their goal. Each framework or library has its

own style, integraon level, documentaon, release

cycle, and level of support.

Though the web applicaon stack will somehow

stabilize in the next few years, it’s important to make

good decisions on what technologies to use, so that

the project won’t have to be rewrien from scratch

mulple mes.

Sustainability of C++/Qt/QML

C++ is a mature language that has proven to be

conservave and slow changing. The adopon of the

major C++11 standard in projects followed by its C++14

extension is fairly slow because of a lack of support by

major compilers. The 4th edion of Stroustrup’s The

C++ Programming Language including C++11 features

was published in 2013, two years aer the standard

was raed. All the C++ standards up to and including

C++17 are backwards compable with the older

version.

The Qt framework has been on the market since 1995,

with major versions released in 1999 (Qt 2, lifespan of

2 years), 2001 (Qt 3, lifespan of 4 years), 2005 (Qt 4,

lifespan of 7 years) and 2012 (Qt 5, lifespan of at least

5 years). Source compability was largely maintained

during the transion from Qt 4 to 5, whereas previous

transions broke the compilaon process. That is, the

transion should have been made either completely or

not at all. Qt 4 introduced Qt3-support classes for a

smoother transion to the newer version of the library.

Paradigms and approaches used in Qt have remained

mostly the same throughout recent major releases.

That means having learned Qt once, one is able to

develop Qt applicaons for at least the current and

next major release. With a median cycle of major

releases every 4 years, this typically means sustainable

project development for at least 8 years.

As for now, Qt 5.x is developed in a 6-month cycle with

API and ABI compability.

Sequality, 05/20178

The Qt framework covers most areas of

applicaon development one might need in a

project oering uniform class names, a single

paradigm throughout the whole framework,

accurate documentaon, and good portability.

QML appeared in 2010 in Qt 4.7 and has been

developed and polished constantly ever since.

There’s been evoluonary development of the

language from the beginning while maintaining

backwards compability. Moreover, the module

version system ensures the correct outcome of an

applicaon being processed by newer versions of

QML engines.

As menoned earlier, unlike any HTML5

framework or library, Qt is a general-purpose

framework and more or less self-contained – an

applicaon using Qt wouldn’t require addional

libraries for widgets, networking, databases, serial

bus, etc.

Sequality, 05/20179

Performance

Overall

• Both technologies are capable of separang design

from business logic

• Both technologies are capable of rendering pixel-

perfect UI designs on mulple plaorms

Speed

• The QML version of the demo is faster than the

HTML5 version

• With HTML5, latency me between user interacon

and user interface response is higher with our setup

Features

• The QML version has complex swipe gestures

(setup-slider, mul-touch zooming) that are not

available in HTML5 out of the box

• The QML version has a virtual keyboard – no such

component is available with HTML5 out of the box

Plaorm

• Qt-based applicaons are compiled for the target,

meaning that in terms of user observaon, they

behave exactly the same no maer which plaorm

they run on

• HTML5-based applicaons run on the browser of

the target (e.g. Chrome), meaning dierent plaorms

can show dierent behavior as the browser might

use dierent rendering engines depending on the

plaorm. Browser tesng is a major development

cost factor in HTML5 based applicaons

Connecon to hardware

• Low-latency sensor connecons to direct hardware

components are easier with C++/Qt as you have

direct contact to the embedded hardware

• With HTML5, if the applicaon has to react quickly

to sensor input (for example, CAN-Bus-Value, GPIO-

Pin, RS232, bluetooth, gyrometer), it can get very

dicult to route this signal through the hp-server,

browser, and javascript to the HTML5 frontend

Summary: comparing

Qt QML with HTML5

Animaons

• Qt QML has built-in support for animaons in the

language, and transions can be ne tuned

• With HTML5, there are several ways to implement

animaons, which can make it quite tricky to get

exactly what you want from an animaon

• Modern embedded applicaons benet by having a

dedicated OpenGL-capable graphics processer that

can render animaons in a smooth way. Making use

of the OpenGL processer in an HTML5-browser-

based seng is somewhat tricky – whether actual

rendering can be done with the help of OpenGL

depends on the browser. In the HTML5 demo with

our setup, most rendering is done only on the CPU.

In the QML demo, all rendering is done by the

OpenGL-based engine

Tesng and debugging

• Both HTML5 and QML can get somewhat tricky

to test, which is true for most complex interacve

visualizaons

• With QML, complex logic is usually implemented in

convenonal C++ code, which oers the benet of a

strictly typed programming language - an advantage

when tesng and debugging applicaons

• With AngluarJS, all logic is wrien in a weakly typed

environment, unless you use TypeScript, which is

again a technology that has to be learned and used

• Generally speaking, one uses third-party tools (e.g.

Babel, require.JS, webpack) to generate the runnable

HTML5/AngularJS applicaon out of a project. As

a result, the code running in the browser is oen

not the same as the code wrien in your IDE. In our

opinion, wring applicaons in AngularJS requires a

more profound knowledge of the whole technology

stack to develop and debug complex applicaons.

Addionally, the technology-stack-components within

an AngularJS applicaon change rather rapidly, which

makes it even harder to follow and understand

Sequality, 05/201710

Sustainability consideraons

• Qt has been around since the 1990s and Qt QML

since 2011

• Modern HTML5-based applicaons that use

frameworks like AngularJS are relavely new

and undergo changes from year to year – a valid

queson is whether AngularJS (or any other

currently trendy Javascript-library) will sll be a

relevant HTML5-technology in 10 years

Sequality, 05/201711

About Sequality

Sequality soware engineering is an

Austrian soware consulng company

that is your partner for creang soluons

in the area of industrial applicaons,

touch display user interfaces, and

embedded soware applicaons.

Usability plays an important role when

creang our applicaons. Together

with usability engineers and UX

designers, we can ship leading-edge UI

technology applicaons that contain

user-friendly funconality, look great,

and deliver a seamless user interface

experience.

sequality soware engineering e.U.• Sowarepark 26A-4232 Hagenberg

www.sequality.at • t. +43 7236 26 101 • m. +43 676 97 72 681

stefan.larndorfer@sequality.at • oce@sequality.at

SOFTWARE

ENGINEERING