Fancy some GUI programming with Elm?

Hello again @Maldus512. Could you show me what that looks like?

I’ve been digging heavily into Rust since my last reply. Mainly because, while exploring Tauri, I’ve stumbled upon sqlx, a package that enables writing type safe SQL interactions: WOW!

So Rust definitely caught my eye this time.

I’m about one third through a book called zero2prod (I like it). I don’t think it’ll get much into fronted stuff, if at all.

So before this conversation closes, I thought I’d ask you what you had in mind.

I’ve stumbled upon this repo that looks very interesting, although a solo project: GitHub - Heliozoa/elm_rs: Generate Elm type definitions and JSON encoders/decoders from Rust types.

So I’ll probably try to use it at some point, but I’d also like to see how you “abuse” the ˋserdeˋ package to interact with Elm :slight_smile:


Oh, it’s nothing particularly advanced or elegant, but I couldn’t imagine connecting the backend to the frontend without using enums (or union types, or ADTs, depending on the language). I’m a novice in both Rust and Elm (despite knowing it for a while I’ve only ever implemented a couple of apps), but if you are interested the code is here GitHub - HSW-Bologna/laundry-control.

Basically I have one major port for my Elm application (port backendPort : Encode.Value -> Cmd msg) where I send commands for the Rust backend encoded as JSON objects.
On the JS side I simply relay everything I receive on a port to a Tauri channel with the same name (you can see this in laundry-control/index.html at 99c1d93694c5178a2aa992a16ef4e78d736869cc · HSW-Bologna/laundry-control · GitHub).
When Rust receives the message (as a string) I convert it to a custom enum with serde::Deserialize automatically derived, so I just need to convert it from string to my data type (laundry-control/ at 99c1d93694c5178a2aa992a16ef4e78d736869cc · HSW-Bologna/laundry-control · GitHub). I then pipe the now type safe command to a Rust channel to send it to another thread that does the heavy lifting - I’m not sure this part is strictly required as Tauri probably runs on the equivalent of a separate thread anyway, but I still like the approach.

The whole ordeal requires some glue on my side. I know beforehand how serde transforms data into JSON so I use the same approach with Json.Encode and Json.Decode, manually: for example, an enum variant like StartProgram(u16) becomes a JSON object like {"StartProgram": x}. If I ever make a mistake the application panics at runtime (by my own choice), but since messages are still supposed to be known at compile time these errors are rare. This means that the JSON translation is potentially error prone, but I only have to write it in once the message is successfully received by Rust however everything is safe and sound. I haven’t used elm_rs but I guess it makes everything easier.

I found that using a single port and multiple messages is cleaner than having multiple ports with different functions - at least to my taste.

1 Like

Thanks for the valuable feedback @Maldus512.

I’ll surely dig into your app when I get back around to investigateTauri properly (I’m in the weeds of Rust at the moment ^^)

Have a great week!

I refactored my cross-platform dekstop app from using Tauri to Wails, and I regret I hadn’t done it before or even better, started off with Wails.

Tauri is a cool project with a lot of popularity, but in my honest opinion Wails works better in every way. On top of my head it has better features, the app looks better on client machines (app window on Windows, macOS and Linux), and the build process is much nicer than with Tauri. CI/CD was a pain in the ass with Tauri, especially with code signing on macOS and Windows, and nobody in the Tauri project had any idea how to code sign even though there was some faint documentation about it. Even though Wails is a smaller project, it felt way more stable and professional to work with.

I’m not bashing on Tauri, simply trying to save the next person some time by sharing my experience with these two desktop frameworks.
Anyways I’m looking forward to trying out Elm in the near future, it looks very nice to work with :slight_smile:

@lxo9a887, how much would you say your bad experience was related to Rust itself? (Rust being a much harder language to handle)

What do you mean here? Both of them using webviews, I would expect the rendering to be almost identical. Was that not the case for you?

I’m still exploring Elm myself, keep coming back to it because I don’t feel satisfied with other stacks.

There are a few similarities with Rust, such as handling errors with the Result type, null values with the Option/Maybe (both of which I find both lovely)

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.