Declarative UI, even when implemented coherently within the same langauge like in Flutter and MAUI/Xamarin, so there is no need for an ugly bridge between two worlds, still leads to an unreadable nested hell.

Surprisingly, an imperative GUI creation code is much more easier to read and modify.

Hmm? I've written a fair bit of React, which I assume fits the declarative description, and I never got the impression that it leads to an "unreadable nested hell". You split up your big functions into smaller reusable functions, just like in all other forms of programming.

By the traditions of desktop ui, React is imperative: it's written in a declarative style, but ultimately jsx is just JavaScript.

The best analogue to "declarative" in desktop ui terms would be to have your dom templates in separate files that you don't manipulate the structure of in code.

I honestly have an overall negative view of react, but its method for letting you declare ui structure is really fantastic.

I respectfully disagree. In my experience, Declarative UI is more concise, making development and changes easier. It enhances productivity and allows for a clear separation of concerns, which is beneficial.

Moreover, Declarative UI enables the development of powerful tooling and visual editors. For instance, in Slint, we have an extension that provides live UI preview and code transformation capabilities. We are also actively working on a visual editor that lets users drag and drop widgets. Such capabilities are difficult or impossible to achieve with imperative APIs.

Have you looked at tools such as Delphi, Lazarus etc and the approach used to build GUI components which can be added at build time or at runtime?

If you are interested in talking about this, do let me know.

> We are also actively working on a visual editor that lets users drag and drop widgets. Such capabilities are difficult or impossible to achieve with imperative APIs

I don't think you have ever used an imperative API, have you?

I used VB, then Delphi, then C++ builder and now use Lazarus, and there's no declarative equivalent that is easier or faster than those.

In the examples you mentioned, the UI is typically described in XML or form files (.dfm), which is essentially a declarative approach, and clearly not described in imperative code. Although they may not be intended to be edited by hand, the underlying representation is still declarative in nature.

Agreed, but they were easily achieved with imperative APIs.

This is the statement I was contending:

> We are also actively working on a visual editor that lets users drag and drop widgets. Such capabilities are difficult or impossible to achieve with imperative APIs

Maybe I should have said "there's no declarative-only equivalents that's easier or faster".

As someone else pointed out elsethread, declarative is a subset of imperative, so it's easy to produce an imperative API that consumes machine-generated declarations, but not so easy to use a declarative-only framework to reproduce the ease and speed of Delphi, Lazarus, etc.

Absolutely. I actually prefer a combination of declarative + imperative code similar to how it is in Delphi/Lazarus.

The overall layout of the GUI is designed using a GUI designer and this gets saved as a "form" in a resource file which is loaded at run time and so the actual code does not have a lot of declaration of the GUI but it is read in as a stream from a separate resource file.

However, to this GUI, you can add event handlers, add or remove components at run time etc. All of this is quite clumsily done (IMHO) in frameworks such as flutter.

Do you have plan for wgpu?

We're working on interop, so that when you select Slint's Skia renderer on top of Vulkan or Metal, you can import a wgpu texture if wgpu's Metal or Vulkan adapter was chosen.

What kind of feature set do you need?

I find Slint's font rendering odd and somewhat off-putting. It doesn't look sharp, especially on classic 96 DPI displays. Big text look inconsistently both fuzzy and aliased, and small text has inconsistent intensity. Lack of subpixel rendering and hinting? Rounded corners look sharp in comparison.

That's unfortunately an issue I have seen with several new GUI frameworks over the last years: with High-DPI displays getting more widespread, they tend to push subpixel rendering support down the road.

And understandably so. Du pixel rendering only works on some kinds of displays (many modern displays don't have 3 vertical subpixels per pixel), makes the text look kinda bad due to the wonky colors, really doesn't mesh well with any sort of transparency or even coloured text, it requires that you keep 3 images of each glyph in memory to account for the 3 different sub pixel offsets. It also deeply entangles detailed knowledge of the monitor into your font rendering. You need to re-render everything and update all text any time orientation changes or the window is dragged between monitors. And how the hell do you handle a window stretching across 2 different monitors?

That's not to dismiss subpixel rendering, there is arguably a legibility improvement to trading off color accuracy for horizontal resolution, but it's really no wonder that new frameworks don't bother and that old frameworks are losing the ability to do subpixel rendering. Apple, for example, ripped out subpixel rendering from their frameworks a long time ago (before Retina displays, IIRC).

> Apple, for example, ripped out subpixel rendering from their frameworks a long time ago (before Retina displays, IIRC).

...or at least when Retina displays were still rare and expensive, probably to encourage the adoption.

Probably because just using higher resolution is easier if it's available. Taking advantage of the physical structure of a pixel seems weird to me.

Actually, CRT monitors did "subpixel rendering" automatically when the beams hit the subpixels only partially. So using this technique on LCDs is just trying to emulate a feature that CRTs have built in.

It seems you may have used the FemtoVG backend, which is the default if Qt is not installed and is written in pure Rust. We offer multiple rendering backends, and you may have better results with the Qt or Skia backend, which utilize native font rendering. Additionally, a recent change made improvements to address this issue in our FemtoVG backend: https://github.com/slint-ui/slint/pull/2618

I was primarily looking at demos on the homepage.

> From my perspective, declarative is the best way to describe UI

I agree.

It seems like we have some good solutions for declaratively describing the structure and static appearance of UIs - but beyond things like transition animations, we don't have anything that satisfactorily describes their behaviour. Its a hard problem nut I sometimes wonder why this aspect is under-served by the technologies we have.

While it's not super clear, I think TFA's issue with Slint is the markup file (new syntax, not rust, special tooling/dev environment?), not the declarative bit. After all, they didn't say anything about Iced which is also declarative.

Good point. I don't see the issue with a new syntax either. GUI libraries always come with their own set of large APIs and conventions, so learning a new syntax isn't a big deal. The special tooling and dev environment in Slint are optional. But if you do use them, the Language Server Protocol (LSP) allow to integrate them everywhere and provides handy features like code completion, navigation, and even a live preview.

> The author seems to dismiss declarative UI without explaining why. From my perspective, declarative is the best way to describe UI.

…but I mean, that’s an opinion that is not falsifiable.

If the author disagrees, that’s up to them right?

I agree with the author too; after using xaml, my taste for declarative UIs is limited.

Here’s something that is falsifiable: what is possible using declarative UIs is a strict subset of what is possible using imperative code.

If your declarative config is Turing complete, it’s a DSL; ie. a programming language, not declarative and you’re in “not invented here” land.

If not, the possibilities for it are a subset.

That’s provable; so, if you’re worried that your UI is too complex to easily represent with the existing declarative structure, go for code.

What if you need dynamic layouts? What if your layouts are determined at runtime by dynamically loaded plug-ins? What if your layout needs to generated differently based on themes, or screen sizes? Who knows?

It seems entirely reasonable.

The same goes for other declarative solutions and projects. Eg. Terraform.

I mean, the author literally says a) it’s a trade off for velocity, b) they’re more concerned with performance, c) the implementation in slint is not complete and d) they’re considering writing a very very low level UI library to get what they want.

…maybe, they just want different things to what you’re offering?

It doesn’t mean they’re “wrong”.

I'm not sure where you read "wrong". Did the message get edited?

Those are scare quotes around the word. It's not quoting the parent comment.

No, sorry if my "'s made it appear I was quoting a literal text. What I mean is:

> The author seems to dismiss declarative UI without explaining why.

> From my perspective, declarative is the best way to describe UI.

I think it's pretty clear that the writer here believes that the OP is wrong about slint and declarative UIs.

My point is that OP is not wrong; declarative UI is not the best way of doing UI for all use cases.

It is simply one way of doing UI.

I've worked on complex UI's for creatives based on XAML.

An application like Photoshop is comprised of relatively simple controls (property sheets, etc.) that are combined in complex ways. (Users can add UI elements such as a color picker, dock them, have them floating in space.) Graphical UI builders are fine for the controls, but there has to be some framework for managing the particular set that is on the screen.

Most plugin UIs are extremely simple compared to a DAW, and have the nice property that most of the time they aren't visible.

This is absolutely not the case for many DAW plugins

Which part isn't the case?

Plugins in DAWs are graphically complex, animate, and exhibit plenty of the issues described about DAWs themselves

Yes, but a DAW must do that dozens/hundreds of times more and is on screen for the entire lifetime of the program.

I stand by what I said: most plugins have nowhere near the complexity of a DAW. Some do! (Kontakt/Reakt, and so on) but the vast majority only have a small subset of what the DAW needs to display, and only need to do it for a limited number of channels, and only need to do it rarely.

As a previous Qt user, I never got on the qml train and stayed firmly in widgets land. Declarative uis work well, until they don't because of custom requirements, and then they simply get in the way. They are harder to debug and understand from a code perspective. Not everyone writes apps that target both desktop and mobile.