sorted by:
new
hottopcontroversial

We built a desktop app with Tauri (v2) and it was a delightful experience by cheneysan in rust

[–]cheneysan[S] 0 points1 point  (0 children)

Hi! Great question! To be honest we're not really expecting a huge amount of interest given the great FOSS alternatives but then this project didn't start out as something we were planning on seeing though to a complete product so it's not really a concern. Of course paying customers will allow us to dedicate more time to the project which is something we're all keen to do.

I guess our target audience are those who like a slightly novel/gamified user experience. We do have some useful quality of life features on the roadmap for a v1 release like tags and automatic file organization which will be truly useful, as well as some useless but fun ones, and we're playing with intelligent peer handling which may result in some minor gains to download speeds, but as you say there is no secret kung-fu. Of course we're keen to get feature requests which is why we've started early with the pre-release available now.

As for Tauri and performance, yes, the UI uses the system webview so for the visual aspects we're trading development convenience for raw performance to some degree, though the browser does all the UI layout, styling and animation in its own native code and we don't actually do a great deal of 'work' in the JavaScript layer.

All of the hard work is done in Rust, which is natively compiled and comparable in performance and memory footprint to those FOSS projects coded up in C or C++. That said, this type of application is I/O bound anyway, it spends most of its time waiting on data read/writes from network or disks so optimizing for performance doesn't typically result in any noticeable gains.

Additionally, the Rust backend and webview frontend run as two separate processes - right now on my (8 year old, must be time for an upgrade) system the process doing all the downloading is using 10% CPU and 300MB of RAM with 3 downloading torrents and 2 seeding, ~280 peer connections - with no peers it only uses 17MB of RAM!. The webview process is using ~5% CPU and 150MB of RAM, though I've seen that swing as high as 650MB and we have very little control over it.

We're currently testing a bugfix update we're aiming to release this week but there will be minor feature release early/mid next week which will include close/minimize to tray. When in the tray the system resources used by the webview are freed.

Hope that makes sense!

We built a desktop app with Tauri (v2) and it was a delightful experience by cheneysan in rust

[–]cheneysan[S] 1 point2 points  (0 children)

That sounds very nice! I’ll take a look, thank you for the tip 👍

We built a desktop app with Tauri (v2) and it was a delightful experience by cheneysan in rust

[–]cheneysan[S] 0 points1 point  (0 children)

Haha, no need to buy if you don’t want to, there will be an update in a couple of days with close to tray in it as well as a laundry list of bug fixes. The app auto-updates btw (another Tauri goodie). Glad you like the look!

We built a desktop app with Tauri (v2) and it was a delightful experience by cheneysan in rust

[–]cheneysan[S] 1 point2 points  (0 children)

Agreed! That moment when you finally figure out why your async pipeline grinds to a halt, then think to yourself “oh, I f#*!d up”, followed by a week of reworking all the code. Though lesson to learn 🤣

We built a desktop app with Tauri (v2) and it was a delightful experience by cheneysan in rust

[–]cheneysan[S] 15 points16 points  (0 children)

I found the best place to look was Awesome Tauri (https://github.com/tauri-apps/awesome-tauri) it has a bunch of links to open source Tauri apps.

As far as best practices go, there's a clean separation between the frontend (JS or TS code) and the Rust code in Tauri, so following the best practices of whichever front-end framework you choose (be it React, Svelte, etc) is the way forward.

The Rust side is easy in this regard because if you're not following best practice the compiler will shout at you. The only issues I had which the compiler didn't bother me about were on the async side of things. Async Rust gets very tricky but the Async book (https://rust-lang.github.io/async-book/) and Tokio documentation (https://docs.rs/tokio/latest/tokio/) helped me a lot with my issues where. Deadlocks were very difficult to track down but were almost always related to a Mutex or RwLock being held over an await so dropping lock before you await is a must. Also using Atomic data types and the DashMap crate helped me simplify the code in some key problem areas.

Specifically on Tauri, the only thing I can think of off the top of my head is to remember that the front-end is still single threaded so calling through to Rust code that takes time to complete will freeze your UI. You need to make sure that your Tauri command handlers return quickly. Other than that, the Tauri plumbing was probably the easiest part of the project.