HackerTrans
TopNewTrendsCommentsPastAskShowJobs

ogoffart

no profile record

Submissions

Slint and the Node.js Event Loop

slint.dev
1 points·by ogoffart·11 gün önce·0 comments

comments

ogoffart
·8 gün önce·discuss
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.
ogoffart
·19 gün önce·discuss
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.
ogoffart
·geçen ay·discuss
[dead]
ogoffart
·2 ay önce·discuss
If you are looking for something similar but not limited to C++, you can check Slint out: https://github.com/slint-ui/slint/
ogoffart
·5 ay önce·discuss
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.
ogoffart
·5 ay önce·discuss
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.
ogoffart
·5 ay önce·discuss
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
ogoffart
·6 ay önce·discuss
> I wish that there was some native alternative to the Web-based everything.

I suggest Slint (https://slint.dev)
ogoffart
·6 ay önce·discuss
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...
ogoffart
·6 ay önce·discuss
> 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
ogoffart
·7 ay önce·discuss
> 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.
ogoffart
·7 ay önce·discuss
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")
ogoffart
·8 ay önce·discuss
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.
ogoffart
·8 ay önce·discuss
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++.
ogoffart
·8 ay önce·discuss
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...
ogoffart
·9 ay önce·discuss
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.)
ogoffart
·9 ay önce·discuss
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...
ogoffart
·9 ay önce·discuss
Regarding Rust GUI framework, there is also Slint https://slint.dev

(Disclaimer: I'm one of the Slint developers.)
ogoffart
·9 ay önce·discuss
I'm one of the developers of Slint[0], a framework the should be ticking all the boxes for stable, lightweight, and native-style UIs supporting accessibility

[0] https://slint.dev
ogoffart
·9 ay önce·discuss
> Rust, contrary to public claims, often does worse on memory safety than C++, which is a sad state of affairs.

Nonsense! Where do you get that from?

Aslo, you can make easily make linked list, it's just not a recommended data structure.