Do you count Qt apps as native, but not count web apps as native? Why?
I mean, is anyone clamouring for VS Code, for example, to be rewritten in native toolkits?
I still use Macvim or even Sublime Text a lot for speed reasons, especially on large files.
If we’re going to use JavaScript to write native apps, I’d really like to see things like React Native take off: with a good set of components implemented, it would be a first class environment.
VSCode very quickly freezes because it cannot handle a file that size. Sublime not only opens it but syntax highlights immediately.
Curious what desktop do you run your browser under?
I would give you an example of a simple video split application. A web platform requires uploading, downloading and slow processing. A local app would be hours quicker as the data is local.
(Likewise, applications using the JVM may also look very convincingly like native ones, but you will feel it as soon as you start interacting with them.)
You're fundamentally mistaken about where Qt sits in the stack - it effectively sits in the same place as USER32/WinForms in Windows or NS/Cocoa GUI widgets of OSX. It is reasonable to think of it as an alternative native GUI library in that sense. If it is slower, it's because an implementation of something is slower, not because of where it lives or an abstraction cost.
Qt pretty much draws using low-level drawing APIs on the respective platform. And although Qt itself is not written in the most performance sensitive C++, it is still orders of magnitude faster than most (and it's not like Chrome doesn't pay overhead) - people rag on vtable dispatch speed but jeez its still orders of magnitude faster than something like ObjC which served Apple quite well for years.
The performance of a Qt app is more likely a function of the app itself and how the app developers wrote it.
But no, you're not noticing any micro-seconds differences in C++ overhead for Qt over "native native" - and you're basically comparing the GUI code of the platform - since Qt does it's own rendering. Win32 is mostly pretty good, NS is a mixed bag, and Gtk+ is basically a slug. In all cases there is some kind of dynamic dispatch going on, because that is a fundamental pattern of most GUI libraries. But dynamic dispatch is almost never a factor in GUI render performance. Things like recalculating sizes for 1 million items in a table on every repaint are the things that get people into trouble, and that is regardless of GUI library.
- Qt is actually the native toolkit of multiple operating systems (Jolla for instance and KDE Plasma) - you just need to have a Linux kernel running and it handles the rest. It also does the effort of going to look for the user theme for widgets to mix in with the rest of the platform, while web apps completely disregard that.
- Windows has at least 4 different UI toolkits now which all render kinda differently (win32, winforms, wpf, the upcoming winui, whatever is using Office) - only Win32 is the native one in the original sense of the term (that is, rendering of some stuff was originally done in-kernel for more performance). So it does not really matter on that platform I believe. Mac sure is more consistent, but even then ... most of the apps I use on a mac aren't cocoa apps.
- The useful distinction for me (more than native and non-native) is, if you handle a mouse event, how many layers of deciphering and translation has it to go through, and are these layers in native code (eg. compiled to asm). As it reliably means that user interaction will have much less latency than if you have to go through interpreted code, GC, ...
Of course you can make Qt look deliberately non-native if you want, but by default it tries its best - see https://code.woboq.org/qt5/qtbase/src/plugins/platforms/coco... and code such as https://code.woboq.org/qt5/qtbase/src/plugins/platforms/wind...
Also worth noting that many creation-centric applications for the desktop (graphics, audio, video etc. etc.) don't look "native" even when they actually are. In one case (Logic Pro, from Apple), the "platform leading app from the platform creator" doesn't even look native!
That's true of QtWidgets, but not QML / Qt Quick (the newer tool), correct? (I found this hard to determine online).
But :
- QML can be used with other graphics stack - for instance Qt Widgets like with https://www.kdab.com/declarative-widgets/ or alternatives to the official Qt Quick controls with https://github.com/uwerat/qskinny or with completely custom rendering like here with NanoVG : https://github.com/QUItCoding/qnanopainter
- QtQuick Controls can be made to use the same style hints than the desktop with https://github.com/KDE/qqc2-desktop-style
Put a <button/> in an HTML page and you get a platform-provided UI widget.
I did a small bit of research into this, and found plenty of "anecdotal" evidence, but nothing confirming for sure. I'm looking and interacting with the controls and they seem pretty native - if they're a recreation than that's pretty impressive :)
Implementing the look is simple, adding behaviour quite harder and utilizing the service the endgame. WebUI usually does nothing from those or some parts, it all depends on the constellation. But usually there is a obvious difference at some point where you realize whether something is native or just made an attempt.
Qt also supports rendering directly on the GPU (or with software rendering on the framebuffer) without any windowing system such as X11 or Wayland - that's likely how it is most commonly used in the wild, as that's one of the main way to use it on embedded devices.
You're seriously suggesting that the common use of Qt on Linux systems is direct rendering without the windowing system?
Arguably it's use in embedded contexts is much larger than desktop. It's quite popular for in-car computers, defense systems, etc.
For desktop linux, yes, it uses the windowing system.
I know how Qt works at that level. I did a bunch of work in the mid-naughts on the equivalent stuff in GTK.
I've taken c++ qt desktop apps that never had any intention of running on a phone, built them, ran them, everything "just worked. I was impressed.