Developing a Beautiful and Performant Block Editor in Qt C++ and QML

The tooling, that is why.

Having QtCreator, Qt Design Studio, compiling QML to native code, debugging experience.

React Native has all the gotchas from JavaScript and poor tooling for developers that never left the CLI world.

Flutter depends on Dart, a programming language that was rescued from oblivion thanks to Flutter, and is pretty much useless everywhere else.

I've encountered tons of bugs (many of them still unfixed) that I had to find very ugly workarounds for. Also, while a declarative style UI language can have a lot of benefits, it does also have a lot of limitations. For example, in my application I required a (infinite) canvas to rendering the ink strokes, which would be a perfect job for QGraphicsView, but there is no equivalent in Qt Quick. So I had to roll out my own component (which uses Skia under the hood), but that was quite painful. Since Qt 6, the Qt Quick scenegraph is rendered with a custom RHI backend (abstracting over Vulkan, Metal, OpenGL and DirectX) which I had a lot of trouble integrating with third party engines (I really wish they had a WebGPU backend).

[0] https://scrivanolabs.github.io

QML is better suited for apps that want full control of their UIs, styling, etc... Which is a more modern way (doesn't mean better!).

It is clear that the author wants the latter, so QML it is.

And yes, it makes sense to use a different language for the UI in this case, with C++ bindings, C++ is not that great for designing UIs. In fact, with QtWidgets, you typically don't use C++ to design your UI. Instead, you use Qt Designer, a graphical tool that works on .ui files (xml), that are then compiled into C++ classes that your derive from, which is a form of binding between two languages: C++ and .ui/xml. You can use C++ directly, sometimes you have to, like when the UI is dynamically generated, but for something like a dialog box, using the graphical tool is much more convenient.

Those that think it shouldn't be, end up yak shaving trying to bring UNIX and C concepts to platforms that no longer care about that.

So use the old one? Your first link literally mentions two ancient frameworks that are not abandoned (win32 and MFC)

But you're right

> So, it's more useful to ask: what do we expect from good native apps?

The challenge, though, is there isn't really a good comprehensive list of those things the would allow you to compare the framework you use to native. And you can't patch everything if you don't even know where the holes are

So that why this is correct...

> Qt apps typically don't look or behave exactly like native apps,

... but this is theoretical

> I'm going to argue that they can.

Yes, of course they can, but to do in reality requires too much effort, so you end up with with the state mentioned in the first part of the quote. (that's the whole point of the framework - to handle that complexity for you, and if the whole huge QT can't do that even though "they can" why do you think a single dev can?)

> At the same time, I've grown fond of Markdown. The idea that all my notes are formatted in a syntax that will essentially last as long as computers exist—plain text—is very reassuring

That's a very common mistake as well. It's true only for very primitive parts of markdown, which is rather limiting for notes, but if you venture into the more complicated extensions/HTML area, then it's not different from any other format - as long as the format codecs work, it's usable. Like, even word doc is plain ugly XML text, so will exist forever?

> rendering the underlying Markdown when the cursor is inside a Markdown-formatted text—was quite challenging.

Indeed, because it's not fit for purpose.

> For example, if the cursor is inside this bold and italicized text it will show as *bold and italicized text*.

So you now have constant layout shifts when you simply move your caret around.