The Slint team has released version 1.0 of its cross-platform GUI toolkit, implemented in Rust and with additional bindings for C++ and JavaScript.
Once known as SixtyFPS, Slint is both fast and small. “Graphical applications built with Slint can run on systems with less than 300 kB of RAM, such as the Raspberry Pi Pico,” says the post introducing this first production version of the library.
DevClass spoke to Slint co-founders Olivier Goffart and Simon Hausmann. These two developers met when working at then-Norwegian company Trolltech, which created the Qt C++ toolkit, before it was acquired by Nokia. Goffart moved to Berlin to create his own company, but both continued to work in the Qt ecosystem. “We had a pretty good idea of what kind of problems people face when they build complex user interfaces for embedded devices or desktops,” said Hausmann. “We also knew that Qt had accumulated a lot of legacy that made the product heavy, partly cumbersome, and in some ways inflexible. We felt like it was time for a new start.”
There was also a conscious decision to move away from C++, even though C++ developers are currently the primary market for Slint. “In 15-20 years it will be difficult to find C++ developers,” said Hausmann. “We wanted to see if it’s possible to build something prepared for the future and not tied to C++.”
Qt has bindings for other languages, but according to Goffart, “all the documentation, everything is always on C++ …. developers can work in many languages and systems languages like C++ are not really the best language for UI. They are good languages to implement the library itself, because it needs to be really fast, but the logic of the application can be in a much higher level language. We wanted to support several programming languages.”
What was it like working in Rust after using C++ for so long? “Rust is quite restrictive in what you can do,” said Goffart. “In C++ we had a lot of freedoms with templates and meta programming, and that makes it possible to do things which are not possible in Rust. Rust forces you into the Rust way, which is in retrospect a good thing because that forces you to keep things simple in some respects.”
Hausmann added that “it helps us to void entire classes or categories of errors that we would have if the code base were in C++ … the build system is something you don’t have to worry about to the degree that you do as a C++ developer. Dangling pointers and the like, you don’t have those any more. So you can spend your time on other things.”
Despite the use of Rust, Hausmann told us that C++ developers will feel at home. “We know how to make first class C++ APIs,” he said. “This is a proper C++ API that C++ developers will feel completely comfortable about.”
The use of Rust brings another benefit: the ability to compile to WebAssembly (Wasm). Hausmann said this is mainly of value for demonstration and prototyping. “The ability to compile our examples and run them in a web browser is a great way to convey the kind of designs you can do.”
This brings up a key point: that Slint has its own declarative language for describing a user interface, conceptually similar to QML (Qt Modelling Language) or Microsoft’s XAML. This enables demos like SlintPad where developers can write Slint design markup language and see it instantly rendered via Wasm. Similarly, there is an extension for Visual Studio Code that provides instant preview of Slint markup.
Hausmann sees the Slint language as fundamental. “This domain-specific language for describing the UI is really the heart of it. Everything is fully typed, you get visual feedback instantly as a developer.”
How does it compare to QML? “We like QML but we thought we could make it better. We want to have a good separation between the logic and the UI … another thing is that we see a lot of people know CSS, so we thought we should also try to get as close as possible to CSS.”
Slint draws its own widgets rather than relying on native controls, something which is completely necessary in the embedded world where native controls might not exist, but which can make it look different than native applications on desktop operating systems like Windows and macOS.
We asked the Slint team about the challenges of finding the right business model for this open source project. “We like open source, we come from an open source background. I started programming because of open source,” said Goffart. “We also like the model which Qt still has, where you have open source but if you want to do proprietary software, then you need to pay.
“On the other hand, we know that there are some target platforms where we cannot compete. For example, everything that is web or mobile, the alternative is for free, nobody is going to pay for our work because there are so many. On desktop there are also many toolkits starting with Electron, Qt, Flutter and many others.” Because of this, Slint has a free “Ambassador” license which “is fairly permissive and should fit most use cases,” Goffart said, though it does require users to agree that their product could be used for marketing Slint.
This means that the main commercial market for Slint is embedded devices, where “for confidentiality [customers] would not want to take the ambassador license,” said Goffart.
Slint is also in a better state of readiness for embedded than it is for desktop use. For embedded, “we are lightweight compared to alternatives,” said Goffart, whereas “we still have a long way to go, to get full integration into the desktop.”