Embracing DSLs in UI Development: Why Learning Slint Isn’t Harder Than Mastering an API

[ogoffart]

Discussion thread for the blog post https://slint.dev/blog/domain-specific-language-vs-imperative-for-ui

[theopfr]

Interesting read! (there is a closing "}" missing in the first Code block I think?)

[ogoffart]

Well spotted, thanks! I've fixed it.

[WiktorPrzetacznik]

The AI image looks very off

[silentbat]

For me the only thing that holds me back using DSLs is that I cannot "look at the source" as easily as I can with an (open) api. So if I am not sure whether something I wrote will do the thing I want - depending on how the DSL, documentation, lsp etc. is done - I cannot look deeper into it.

But if it is done well and there is small to noen ambiguity a DSL is a very nice thing indeed for all the nice reasons you already mentioned in the blog post.

[ogoffart]

That is a good point.
In the case of Slint, the slint-lsp already provide navigation within the Slint code. But yes, this is missing for the interface between rust and slint. Although it could be possible to improve things if proc_macro::Span could be created for external files.

[renlite]

1. Slint DSL is compiled/transpiled to Rust and then
2. Rust compiled to native.

An option to write components/widgets in Rust (API) would offer a choice to use the preferred direction and you can look under the hood to know what happens.
After step 1) the Slint code should be available as Rust code and could be used to write own widgets and use the FW API (Render-Tree) to create the UI in Rust. I know this would work only one way "Slint -> Rust" and has the drawback that you would loose the possibility to switch to an other language (C++, ...). And you would loose the fast and light interpreted preview of Slint and code separation but you would write only in one programming language.
In this case there should be at least a getting started tutorial for creating own components and handle callbacks only in Rust. There are ways to write simple wrappers that UI coding feels like writing code in declarative style. (e.g. https://www.gpui.rs/)

Kotlin Compose Multiplatform uses KotlinLang (no DSL) for compositon of the Render-Tree. IMO it is an declarative style in KotlinLang of functions annotated with "@Composeable". https://medium.com/@itsuki.enjoy/android-kotlin-jetpack-compose-dropdown-selectable-list-menu-b7ad86ba6a5a
The compose (pre)compiler adds coding to the @Composeable blocks so it is not actual an DSL but you need an compiler/transpiler that it works. https://medium.com/androiddevelopers/under-the-hood-of-jetpack-compose-part-2-of-2-37b2c20c6cdd
Could you write a comparison with "Compose Multiplatform" on slint.dev?

[ogoffart]

In Slint, we decided that the "Rust" API would stay private API for now. That's because there is no 1:1 transformation to the runtime data-structure as the compiler will do some transformations. And also because the Rust API is not stable and we want to be able to change it while keeping compatibility.

It is indeed possible to write declarative looking code in Kotlin, Dart, and even Rust or C++, but that would still be mixing code and UI and make it hard for tool to preview and edit.

[xiaguangbo]

slint can support zed extensions?

[ogoffart]

Yes: https://github.com/slint-ui/slint/blob/master/editors/README.md#zed