ogoffart

That’s what we’re trying to do with Slint (I work on it): a declarative, reactive UI like React, with the logic in Rust, C++, JS or Python. It needs no browser engine, so it uses a fraction of Electron’s memory.

> Either it's a rust library or it's not.

It is one. Your app is a Rust program that depends on a crate. The UI compiles to Rust code, and we also have the `slint!` proc macro.

> there's always some edge case logic that needs a full programming language

Right, and that language is Rust. The DSL only describes the GUI. You operate it from Rust.

> Why was using js like qt quick not good enough?

QML was the inspiration. I worked on Qt and wrote QML bindings for Rust before (qmetaobject-rs). Slint is a new take on it, compiled ahead of time, no GC, strongly typed.

But they even can. (royalty-free license)

(Slint author here) Slint is written in Rust, and Rust API is at its core. That's not changing. What's wrong with the DSL? the UI is described in the DSL, the application logic in Rust. I wrote about why here: https://slint.dev/blog/domain-specific-language-vs-imperativ...

What gave you the impression we're moving away from Rust?

It depends on what you're building. If your app is free software, a GPL library is no problem at all. (and your own code can even stay MIT or Apache.)

It "cannot be considered" only for proprietary apps.

Slint is under multiple license, including the open-source GPL and a royalty free license. What specifically bothers you about the licensing? (I work on Slint, genuinely curious)

Slint is an open source, free software. The whole framework is on GitHub. A rug pull can't take back what's already released, and one could always fork if needed.

Btw, a rug pull can happen under even the most permissive licenses. As we've seen in the past with some project changing license or direction. That's more or less already happened with GPUI when Zed refocused development on its own needs rather than other GPUI users resulting in several forks.

I'm working on Slint. It is a declarative UI language that compiles to native code, the application logic can be written in Rust, C++, TS or Python, and it is cross platform, including mobile. Has accessibility through AccessKit. A live preview, so iterating on the UI doesn't mean recompiling Rust.

Compared to Electron, there is no browser, so binaries are a much smaller, use less memory, startup is fast. And the attack surface is also much smaller (no XSS)

IMHO Rust isn't a great language for describing UIs because it is too explicit in places that doesn't need to be for coding a UI. Which is why in Slint (another Rust UI framework) we opted for a DSL. The application logic stays in Rust, but the UI is described in a language designed for it.

Your example would look like this:

    export component Hello inherits Rectangle {
        in property <string> text: "World";
        width: 500px; height: 500px;
        background: #505050;
        border-width: 1px; border-color: blue;
        drop-shadow-blur: 15px; drop-shadow-color: #0008;
        VerticalLayout {
            alignment: center; spacing: 12px;
            Text { text: "Hello, \{root.text}!"; font-size: 20px; color: white; horizontal-alignment: center; }
            HorizontalLayout {
                alignment: center; spacing: 8px;
                for c in [#f00, #0f0, #00f, #ff0, #000, #fff]: Rectangle { width: 32px; height: 32px; background: c; }
            }
        }
    }
    

More on why we chose a DSL vs code in Rust: https://slint.dev/blog/domain-specific-language-vs-imperativ...

I have noticed the same on my project.

The agent helps a lot to fix bugs. Just point the agents at the bug reports. They do the reproduction, debugging and fixes. We "just" have to review. (Sometimes ask more details and tell we'd prefer another approach.) This makes bug fixing much faster and automated.

And at the same time, it seems we get less bug reports to our library. I think user just use their agents to code, and agents don't report bugs, they just work it around somehow.

So overall, the open bug count is decreasing. Which somehow feels good.

On the other hand, we get a lot of PR made by other's people agents, which can be a bit overwhelming when it's just a huge code drop. We can't easily review that.

There is also Slint that'd fir perfectly. Others have built game launcher with it as well

Slint ?

There is Slint - https://github.com/slint-ui/slint/

- UI renders natively (without a browser)

- Slint uses a declarative UI that should be intuitive to use for developers / designers / agents.

- Can be interfaced from different languages such as Rust / JS / TS / Python

(disclaimer, I am working for Slint)

Similar story here.

Even though our ovens actually work fine, the problem is a new competitor: OpenOven. Their oven is completely free, and on the Italian forum everyone talks about them. It has even way more buttons than ours (most don't work very well, but the community loves it).

We almost sold to MrBaguette, one of the biggest bakery chains in the world, as they wanted new oven supplier for their next generation of kitchen. Their chef tried our oven and loved it. But in the end they went with the pricier one from Corporate Oven, because some VP thought we were too small and worried we wouldn't supply them in 20 years.

one missing from that list: Slint, which i work on. runs on Linux, Windows, macOS and embedded, with app logic in Rust, C++, Python or JS.

You can use JS but it doesn't ship a browser engine, it renders with its own lightweight toolkit.

If you are looking for something similar but not limited to C++, you can check Slint out: https://github.com/slint-ui/slint/

C++ works, but compared to other languages it's often no longer the most productive choice for UI work. Modern UI code is mostly glue and state management, where fast iteration matters more than squeezing out maximum performance. And when performance does matter, there are also newer, safer languages.

For teams comfortable with C++ or with existing C++ libraries to integrate, it can of course still be a strong choice, just not the preferred one for most current teams.

Qt is still used, but I think part of the reason it is less used is that C++ isn't always the right language anymore for building GUI application.

That’s actually why we're working on Slint (https://slint.dev): It's a cross-platform native UI toolkit where the UI layer is decoupled from the application language, so you can use Rust, JavaScript, Python, etc. for the logic depending on what fits the project better.

We're actually working on a native open source cross-platform UI toolkit called Slint that’s trying to do exactly that. https://slint.dev

> I wish that there was some native alternative to the Web-based everything.

I suggest Slint (https://slint.dev)

There are some desktop apps made with Slint. For example:

- WesAudio has a VST plugin for audio applications: https://slint.dev/success/wesaudio-daw

- LibrePCB 2.0, is migrating their code from Qt to Slint and should soon be released. https://librepcb.org/blog/2025-09-12_preview_of_next_gen_ui/

- krokiet: https://github.com/qarmin/czkawka/blob/master/krokiet/README...

> someone has to make a native cross-platform desktop UI framework that doesn't suck

This is exactly what we're trying to do with Slint (https://github.com/slint-ui/slint ). It’s a native, cross-platform UI framework for desktop and embedded (Rust/C++/Python/JS), with no browser runtime

> So in case of slint, I would check how they solved the text inputs.

Slint uses the NativeActivity by default, but it supports IME by implementing the IME support in Java in the Slint's android backend.

slintpad.com uses the wasm port to run on a browser and is not the same as when using Slint to build a "native" app, especially on mobile.

Slint does support decent text input and IME. Including text selection with the native handle. As a demo for android you can try the demo from https://material.slint.dev/ ("Download APK")

I’m curious what that showstopper bug actually was.

I was really looking forward to this feature, as it would've helped improve Rust <-> C++ interoperability.

Of course Rust can handle those use cases fine (GUIs, web browsers, and game engines).

C++ is still high on the TIOBE index mainly because it is indeed old and used in a lot of legacy systems. For new projects, though, there's less reason to choose C++.

Author of one of these "markup"-based toolkits here. I believe that Rust might not be the best language syntax to express UI. I am curious why you are so strongly against using a DSL.

This topic comes up often, so I wrote a blog post explaining why I think a DSL is a good fit: https://slint.dev/blog/domain-specific-language-vs-imperativ...

Not OP, but some users migrated from Qt to Slint and are happy with it. [https://slint.dev] (I'm one of the Slint developers.)

Slint does require using its DSL to define UIs, but I'd argue it's not really like learning a whole new language. It's not harder than learning the API surface of any other GUI framework.

I actually wrote a blog post about this exact topic, since it's a common question: https://slint.dev/blog/domain-specific-language-vs-imperativ...

Regarding Rust GUI framework, there is also Slint https://slint.dev

(Disclaimer: I'm one of the Slint developers.)