7 ms·

Qt is an amazing piece of tech that got many things right. 1. Performance that matches native speeds 2. Single codebase for multiple platforms (without relyin

Qt is an amazing piece of tech that got many things right. 1. Performance that matches native speeds 2. Single codebase for multiple platforms (without relying on web technologies) 3. Not limited with a single language (has bindings to all major languages) 4. The core is written in a performant language (C++) But recent developments in UI programming is sidelining frameworks like Qt with some really good innovations. - Like React/React-native ecosystem pioneered the component based declarations of UI elements. - Flutter pushed it to all platforms with Skia as the rendering engine - Jetpack Compose is pushing it with a better language (Kotlin) - State management had matured a lot with redux style immutable stores The irony is even with all these recent developments there isn't a single UI framework that took the best parts of older frameworks like Qt and combined it with the recent ideas from Flutter and Jetpack-compose! If it did it all, the multi-platform support is handicapped. Either the native strategy becomes an afterthought or the Web becomes an afterthought, hurting accessibility, etc. We still have a long way to go in cross-platform UI frameworks :)

deleted 4y ago
[deleted]
bsnal 4y ago
1. Qt is much faster than other UI technologies, but it’s far from being as performant as native solutions are. 2. You will need a big amount of hacks to make your project work on different platforms. Especially if you do something fancy. Not to mention serious licencing issues.
- joezydeco 4y ago
  Licensing has gotten much worse, so much so that my current firm is sticking with our Qt5 contract and will not negotiate to Qt6. So we're hitting the end of the road with Qt in the next few years. On top of that, priorities are just different now. I spent an afternoon chasing down why QtCore has incomplete or missing methods for handling JSON documents (TLDR: "won't fix"), but I get a constant stream of marketing email promoting their new in-app advertising structure. And now there's a speech recognition engine? I'm just done with it all. Guess I need to learn React.
  - bsnal 4y ago
    This is my experience as well. Core bugs keep pilling up for years at an alarming rate while they focus on adding new functionality that most developers don’t need. Their bad licencing made sense back in the day. But they now face strong competition and instead of moving to a more open licence system, they seem to be doubling down. They don’t seem to understand that not only they aren’t the only framework in town anymore, they are currently worse than much better licenced systems.
  - marcosdumay 4y ago
    From my point of view, there's a reasonable chance that the entire world sticks with LGPL Qt5.
- shrimp_emoji 4y ago
  Can you expand on this? >You will need a big amount of hacks to make your project work on different platforms. Especially if you do something fancy. Having done Windows-Linux Qt, I haven't noticed needing "hacks" (unless you count the hacks necessary to build anything on Windows at all cuz the OS wasn't meant for programming ;p). The fanciest thing I've done is theming (light, dark, etc.), which Qt doesn't seem to support natively, and which is difficult to do sanely without some "hacking". >Not to mention serious licencing issues. What issues? Is it just that it's LGPL, or what?
  - bsnal 4y ago
    I said “if you do something fancy”. For example custom widgets with qpainter, etc Light/dark theming should be easy with stylesheets.
- dal 4y ago
  I think they have a very reasonable licensing model being GPL and Free Software.
- SemanticStrengh 4y ago
  > Qt is much faster than other UI technologies, but it’s far from being as performant as native solutions are. What does it feels like to spit random beliefs out of your hat and state them as truth? Native doesn't even mean anything, there really is something wrong going on on the mental models people have when talking about GUIs. IIRC QT use GDI+ on Windows for drawing 2D GUIs, which is mostly CPU based. And its shows in many tasks, see e.g. the strokePoly40 https://blend2d.com/performance.html https://blend2d.com/performance.html Chromium use Skia and gecko use webrender, those are much much much faster on average. In fact the web has more FPS than native libraries in general.
  - bsnal 4y ago
    You conveniently forget about the DOM, for example
    - SemanticStrengh 4y ago
      I'm not seeing why the DOM would necessarily makes rendering slower. See e.g. this comparison showing react web being faster and more energy efficient than react-native. https://ionicframework.com/blog/ionic-vs-react-native-performance-comparison/ https://ionicframework.com/blog/ionic-vs-react-native-perfor... It's true that pathological DOM dynamism might incur some cache/layout invalidations, however if that were to be an issue (which is very rare and profiling is easy), you could mostly eliminate the problem with a few lines of https://developer.mozilla.org/en-US/docs/Web/CSS/contain https://developer.mozilla.org/en-US/docs/Web/CSS/contain
- dTal 4y ago
  > 1. Qt is much faster than other UI technologies, but it’s far from being as performant as native solutions are. As a Linux user, do tell me what the "native" solution is that I should be using! I love performance.
Kelteseth 4y ago
QML is Qts innovation. The declarative way to write a UI is unmatched IMHO when comparing to Unreal, Godot or the Web. Still, QML has a _lot_ of other little problems like bad tooling (no autoreload, unusable designer) and often broken type system where you can assign invalid properties, and it will silently fail.
- joezydeco 4y ago
  If by "silently fail" you mean "entire segments of your UI disappearing" then yes.
- eql5 4y ago
  Autoreload can be added quite easily, like in this Lisp binding, which has an example where even single file autoreload works, both on desktop and mobile, simultaneously: https://gitlab.com/eql/lqml https://gitlab.com/eql/lqml https://gitlab.com/eql/lqml/-/tree/master/examples/advanced-qml-auto-reload https://gitlab.com/eql/lqml/-/tree/master/examples/advanced-...
- enqk 4y ago
  It's also not truly declarative since you can observe ordering (and therefore your app may silently depend on imperative execution) There's also performance issues with large amount of code, and last I checked, Qml doesn't really mix well with the traditional Qt widget and protocols (i.e. sometimes things are reimplemted in Qml under similar names, but with different behaviors)
- mariusmg 4y ago
  >QML is Qts innovation. The declarative way to write a UI is unmatched when comparing to...the Web What? Isn't HTML the daddy of declarative languages for UI ?
  - dahfizz 4y ago
    > Isn't HTML the daddy of declarative languages for UI ? Not really. HTML is a way to create documents. It's closer to latex than QML. HTML + CSS + JS is used to create UIs, but it definitely does not match the capabilities of something like QML.
simion314 4y ago
-Like React/React-native ecosystem pioneered the component based declarations of UI elements. What do you mean? Qt,WPF, Flex was doing UI with an XML syntax language before React existed, some people prefered doing things by hand instead of rag and drop back then too. The "components" were named Controls or Widgets and the Web still is a inferior pile of shit because in this old tooljits when you needed say a custom DataGrid widget you extended the existing one and where in Web you start from Zero with divs,inputs and buttons.
- lewisjoe 4y ago
  I think you are confusing XML style UI declarations with composable-components-based UI declarations. To cut the explanation short, the former means while initial UI state was declarative (with XML), runtime mutations of UI were mostly imperative with a binding turing complete language. The recent Component based model of composing UI - the runtime mutations of the elements are expressed as state updates inside the UI declarations itself(and declarations are usually done with a turing complete language)
  - jcelerier 4y ago
    > The recent Component based model of composing UI - the runtime mutations of the elements are expressed as state updates inside the UI declarations itself(and declarations are usually done with a turing complete language) is pretty much how Qt does it with QML (released in 2011), except that instead of requiring explicit function calls, the variables are themselves reactive so that: Button { text: "foo" + counter.value } updates automatically whenever "value" changes. See e.g. https://www.qt.io/product/qt6/qml-book https://www.qt.io/product/qt6/qml-book (or a small TodoMVC example I did at somepoint to see some actual code: https://github.com/jcelerier/TodoMVC-QML/blob/master/Main.qml https://github.com/jcelerier/TodoMVC-QML/blob/master/Main.qm... )
  - simion314 4y ago
    you think bindings are super cool like bind the hidden state of soemthing to some variable then Flex did it before React and probably was not the first. Compos ability for me means I can make a big component by combining smaller ones, what does it mean to you? Extensibility is the important part, you can get a DataGrid and add 10 lines of code to add some feature to it and you inherit everything from the base component, you get it all: the performance, the events, the accessibility. In web I only see shitty implementation that fail in different ways, even the YouTube search + dropdown input fails sometimes and remains open until you reload the page, a ton of Google "geniuses" can't implement a shitty component with all their languages and frameworks. I personally like about react the functional part of it and not the JSX part, that is sugar syntax, though when doing complex stuff the functional part brke and you had no choice then get your hands dirty and find workarounds and do ugly stuff.
orangepurple 4y ago
Give it a few years and Flutter/Skia will be Killed By Google™ https://killedbygoogle.com/ https://killedbygoogle.com/
- sounds 4y ago
  Skia is the compositing/rendering engine for Chrome. I doubt Chrome will stop using Skia, though Google can always do something akin to a fork or name-change that will break all existing apps. Highly doubtful that will happen.
  - MrDresden 4y ago
    And Skia is also used in Android. It aint going away anytime soon.
    - SemanticStrengh 4y ago
      kinda funny how native switched to the chrome's 2D renderer and there was no outcry
Matl 4y ago
I'd add treating the KDE community with contempt to the negative side of your list. KDE did a lot to breathe life into Qt and that seems to have been forgotten.
- digisign 4y ago
  I'm not familiar with the contempt angle of Qt?
  - nyanpasu64 4y ago
    There were rumors that Qt wanted to take the project proprietary. They didn't go through with those plans, but right now they are delaying all patch releases of Qt5 by 12 months, forcing KDE to maintain their own set of backported patches )https://invent.kde.org/qt/qt/qtbase/-/tree/kde/5.15 https://invent.kde.org/qt/qt/qtbase/-/tree/kde/5.15), and rebase on top of Qt 5.15.3 and .4 etc. every so often, until KDE eventually ports to Qt 6.
HelloNurse 4y ago
What do you mean by "component based declarations of UI elements"? Declarative specification of UI widgets (e.g. XUL) is much older than web-based component frameworks like React. Component orientation in UI frameworks is even more traditional, and far older than Qt. What "recent ideas" do you find in Jetpack Composer, Flutter and React Native that Qt lacks? These tools let you write apps with a nice user interface for Android exactly like Qt; supporting Kotlin, Dart, Javascript etc. besides C++ and various Qt language bindings is useful, but not necessarily superior.
- mosdl 4y ago
  Even React wasn't the first web framework to do this, Dojo for example did this way back as well.
jjtheblunt 4y ago
> Like React/React-native ecosystem pioneered the component based declarations of UI elements. why don't you consider NeXTSTEP from 1988 on to the present day in macOS UIKit?
heavyset_go 4y ago
QML and QtQuick are actually declarative and reactive in ways that React isn't, and I find them much more pleasant to use than React, especially when it comes to separation of concerns. They've existed for quite some time, too.
nsonha 4y ago
Single code base for multiple platforms is not impressive these days, you can do it in many frameworks. The key thing seems to be 1. written in C++ (hence performant) and 2. Has a declarative language (QML). 1 is no longer an advantage since C++ is no longer a desirable language for UI engineers, largely because UI went from desktop to mobile and web which created an opportunity to disrupt the status quo 2 is no longer trendy either as functional programming becomes more popular. People realized they can be declarative in real programming languages and don't have to turn UI into a bunch of config files.
jasfi 4y ago
If you like Flutter but want a simplified SDK that also works on the back-end, check out the upcoming DocUI project: https://nexusdev.tools https://nexusdev.tools
dTal 4y ago
>Not limited with a single language (has bindings to all major languages) Actually I find this to be a serious pain point. Qt leans heavily on C++ features for core parts of its API (subclassing to create new widgets, for instance), and has its own C++ pre-processor. Getting to work in a different language in any capacity greater than "toy demo" is insanely hard - PyQt is probably the only success story here. I don't believe I have ever encountered a "real" program that uses Qt that was not written in C++ or Python.

deleted 4y ago

[deleted]

bsnal 4y ago

1. Qt is much faster than other UI technologies, but it’s far from being as performant as native solutions are. 2. You will need a big amount of hacks to make your project work on different platforms. Especially if you do something fancy. Not to mention serious licencing issues.

joezydeco 4y ago
Licensing has gotten much worse, so much so that my current firm is sticking with our Qt5 contract and will not negotiate to Qt6. So we're hitting the end of the road with Qt in the next few years. On top of that, priorities are just different now. I spent an afternoon chasing down why QtCore has incomplete or missing methods for handling JSON documents (TLDR: "won't fix"), but I get a constant stream of marketing email promoting their new in-app advertising structure. And now there's a speech recognition engine? I'm just done with it all. Guess I need to learn React.
- bsnal 4y ago
  This is my experience as well. Core bugs keep pilling up for years at an alarming rate while they focus on adding new functionality that most developers don’t need. Their bad licencing made sense back in the day. But they now face strong competition and instead of moving to a more open licence system, they seem to be doubling down. They don’t seem to understand that not only they aren’t the only framework in town anymore, they are currently worse than much better licenced systems.
- marcosdumay 4y ago
  From my point of view, there's a reasonable chance that the entire world sticks with LGPL Qt5.
shrimp_emoji 4y ago
Can you expand on this? >You will need a big amount of hacks to make your project work on different platforms. Especially if you do something fancy. Having done Windows-Linux Qt, I haven't noticed needing "hacks" (unless you count the hacks necessary to build anything on Windows at all cuz the OS wasn't meant for programming ;p). The fanciest thing I've done is theming (light, dark, etc.), which Qt doesn't seem to support natively, and which is difficult to do sanely without some "hacking". >Not to mention serious licencing issues. What issues? Is it just that it's LGPL, or what?
- bsnal 4y ago
  I said “if you do something fancy”. For example custom widgets with qpainter, etc Light/dark theming should be easy with stylesheets.
dal 4y ago
I think they have a very reasonable licensing model being GPL and Free Software.
SemanticStrengh 4y ago
> Qt is much faster than other UI technologies, but it’s far from being as performant as native solutions are. What does it feels like to spit random beliefs out of your hat and state them as truth? Native doesn't even mean anything, there really is something wrong going on on the mental models people have when talking about GUIs. IIRC QT use GDI+ on Windows for drawing 2D GUIs, which is mostly CPU based. And its shows in many tasks, see e.g. the strokePoly40 https://blend2d.com/performance.html https://blend2d.com/performance.html Chromium use Skia and gecko use webrender, those are much much much faster on average. In fact the web has more FPS than native libraries in general.
- bsnal 4y ago
  You conveniently forget about the DOM, for example
  - SemanticStrengh 4y ago
    I'm not seeing why the DOM would necessarily makes rendering slower. See e.g. this comparison showing react web being faster and more energy efficient than react-native. https://ionicframework.com/blog/ionic-vs-react-native-performance-comparison/ https://ionicframework.com/blog/ionic-vs-react-native-perfor... It's true that pathological DOM dynamism might incur some cache/layout invalidations, however if that were to be an issue (which is very rare and profiling is easy), you could mostly eliminate the problem with a few lines of https://developer.mozilla.org/en-US/docs/Web/CSS/contain https://developer.mozilla.org/en-US/docs/Web/CSS/contain
dTal 4y ago
> 1. Qt is much faster than other UI technologies, but it’s far from being as performant as native solutions are. As a Linux user, do tell me what the "native" solution is that I should be using! I love performance.

Kelteseth 4y ago

QML is Qts innovation. The declarative way to write a UI is unmatched IMHO when comparing to Unreal, Godot or the Web. Still, QML has a _lot_ of other little problems like bad tooling (no autoreload, unusable designer) and often broken type system where you can assign invalid properties, and it will silently fail.

joezydeco 4y ago
If by "silently fail" you mean "entire segments of your UI disappearing" then yes.
eql5 4y ago
Autoreload can be added quite easily, like in this Lisp binding, which has an example where even single file autoreload works, both on desktop and mobile, simultaneously: https://gitlab.com/eql/lqml https://gitlab.com/eql/lqml https://gitlab.com/eql/lqml/-/tree/master/examples/advanced-qml-auto-reload https://gitlab.com/eql/lqml/-/tree/master/examples/advanced-...
enqk 4y ago
It's also not truly declarative since you can observe ordering (and therefore your app may silently depend on imperative execution) There's also performance issues with large amount of code, and last I checked, Qml doesn't really mix well with the traditional Qt widget and protocols (i.e. sometimes things are reimplemted in Qml under similar names, but with different behaviors)
mariusmg 4y ago
>QML is Qts innovation. The declarative way to write a UI is unmatched when comparing to...the Web What? Isn't HTML the daddy of declarative languages for UI ?
- dahfizz 4y ago
  > Isn't HTML the daddy of declarative languages for UI ? Not really. HTML is a way to create documents. It's closer to latex than QML. HTML + CSS + JS is used to create UIs, but it definitely does not match the capabilities of something like QML.

simion314 4y ago

-Like React/React-native ecosystem pioneered the component based declarations of UI elements. What do you mean? Qt,WPF, Flex was doing UI with an XML syntax language before React existed, some people prefered doing things by hand instead of rag and drop back then too. The "components" were named Controls or Widgets and the Web still is a inferior pile of shit because in this old tooljits when you needed say a custom DataGrid widget you extended the existing one and where in Web you start from Zero with divs,inputs and buttons.

lewisjoe 4y ago
I think you are confusing XML style UI declarations with composable-components-based UI declarations. To cut the explanation short, the former means while initial UI state was declarative (with XML), runtime mutations of UI were mostly imperative with a binding turing complete language. The recent Component based model of composing UI - the runtime mutations of the elements are expressed as state updates inside the UI declarations itself(and declarations are usually done with a turing complete language)
- jcelerier 4y ago
  > The recent Component based model of composing UI - the runtime mutations of the elements are expressed as state updates inside the UI declarations itself(and declarations are usually done with a turing complete language) is pretty much how Qt does it with QML (released in 2011), except that instead of requiring explicit function calls, the variables are themselves reactive so that: Button { text: "foo" + counter.value } updates automatically whenever "value" changes. See e.g. https://www.qt.io/product/qt6/qml-book https://www.qt.io/product/qt6/qml-book (or a small TodoMVC example I did at somepoint to see some actual code: https://github.com/jcelerier/TodoMVC-QML/blob/master/Main.qml https://github.com/jcelerier/TodoMVC-QML/blob/master/Main.qm... )
- simion314 4y ago
  you think bindings are super cool like bind the hidden state of soemthing to some variable then Flex did it before React and probably was not the first. Compos ability for me means I can make a big component by combining smaller ones, what does it mean to you? Extensibility is the important part, you can get a DataGrid and add 10 lines of code to add some feature to it and you inherit everything from the base component, you get it all: the performance, the events, the accessibility. In web I only see shitty implementation that fail in different ways, even the YouTube search + dropdown input fails sometimes and remains open until you reload the page, a ton of Google "geniuses" can't implement a shitty component with all their languages and frameworks. I personally like about react the functional part of it and not the JSX part, that is sugar syntax, though when doing complex stuff the functional part brke and you had no choice then get your hands dirty and find workarounds and do ugly stuff.

orangepurple 4y ago

Give it a few years and Flutter/Skia will be Killed By Google™ https://killedbygoogle.com/ https://killedbygoogle.com/

sounds 4y ago
Skia is the compositing/rendering engine for Chrome. I doubt Chrome will stop using Skia, though Google can always do something akin to a fork or name-change that will break all existing apps. Highly doubtful that will happen.
- MrDresden 4y ago
  And Skia is also used in Android. It aint going away anytime soon.
  - SemanticStrengh 4y ago
    kinda funny how native switched to the chrome's 2D renderer and there was no outcry

Matl 4y ago

I'd add treating the KDE community with contempt to the negative side of your list. KDE did a lot to breathe life into Qt and that seems to have been forgotten.

digisign 4y ago
I'm not familiar with the contempt angle of Qt?
- nyanpasu64 4y ago
  There were rumors that Qt wanted to take the project proprietary. They didn't go through with those plans, but right now they are delaying all patch releases of Qt5 by 12 months, forcing KDE to maintain their own set of backported patches )https://invent.kde.org/qt/qt/qtbase/-/tree/kde/5.15 https://invent.kde.org/qt/qt/qtbase/-/tree/kde/5.15), and rebase on top of Qt 5.15.3 and .4 etc. every so often, until KDE eventually ports to Qt 6.

HelloNurse 4y ago

What do you mean by "component based declarations of UI elements"? Declarative specification of UI widgets (e.g. XUL) is much older than web-based component frameworks like React. Component orientation in UI frameworks is even more traditional, and far older than Qt. What "recent ideas" do you find in Jetpack Composer, Flutter and React Native that Qt lacks? These tools let you write apps with a nice user interface for Android exactly like Qt; supporting Kotlin, Dart, Javascript etc. besides C++ and various Qt language bindings is useful, but not necessarily superior.

mosdl 4y ago
Even React wasn't the first web framework to do this, Dojo for example did this way back as well.

jjtheblunt 4y ago

> Like React/React-native ecosystem pioneered the component based declarations of UI elements. why don't you consider NeXTSTEP from 1988 on to the present day in macOS UIKit?

heavyset_go 4y ago

QML and QtQuick are actually declarative and reactive in ways that React isn't, and I find them much more pleasant to use than React, especially when it comes to separation of concerns. They've existed for quite some time, too.

nsonha 4y ago

Single code base for multiple platforms is not impressive these days, you can do it in many frameworks. The key thing seems to be 1. written in C++ (hence performant) and 2. Has a declarative language (QML). 1 is no longer an advantage since C++ is no longer a desirable language for UI engineers, largely because UI went from desktop to mobile and web which created an opportunity to disrupt the status quo 2 is no longer trendy either as functional programming becomes more popular. People realized they can be declarative in real programming languages and don't have to turn UI into a bunch of config files.

jasfi 4y ago

If you like Flutter but want a simplified SDK that also works on the back-end, check out the upcoming DocUI project: https://nexusdev.tools https://nexusdev.tools

dTal 4y ago

>Not limited with a single language (has bindings to all major languages) Actually I find this to be a serious pain point. Qt leans heavily on C++ features for core parts of its API (subclassing to create new widgets, for instance), and has its own C++ pre-processor. Getting to work in a different language in any capacity greater than "toy demo" is insanely hard - PyQt is probably the only success story here. I don't believe I have ever encountered a "real" program that uses Qt that was not written in C++ or Python.