It was in the middle of midnight when I stumbled upon a white-paper comparing Qt QML app development with web app development. I like the idea to compare these two wonderful technology, however more I read the white-paper more I dislike it. I think it’s just another misleading marketing stun. Let’s dive down a bit on this white-paper titled Qt QML vs HTML5 – A Practical Comparison.
So in this whitepaper an Austrian company tasked a developer to build an Embedded Application using QT and HTML5, the developer had 160 Hours to build the QT version then another 160 Hours for the HTML5 version. The developer was experienced in HTML5 and C++ but had little experience on building QT/QML apps.
From this point please read the whitepaper before continuing this post, for complete context.
I think there is one main misconception which leads to inappropriate comparison in this whitepaper.
The definition of Embedded Application; I would say embedded application would come in packaged and controlled target machine, like for webapp we can pick whichever browser our app work best. And for QT apps would mean which operating system and hardware platform the apps is targeted, so we can limit the build number to release. On both software stack or in embedded application generally, limiting target environment means less testing and less extra variable to take into account.
The white-paper was using Raspberry Pi with Debian as target platform and Chromium as testing platform for the HTML5 apps. So it is quite clear for both version, but later the white-paper stated “The testing and debugging process was found to be more straightforward with Qt QML, not least because it didn’t need testing on multiple browsers.” Even-though this is true but in this case it’s not correct to compare between QT app with 1 target platform and HTML5 targeting multiple browser. That’s just unfair, how about providing and testing different build of QT apps on different platforms? The white-paper didn’t even mention this fact (the fact that different build is needed for each QT target platform).
I agree with most point on this comparison, which shows the power of QT as native application and has superb support of accelerated rendering. However “Browser Engine” part of this chapter really annoyed me, “The HTML5 demo was tested on Chromium for Raspberry Pi, Chrome on Android, and Chrome on Windows” and “Moreover, Chrome on iOS uses WebKit as the layout engine due to Apple Store’s limitations, meaning additional testing effort is required when targeting this platform “. Why they bring this up in this “Performance” context? My main concern still stand here.
This white-paper does bring quite good things in the side of implementation details, unfortunately it also contains a few things which make it feels like just usual marketing content.