Why Arboretum Chose Tauri

This was originally shared as a post on /r/rust on 2025-02-04. Click here to read the original post and its comments.

TLDR: Despite its shortcomings, Tauri is the best option for desktop app development that Rust has today. It lets you use Rust where it matters while providing the tools to escape its limitations and use proven web technologies when necessary.

As a frequent browser of r/rust I spend a lot of time reading about one of r/rust's favourite subjects, Rust GUI frameworks. Over the last year I've been putting all of that reading into practice with Arboretum, a local-first PKMS app that I built with Rust and Tauri. It's been an experience full of ups and downs that I hope will be helpful to Rust enthusiasts looking to develop their own desktop applications. If that’s you, read on.

Why I chose Tauri

With Arboretum, I had a very specific look in mind that I wanted to achieve, one that I wasn't confident any of the native Rust GUI options like Iced, Slint, or egui would be capable of. This may well be untrue, but it's certainly not something that any of them advertise on their websites or in their examples.

Starting from this assumption, I focused on mature UI solutions I could easily integrate with Rust.

My first attempt at building a desktop GUI in Rust was with flutter_rust_bridge, almost two years ago now. It seemed like a great choice at the time, Canonical had recently embraced Flutter for Ubuntu app development and after testing it out I quickly fell in love with Flutter as an alternative to HTML and CSS (A purpose built app framework has a better development experience than a glorified markup language pretending to be one — shocking, I know).

The initial excitement faded as I dug into the one thing that matters most in a note-taking app: text editing. I didn't have much interest in building my own WYSIWYG editor from scratch and the existing open source solutions for Flutter either performed poorly, didn't provide expected platform integrations (standard hotkeys, IME integration, etc.), or were very early in development with unstable APIs.

This would quickly prove to be the most important requirement for any framework that I selected for Arboretum and a disqualifying one for Flutter, leading me to look for alternatives. With continued investment in essential features of Flutter for Desktop in question, I certainly don't have any regrets about leaving it behind (even though the AppFlowy team has made impressive progress on their open source editor).

Despite its shortcomings on desktop and with rich-text, I still think Flutter is a great option for Rust GUI apps. It would be my first choice for any mobile-only Rust application and can still deliver a great experience for simple desktop apps.

With Flutter off the table, I was faced with returning to HTML and CSS. I tried out Dioxus, Tauri with Leptos, and Tauri with Yew. When considering that the text editor would need to be JS-based, none of the Rust-first options offered an interop story that was compelling enough to justify splitting the frontend between two languages. In the end, combining Tauri and old reliable React was the only path forward which met all of my criteria, though not without its fair share of difficulties.

Where Tauri falls short

Tauri's usage of the native OS browser is its primary differentiator, but it can also be a weakness when compared to (non-Rust) alternatives. The inconsistency between platform browsers can be painful and not only in the obvious ways. Beyond the rendering inconsistencies and gaps in feature availability, there are huge differences in some web APIs’ behaviour that I was blissfully unaware of a year ago. In the time since, I've spent far longer than I'd care to admit learning about URL parsing inconsistencies between Safari and Webview2. Performance is also inconsistent between the different browsers. Arboretum hasn't launched on Linux and probably won't in the immediate future due to performance issues with the Linux browser engine.

The browser engines themselves aren't the only difference that I’ve needed to consider working with Tauri: there's also the framework's integration with them through wry, which can have subtle differences between platforms due to their distinct APIs. The Tauri team has done a great job at abstracting away the differences for the most part, but there are still sharp edges that are almost impossible to anticipate. In particular, I've been burned by my custom initialization scripts working just fine in iframes on Windows, but not running at all on other platforms (this has since been fixed, though it hasn't landed in a Tauri release yet).

These bugs are rare, but they're incredibly frustrating to discover and debug. Even more so when, from my perspective, I gain little from Tauri's shared browser approach. The current build of Arboretum is, due to other bad decisions wholly unrelated to Tauri, 381 MB on macOS. Basically the same as any Electron app. At this point, I've already lost the users who care about every byte on their drive. I would absolutely add another 200 MB to the bundle if it meant that I could offer my users a more consistent experience with a single browser to target.

Why you should probably choose Tauri anyway

As cathartic as it may be to list a bunch of problems, it doesn’t actually count as the advice I promised you at the beginning. So let me explain how, despite everything above, Tauri’s strengths outweigh its weaknesses to make it your best option for desktop app development in Rust.

For all that I might complain about cross-browser inconsistencies, they’re hardly a Tauri problem — they’re simply the nature of targeting web browsers. While Arboretum is and always will be a desktop-first experience, I do have ambitions to bring it to the web eventually (once I can get rid of Python). Using Tauri has "shifted-left" all of these problems to the earliest stages of development, which is a short term inconvenience but also an excellent forcing function to ensure that support for alternative browsers is accounted for at every stage of the development process.

There’s also hope for more options in the (somewhat) near future. The Chromium Embedded Framework is exploring the possibility of shared installation and API versioning, which could make it a viable option for integration with wry and by extension, Tauri. Perhaps more exciting for the Rust community, Servo is also being explored as an alternative web render for Tauri, though it's not clear how far that has moved since the blog post a year ago (Verso seems to be the project driving forward Servo embed-ability at the moment).

Even if you never intend to ship your own app on the web, its ecosystem is the largest by an order of magnitude. It's difficult to overstate the benefits of this scale for the development of your application. Building rich text editing experiences is really hard, and no platform other than the web has multiple fully featured rich text editing solutions (there are still rough edges in Arboretum's editor that I'm trying to work out, even with a strong foundation to build on). No matter what you intend to do, you’re more likely to find the building blocks for it on npm than on any other platform.

In my experience with Arboretum, the balance Tauri strikes between the Rust and Javascript ecosystem is an extremely effective one for application development. In Rust I can drop in an excellent search engine; on the JS side I can add an unstyled and accessible action menu. Managing this balance keeps the focus on developing the unique ideas that Arboretum brings to the table, which I would otherwise spend reinventing the wheel.

That's not to say you shouldn't reinvent the wheel, if your passion is wheel design. I'm sure many better wheels are possible – and I look forward to trying them out some day – but when it comes to choosing a Rust GUI framework in 2025, you need to decide where your priorities lie.

Something resembling a conclusion

There are many promising Rust GUI options and they need adoption to develop further. As a community, we should strive to support them, but equally we need to be honest and direct with newcomers. Pure Rust GUI solutions aren't ready for wide adoption and aren't the right way to learn the language. Immediate-mode GUIs in particular are full of footguns and might reinforce the idea that Rust is only for systems programming to someone experimenting with it for the first time.

This all may seem obvious. I spent a while wondering if it was even worth writing, but I've also spent a while reading posts on r/rust about the state of the GUI ecosystem. These are often questions from new programmers, who are usually given many different options with little discussion about the pros and cons of each or links to areweguiyet.com, which doesn't provide any practical advice to help users make a selection.

If you're one of those people, either looking to get started with Rust or an experienced Rust programmer looking to dip your toes into the GUI scene, here's my advice. Try out all of the different frameworks I've mentioned (I've listed them again below for convenience), play around with them, and try to decide if they're right for you. If you have any doubts or find yourself running into problems that the framework doesn't have clear solutions for, use Tauri. It's hard to just say that without a whole bundle of qualifiers, but hopefully the wall of text above has covered those better than I could here. The bottom line is this: Tauri is the best Rust GUI solution that exists for developing desktop apps today because it lets Rust do the things that it is good at while providing the escape hatches you need to remain unburdened by the parts of the ecosystem that aren't ready.

Referenced Rust GUI frameworks/solutions, in no particular order:

• Tauri: What most of this post was about. A Rust Application framework similar to Electron which uses the OS browser engine. It has a clear backend/frontend separation that supports both Rust based frontend-frameworks like Yew and Leptos as well as standard web solutions like React and Vue.
• Iced: Elm-inspired Rust GUI library. It's used in the COSMIC Linux desktop environment.
• Slint: Rust GUI/application framework which uses a custom language for defining the UI. It can only be used under either the GPL 3 or a non-standard Slint License. - Web Demo
• Dioxus: Rust GUI/Application framework which supports Web, Full stack, Desktop and Mobile applications using wry, the same browser integration that Tauri uses. Unlike Tauri, it doesn't have a backend frontend split. Everything is the same Rust codebase. - Showcase page with some Web Examples at the bottom
• egui/eframe: egui is an immediate-mode GUI library, eframe is its accompanying app framework. In my opinion, it tends to only be simple for simple apps and quickly becomes unmanageable as the needs of the application grow. - Web Demo
• flutter_rust_bridge: CLI for generating bindings between Rust and Dart code for use in Flutter applications. Not really a GUI framework in its own right, just a method for easily embedding Rust code in Flutter apps.

Wow, that was a lot more than I had originally intended to write. There's still more I'd like to touch on about Dioxus, distribution, mixing Rust and JS in the frontend with Tauri, accessibility, state management, and testing, but this is already way too long. If you'd like to judge for yourself if I know what I'm talking about or just want to see what a Tauri application looks like in practice, consider trying out Arboretum! Either way, I appreciate you reaching the end! If you scrolled down here looking for the TLDR, it's back at the top 👆.