Why You Shouldn’t Build Your Next App in Rust

In this video, we will explore why programming a UI in Rust is so hard and what are some of the possible solutions if you are looking to build an app in the Rust programming language. 🦀👩‍💻

You see Rust being talked about EVERYWHERE and for good reason. Something that isn't so obvious is how hard it is to create a User Interface (UI) with it.

We will look at how Rust’s unique memory management model and lack of inheritance make it difficult to use traditional object-oriented programming patterns for UI development. We will also see how some Rust frameworks and libraries are trying to overcome these difficulties by using different approaches, such as functional programming, entity-component-systems, immediate mode GUI, and even the DOM.

If you are interested in learning more about Rust and UI programming, this video is for you!

Written Version 📝

LINKS
-----

Twitter 🐦

TikTok 📱

TIMESTAMPS
---
0:00 Why Rust is Loved
0:34 What Makes Rust So Unique?
1:45 How UI Programming (Usually) Works
2:46 How Rust Makes This Hard
4:21 Attempting UI Design with Rust
5:34 How We Are Tackling Rust with UI
6:10 ELM Architecture
7:26 Entity Component Structure
7:58 How We Are Building UI
9:03 What Are Your Thoughts?

[warpdotdev]

Are you using Rust to build UI? 🤔 Let us know!

[CodingWithLewis]

"Imagine having a button that doesn't do anything when you click on it".

This is how my apps work now

[TON-vzpe]

Isn't this a click bait? You didn't explain why we shouldn't use Rust and started explaining all Rust features.

[kirglow]

Lack of inheritance puts no restrictions on how UIs are built. If anything, there's more and more trend towards getting rid of inheritance and OOP in general (take react hooks for example). What's challenging in Rust is sharing of mutable data. If 2 components can modify the same view / same data (e.g. clicking menu icon can open a menu, and clicking close button or overlay can close the menu), that means both components need mutable references to the same data, which is disallowed in Rust. This is solved, usually through RefCell or something like it, but it's not as easy as in other languages, though I'd say every UI framework has already come up with good solutions for this and many have decent DX. I don't think the argument about inheritance makes any sense, and criticizing one example of trait implementation doesn't lead to a general conclusion that Rust is too limited for building UIs in any way. Rust doesn't have less capabilities than other languages, but Rust has less magic and fewer ways of shooting yourself in the foot. If you want to understand and fully control the memory and speed of your application, I'd say Rust is actually preferable.

[jaysistar]

Rust does not "lack" object oriented programming. It supports it in almost the same way that C++ does, even with multiple inheiritance. Instead of "extending" a class, you just have another struct as a member. To make the "derived" class act like one of it's members, impl the Deref trait to allow it to be borrowed. This use is what the Fyrox game engine uses. Please don't make it more difficult to find Rust programmers for hire buy discourraging its use. We need more Rust programmers.

[gotbread]

This is ironically a common Trend I see in more complex rust programs. Using owning relations gets prevented by the borrow checker, so people invent this "index into an array" method, to circumvent the borrow checker. Issue is, then you kinda reinvented pointers, only that the rust system does not "know" about them and thus cannot check them. This also means there is no mechanism preventing you from accidentally using the wrong index into the array. This is similar to the memory bugs rust tries to avoid, just one level higher.

[vnldces]

Personally i like the "egui" crate the most. You create UI elements not by creating objects, but by calling functions. Your code sits inside a big closure that is called each frame, therefore your UI is rendered every frame - no need for component management, if you don't want to draw something based on a condition, you just put the drawing call into an `if`.

Anything OOP can do, traits can do better.
The mutability thing is not really a problem in Rust.
Problems with references and the borrow checker? Use smart pointers. Accessing smart pointers is very performant, like accessing references (without optimizations).
Iced is amazing, but still lacks many features.

[hmon]

Sorry for nit pick. ReactJS isn’t a programming language -> 3:19

[stzi]

In the AMIGA days there also was no object oriented Model for doing GUIs, but AMIGA had GUIs, Windows a long time before Microsoft Windows was a thing. There are C-libs for graphics out there like raylib or OpenGL that also need to update alot of events and have to organize that. With C you need to build your own structures and data organization, because C is a very primitive language. So the big picture could yield from the question: How did they do this with those minimal resources, and how can we transfer this to the Rust-world? Another good sort of information would come from game programmers like for instance Casey Muratori. With the object oriented approach you miss the cache alot. So I think a Module based approach is better, like you are already following. A Module that handles all the drawing in the GUI framework can utilize the CPU cache well better, reducing performance-headaches. There are, frankly better, solutions out there that do not need object orientation at all. So it is definitively doable.

[naczu]

I really don't understand why you compare Rust and React. Rust is low level programming language, React is a js library. How do you compare these two ? I have never seen comparison between C and React or C++ and React. Maybe your next video title will be comparison between HTML and Java 🤣

[CramBL]

I've not run into these "big headaches" writing GUIs in Rust. Event handling and message passing is so easy in Rust. My GUIs typically use a tree structure and the root component has an event loop where it receives events and dispatches them to sub-components that handle the events that they can handle in their event loops. No need for interior-mutability.

[hakuna_matata_hakuna]

More content like this please, getting fireship vibes here nice balance of educational and fun

[CritterPop]

Why don’t you guys open source your GUI

[Christobanistan]

Traits are interfaces. Rc, Arc, and RefCell exist. If you can't figure out how to make a UI with those tools, you suck at Rust.

There are tons of Rust UI libs. The way you hide the complexity is by just keeping it inside the library.

[thfsilvab]

I didn't quite catch the relationship between hierarchy in OOP, the component tree (a.k.a. tree data structure), and the lack of inheritance in Rust. It's completely possible to build a tree structure in Rust, just like your example for React or how it's done in Angular. If the lack of a common type is the problem, you can use "dyn Component" which should work as a common trait for all components. I'd appreciate if you could elaborate a bit on this, because the way it's explained in the video might misinform people.

[Alex-hrdf]

I agree on everything in this video. Building GUI with Rust frameworks/tools is over ambitious. Perhaps it's too early for that. I separate FE from BE. I use Go/Rust for BE and React/Flutter for FE - the best so far IMO.

[tacorevenge]

As a mathematician I come from c++, python (ML and DL) . Love rust just because ML and DL will need to be productionised at some point.

[codetothemoon]

Fantastic video. I’m not sure I fully followed everything, but I think that’s mostly on me. Do you think the issues you raise are those that UI developers have to contend with or just framework developers? I feel like procedural macros fill in some of the gap left by the lack of inheritance

[JReuben]

I had amazing experience building UI PoCs in Rust
- Ratatui for TUIs
- Leptos for WASM webdev
- bevy for ECS WGPU