Hacker News Reader

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.

If by "silently fail" you mean "entire segments of your UI disappearing" then yes.

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/-/tree/master/examples/advanced-...

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)

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

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

- JS is not needed to create UIs.

- CSS is used for styling, it is important but is not required.

Don't get me wrong, i think QML and XAML are cool and all, but HTML did this a long time ago.

HyperText Markup Language, but also have some UI elements/styles.

Nope, Lisp was there first.

QML on the desktop is highly buggy. The menu bar doesn't close when you click on other windows (even after 10 years), it took a decade to create a half-decent Qt Quick Controls 2 file dialog, there were multiple tab order bugs where pressing Tab hung the app (in Qt Widgets it would instead highlight the wrong widget when you pressed Tab then Shift-Tab) and one of them was fixed after several years mere weeks ago (https://bugreports.qt.io/browse/QTBUG-87190), mouse scrolling (Flickable) works differently from Widgets (and scrolling twice quickly can travel 4 times the distance as scrolling once), on Android it drops frames even on a fairly high-end phone (Pixel 4a) and interactions feels uncanny-valley... I'm under the impression that you're almost not meant to use Qt Quick Controls 2, since KDE created their own Item hierarchy, rejecting Qt's own Flickable altogether.

KDE still uses QQC2 and Flickable. However, we do workaround Flickable's deficiencies by filtering mouse wheel input on QQC2 ScrollViews and setting the content X/Y values so that it moves more like a view in Qt Widgets. It's not ideal. I hope one day I or someone else will be able to fix Flickable's behavior upstream.

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

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)

> 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 (or a small TodoMVC example I did at somepoint to see some actual code: https://github.com/jcelerier/TodoMVC-QML/blob/master/Main.qm... )

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.

There's a common misconception that JSX is XML - that's very excusable as the syntax is based on XML, but it's not the case and you should look into JSX in more depth if you think it is.

However, what's less excusable is thinking React components are somehow equivalent to XML: React components are a lot more than bits of JSX (components very often don't contain any JSX, it's an optional syntax extension, not a fundamental part).

There's very little in common between React components and the XML definitions used by Qt,

> UI with an XML syntax language

If you're interested in learning a bit about how React works, I'll start you off with this: React doesn't really do UI directly at all. It isn't layout-aware, layout is handled by the rendering target: e.g. DOM+CSS for the ReactDOM rendering lib, HTML+CSS for the ReactDOMServer rendering lib, UIKit for the RN iOS rendering lib, etc.

Another fun fact about React (at least React Native): there are basically two separate "engines" for class-based and function-based components, with subtle differences.

I think the point was that they were declarative and retained mode systems and existed long before react. I'm deeply familiar with React and systems such as WPF/QT and I can see the comparison.

> I think the point was that they were declarative ...

> I'm deeply familiar with React

I'm not trying to be snarky here but... React is not declarative.

Though it's good you highlighted that as that is essentially the fundamental difference here: WPF/QT are declarative, CSS is declarative, UIKit is (mostly?) declarative, HTML is declarative(-ish). React components aren't.

I have to disagree. You produce a data structure representing the UI. That's basically the definition of declarative. Just because you can build that dynamically doesn't mean it is not declarative. You could always build up XML dynamically as well.

It's a far cry from an immediate mode API where you are making draw calls.

A React component is a class or function - there is no static "data structure", except for what any individual dev might define as convention for their own application. Unless we're calling class members "declarative data structure", in which case we may need to revisit some definitions across the programming world.

And it's not really representing UI: that's the main point here. Layout is decoupled; it's only really representing front-end logic and state.

I know what React and JSX were 6 years ago, I understand now it much more complex, I even done React components without JSX and use the React.Div functions to render components.

I liked this about react, you create a render function and render your stuff. It is miles of head or the angular horrible architecture but the Web needs basic components implemented naively that developers can extend and not start every time from Zero with divs and other basic stuff.

What's sorely needed is an open state-ful GUI markup language that targets CRUD and data, something HTML/DOM still sucks bigly at. We wouldn't need language binding libraries if we could issue XML to give us all the common and loved GUI idioms like tabs, drop-down menus, data grids, pop-up windows, tool-bars, combo-boxes, etc. (That HTML5 deprecated frames and iframes is a shame. Anti-Kudos to the 5'ers. Fire those b@stards!)

Most business work is still done with mice. Everybody thought fingered mobile would displace mouse-oriented UI's, but that was a bad prediction. Let's do open-source GUI's right this time. (Could QML be reworked to XML and made open-source?)

I have no idea why browsers maker don't look at what Desktop and Mobile GUI frameworks provide and implement same functionality, like give us a ListView or GridView that is implemented to be efficient and you don't have to use pagination as a workaround.

Qt has data grids built in, but QAbstractItemModel is a nightmare to implement and interface with (https://www.reddit.com/r/QtFramework/comments/rx0c8e//hrfvyz..., https://docs.google.com/document/d/1__bldg9SwENN2d6LyiX0wwX5...). I think some of the incidental complexity could be fixed, and the implementation could definitely be simplified by removing dragging between widgets (which requires the model's backing data store be built around adding and removing items, rather than merely reordering them), but I feel it's inherently difficult to communicate changes to data to the QAbstractItemView in the form of individual insert/delete/move operations. I haven't explored the JS world's approaches to UI diffing or lazy-loaded data grids though.

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.

I'm not familiar with the contempt angle of Qt?

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), and rebase on top of Qt 5.15.3 and .4 etc. every so often, until KDE eventually ports to Qt 6.

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

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.

And Skia is also used in Android. It aint going away anytime soon.

kinda funny how native switched to the chrome's 2D renderer and there was no outcry

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.

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

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

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.

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

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.

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.

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.

From my point of view, there's a reasonable chance that the entire world sticks with LGPL Qt5.

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?

I said “if you do something fancy”. For example custom widgets with qpainter, etc

Light/dark theming should be easy with stylesheets.

I think they have a very reasonable licensing model being GPL and Free Software.

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

You conveniently forget about the DOM, for example

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

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

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.

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