Thoughts on Rust GUIs

[skysch]

Apps I’ve built with Electron are easier to write, are more colorful, and move between platforms with literally no code changes.

It’s worth noting that the only way to get the same code to move between platforms unchanged is if it doesn’t strictly adhere to ‘native’ style, which some people really covet. Of native style, portability, and ease-of-development, you really only get to pick two, and different people have different priorities about these things.

Which is probably why a “single UI framework for Rust” is a bit of ephemera that will never satisfy everyone.

[CAD97]

This got really rambley so I’m collapsing it. I try to predict the future and wish everyone could have more time to get future work done now.

As a user, I’d note that I prefer a consistent experience between platforms more than a truly native UI.

That said, modal dialogs that really should be handled by the OS, like file selectors, really should be the native one rather than a cross-platform fake, and confirm/cancel placement should match the platform’s.

As a developer, though, I definitely want to have the choice to write this above “semi-native” portable UI, or to drop down and write native OS UIs.

And in predict the future mode:

I think the ideal end position would be:

• A Rust-first GUI platform, with “semi-native” support for tier1 platforms at least, as well as a fall back for platforms that don’t have that work done yet, and
• For as many GUI platforms as possible, a mature and ergonomic(-as-possible) interop story for writing your “native” GUI in its host language, but writing logic in Rust. (Electron is in this category.)

The first would be the “default” choice for a GUI if you just want something that works across tier1 and maybe tier2 platforms, accelerated by fearless concurrency, but the native interop is there if you want to write a native API.

And ideally, in my ideal scenario, the high level Rust semi-native library plays well with the native libraries, so you can compose them to some extent.

Nothing will beat using the native language to write native GUIs, as the library serves the language it was written for (or in some cases, such as Swift, the language also serves the API design). Rust should not try to replace it, as there’s no way to beat GUI APIs in home turf (yet). Where we can stake a claim is in the semi-native zone, where Electron is used.

To that end, an Electron clone-ish based on Rust/WASM powering it, or even just a really good interop story, is a great place to start. Maybe once js-sys and web-sys are done, we can get node-sys and electron-sys? Maybe we can eventually make an Electron variant powered by Servo instead of Chromium? Who knows? I’m done trying to predict the future for now, but I’m watching with interest.

Whatever the solution, though, it should be async-first and multithreading-first to the very core.

[matklad]

file selectors, really should be the native one rather than a cross-platform fake

An interesting counter-point here: IntelliJ has it’s own open-file dialog. I don’t know what is the motivation for this (historical reasons most probably), but the end result works better than native open file dialog, at least for me: IntelliJ knows more about programming-related file types then my OS, and the UI is more keyboard centric (completion & fuzzy search).

Overall, I definitely agree with yours factoring of the problem, though I’d probably bet on Flutter-like architecture for a cross-platform solution, rather then on Electron.

[jjpe]

You have to have some description language for your GUI (extra thing to know, can’t benefit from static typing).

This is not true. A simple counterexample is a Rust macro that expands down to imperative GUI programming. Even if the macro language doesn’t explicitly use type annotations, it still benefits from them by virtue of Rust itself benefiting from them.

[jjpe]

I can’t speak to new components (Android 8.0 and after) but generally speaking, to me Android seems like the exact thing to avoid as inspiration for GUI frameworks. They’ve made a lot of mistakes*, and calling the API and design not nice is a real understatement.

*Perhaps this was to be expected, given the time constraints the Android team was under to get 1.0 out the door. The poor architecture just stuck around afterwards due to inertia. Even after the rendering stack got a major overhaul, the GUI-level APIs (understandably) remained largely the same so that didn’t fix anything either, at least within the confines of this thread.

[jjpe]

The problem with electron is performance. Most electron apps straight up suck in that regard: Ever tried using slack? The Atom editor with a few plugins? They tend to suck up gigabytes of memory while doing nothing in particular, and are a real drain to CPU resources and battery life when they are doing something.

No, electron may perhaps be considered a partial prototype of what is needed, but electron’s model verbatim is definitely not the way forward.

[dcarosone]

an Electron clone-ish based on Rust/WASM […] powered by Servo instead of Chromium?

I have been hoping for something like this. A web view renderer for html/css (and ideally only a modern subset) driven from wasm (and maybe even without any JS at all) or linkable as a crate for native rust to take events and manipulate DOM.

[Screwtapello]

I’m still keeping my eye on the web-view crate, as a light-weight way to generate a cross-platform UI.

[FloVanGH]

Hello together.

I’ve wrote earlier in this thread. I’m working as (UX) Software Engineer for WPF and Qt (Qml) at Ergosign https://www.ergosign.de. My employer gives us a Friday per month to work on own projects called Focus Time. At this time I’m working with three of my colleagues (one Developer and two UX Designers) at a complete redesign and new development of the g(ui) framework OrbTk from the Redox OS project https://www.redox-os.org/. Our goal is to provide a modern, easy to use, fast and platform independent ui framework. We invest all of our knowledge as UX Developers and UX Designers to reach this goal. From API side our inspirations are Flutter https://flutter.io/ and React https://reactjs.org/.

As first result of our work we’ve released the dces framework as preview on crates.io https://crates.io/crates/dces. DCES is an Entity Component System framework, we are using in OrbTk. It is used to handle the instances and properties of the widgets (controls). You could use DCES also in games / game engines. Feedback is welcome!!!

A preview of OrbTk itself will follow at the end of this year / beginning of the next year.

[dthul]

an Electron clone-ish based on Rust/WASM […] powered by Servo instead of Chromium?

I have been hoping for something like this. A web view renderer for html/css (and ideally only a modern subset) driven from wasm (and maybe even without any JS at all) or linkable as a crate for native rust to take events and manipulate DOM.

That sounds more or less exactly like what Azul is / does: https://github.com/maps4print/azul

[FloVanGH]

The OrbTk changes are now open. Check https://gitlab.redox-os.org/redox-os/orbtk.

[Gee5ive]

I’m not an expert on gui programming by far, but from a pure dev experience point of view, I feel like the write once run anywhere approach (which no ui framework has actually achieved as of yet to my knowledge) should be the overarching goal of any future project for rust (or any language) in 2018. Doesn’t matter if your a cto at a major corp, a single developer working on a MVP for your startup, or a team of devs working on an open source project, the goal is always going to be the same, code and skill reuse.

The closest thing think of is uno for .net https://platform.uno and https://microsoft.github.io/reactxp for typescript. That being said, tradeoffs would have to be made, in the rust community, it seems like performance is always the biggest factor in everything, which is expected and understandable considering the goals of the language, but in this instance, I would expect usability applicability to take precedence over performance alone. That’s not to say that performance shouldn’t matter, but sometimes (most of the time ) good enough is all that’s needed.

All and all, I love the idea of the wasm approach using servo, it seems to be able to meet all of the right goals with the greatest degree of flexibility without sacrificing to much in terms of performance at the same time. Personally, I wouldn’t mind things not being platform native, that’s what theming is for, and designers are easier to come by than good programmers anyhow, that’s the approach that flutter has taken and it seems to be working out just fine.

[DrizztVD]

I feel like the write once run anywhere approach (which no ui framework has actually achieved as of yet to my knowledge) should be the overarching goal of any future project for rust (or any language) in 2018.

I do agree. There is, however, the problem of fragmentation that is a result of legacy code and the insistence of large corporations to be protective over their IP. As such, fragmentation is as much a consequence of protectionist behaviour as it is of technological challenges.

RISC-V is a large step in the right direction for this run-anywhere aspiration. A large part of the fragmentation is due to hardware incompatibilities. x86-64, and ARM. Based on what I can see, there’s a large drive from future-thinkers on RISC-V to overthrow the problem of vendor lock-in and the resultant fragmentation it causes. As such, a project like Libre GPU http://libre-riscv.org/3d_gpu/roadmap/ could be very successful.

Stated otherwise, there could be ‘one ISA to rule them all’, and its large-scale success could solve a lot of the fragmentation problem. Based on what I can see from the RISC-V ecosystem. This is exactly what a whole bunch of vendors are planning on doing.

[H2CO3]

he greatest degree of flexibility without sacrificing to much in terms of performance at the same time. Personally, I wouldn’t mind things not being platform native, that’s what theming is for

As I mentioned earlier in this thread, the problem with a browser-based GUI is not primarily performance, but security.

[DrizztVD]

Furthermore, having to compile half of a browser engine into my app just in order to display a button and an image doesn’t sound terribly attractive from a developer’s point of view. Not to mention the infinitude of security holes that operating a browser engine opens up

A browser engine written entirely within Rust should do 10x better on the security front, conservatively speaking. I have no idea how/when that would happen, but it could?

I would expect usability applicability to take precedence over performance alone. That’s not to say that performance shouldn’t matter, but sometimes (most of the time ) good enough is all that’s needed.

Android JVM as an example.

[sunjay]

A browser engine written entirely within Rust should do 10x better on the security front, conservatively speaking. I have no idea how/when that would happen, but it could?

This exists:

servo/servo

And there’s a Rust GUI framework based off of its rendering engine (early stages of development):

https://azul.rs/

[Gee5ive]

I’m actually about to build a simple desktop app using this crate. I love the ideas behind it. In a perfect world you’d be able to use something like this to write an app for web, mobile, and desktop all at once with a crate like this in rust, but it’s still early, so you never know!

[H2CO3]

A browser engine written entirely within Rust should do 10x better on the security fron

You seem to assume that all browser security problems are memory safety issues. They aren’t. Many of them are inherent in running basically arbitrary e.g. JavaScript from various sources, while others are an unhealthy combination of bad habits of web developers and obscurities in web-related technologies stemming from backward compatibility or misdirected standards. Neither of these are easily mitigated using a memory-safe language.

[DrizztVD]

You seem to assume that all browser security problems are memory safety issues.

You seem to assume that I assume that all browser security problems are memory safety issues. I don’t. Having said that, about half of them are memory related, and most of the more serious issues are memory related. The whole gamut of browser related problems given here https://pentesterlab.com/exercises/web_for_pentester/course should be of little concern for a GUI implementation. Unless you’re suggesting a GUI implementation should somehow be able to solve those problems as well? It should be obvious that the GUI library and webpage building is not the same thing.

[DrizztVD]

The security issues of GUIs would perhaps be something like this https://security.stackexchange.com/questions/97856/can-simply-decompressing-a-jpeg-image-trigger-an-exploit

I’m unaware what other security issues such a library would need to fend off.