Best way to create a front end (in any language) that calls a Rust library?

I'm creating a new cryptocurrency so for the sake of building the best possible backend, that is both secure and high-performance, I feel I need to use Rust. (Check out this blog post advertising Rust btw :))

But I'd like to build a front end, and I'm not sure Rust is ready for that yet. Ideally using something that can be easily made cross-platform(mobile and/or desktop), use a WYSIWYG interface and the two can communicate with each other ideally as a library call to the Rust but a REST API would be fine too, and have a native look and feel.

Any suggestions for the front end technology?

2 Likes

If you want a secure front-end with a minimal number of serious programming errors in shipped code, Rust/WASM is the obvious multi-platform multi-browser choice.

1 Like

This may not fit along your lines of native look and feel or WYSIWYG, but here is some technology that you might want to look into:

Tauri

Tauri is still under development so it may not be suitable for you, but it allows you to create Rust-powered desktop applications using web technologies for the frontend. Instead of using Electron, which is overly resource-intensive, they use their own maintained fork of webview which is super-lightweight.

You can use any web frontend library with Tauri.

Quasar

Quasar is a very complete web GUI framework that can make it easy and fun to make UIs. They have tons of out-of-the-box components for all kinds of GUI elements and they allow you to easily design mobile optimized applications. It is built on VueJS, so you won't write Rust for the front-end design ( unfortunately ) , but it has an integration with Tauri so you are still writing your performance logic in Rust.

Even though it is JavaScript for the frontend, which I would prefer to avoid, I can't argue against the value of all of the quality components that the framework provides and their first-class developer experience.


One of Tauri's ultimate focuses is on security so that fits well with designing a cryptocurrency. I have not personally used Tauri before, but I use Quasar for my company's website and I love it. It lets me focus on my logic while it handles all of the fancy GUI stuff that people have come to expect nowadays.

Tauri doesn't compile for Anroid or iOS yet but it is coming soon according to the README.

Anyway, may not be what you are looking for, but its something I've had my eye on for a bit so I thought I'd throw it out there. :wink:

7 Likes

Very nice recommendations.

After much searching, nothing quite like what I want to make seems to exist, have to make a trade-off... I will definitely consider those, particularly Tauri. Other than WYSIWYG and the not being quite done thing, seems about perfect. Frankly mobile would be slightly better than desktop.. but either one is about equally important and this would get there. Thanks zicklag.

This looks kind of nice for electron, not WYSIWYG but fairly easy:
http://photonkit.com/

1 Like

I've built this library to do rust front-end web-framework using html/css https://github.com/ivanceras/sauron . You can then wrap the app with webview or tauri to have a stand-alone app.

3 Likes

Another option, similar to sauron, that would let you write the HTML-based GUI in Rust and wrap it with Tauri: yew.

2 Likes

Sauron and Yew both look very nice.. particularly Yew with it's better performance and doesn't seem like it requires nightly. Love that Sauron is going after something Elm like, haven't played with it much but I love the Elm project and it's certainly not like Sauron is slow...

1 Like

Wow, it appears Yew benchmark is cheating, doesn't run the entire test (have not verified myself).. meaning it's actually about 50x slower than that benchmark:

1 Like

Are you sure you linked to the right Quasar framework? That one looks amazing and seems like the one you are talking about... but can't figure out how to integrate it with Tauri? The other one(https://github.com/anowell/quasar) looks like it is built with Rust but a little too early for use.

Or is it just that Tauri can work with multiple frontends, including Quasar? If there is a way to do that.. definitely want to give that a shot. Thanks zicklag.

1 Like

Yep that's the right one! Yes, Tauri can work with any JavaScript frontend, including Quasar ( quasar.dev ) .

Right now I think the Tauri documentation is still in-progress, but you can check the wiki and their website ( which I haven't checked out yet ). This page seems to indicate that you can use Quasar mostly like you do normally, with quasar dev on the commandline. I haven't tested it yet so I can't speak to the exact workflow, but you should be able to get help on their Discord server.

Tell me if you try it and how it went. I've been dying to try it out, because I love Quasar and Rust so much, but I haven't found the time yet. :slight_smile:

1 Like

Our plan right now is to most likely use Quasar (possibly Svelte? possibly Elm?).

I really want Tauri but they themselves seem to be saying it's not ready yet by calling it alpha.. so think we're going with Electron for desktop, Cordova for mobile. Both can bridge Rust code and modern front ends. Then we'll replace with Tauri as soon as it's ready.

1 Like

At the risk of taking things slightly off-topic, can I ask how do folks structure these systems architecturally?

I had similar ideas(/dreams/hopes?) in using yew but my naive attempts to explore this space involved copying one of the yew starter templates and adding my existing project as a dependency. This failed pretty much immediately because my existing project has dependencies (specifically net2) that cannot build to wasm. While there are potentially trivial workarounds to this specific problem, in the more general sense I'd be a bit nervous about this as I don't know what other dependencies might not be able to build now or in the future (e.g. system libraries like winapi).

The immediate thoughts was trying to publish a REST API in the lib and communicating via that, but this was not particularly appealing to me as it seemed like a potentially large amount of overhead (in terms of development time, although it seems like performance has the potential to be a future issue for heavier UI). That said, my experience with cross-language GUI stuff is limited (and basically always has involved pre-made bindings). Would having to do this be par for the course or what other options are available am I missing/not understanding?

I think that using Tauri would be a good solution for native apps because you get to fully use whatever web frontend technology you want, such as Vue, Quasar, React, Yew, etc., but you still get to write your app logic in Rust. Tauri gives you a way to call your Rust code from your frontend without having to use a REST API. I don't know 100% what it looks like to call the Rust code from the JavaScript/WASM frontend so I would have to look at that, but I think the point is to make it simple to do. This wouldn't be the same as trying to include your project as a Yew dependency because your Rust would still get compiled to native machine code and would stay separate from your GUI.

With that setup I don't think that performance should be a problem.


Otherwise there are Rust projects that are bindings to things like Qt or gTK which I think would be other good candidates for native GUIs, but I haven't looked into them.

I spent some time playing around with Tauri and it does NOT appear to be case appears that it builds your rust app to native and calls into it from a javascript/WASM frontend. Similar to sauron and yew, it builds to wasm, and also similarly if your app cannot build to wasm, then it's not a good suit.

Nevertheless, it seems like a very cool framework and interested to see where it goes.

1 Like

I think you should contact them ( probably on their discord ) to make sure. I'm pretty sure that that is the whole point of Tauri to compile your Rust to native code. I don't think they are just wanting you to compile your Rust app to WASM. Also, they are saying that it will be possible to bind Tauri to languages other than Rust, such as Python, and that would not make half as much sense if you had to compile everything to WASM.

I'll look into it if I can.


The README says:

The default binding to the underlying webview library currently uses Rust, but other languages like Golang or Python (and many others) are possible (and only a PR away).

Webview is what runs the frontend and it is written in C/C++ with bindings to Rust.

This readme shows how you use rust to eval JavaScript through webview and you use an external object in JavaScript to call exposed Rust:

1 Like

I'll preface this by saying I don't have a lot of experience in this area so on my end it is a lot of fumbling in the dark, and what I say should be taken with a grain of salt!

I did ask on their discord while I was experimenting, and got what I believe was confirmation of the above (basically was told if I can't bundle to wasm then I'm going to face 'significant hurdles'). But now that I look back, perhaps that was specific to the yew example that I was directed to

As far as I could tell, this example builts the yew todomvc to wasm and then bundled it into a webview container. Which seems quite similar to (rust-webview-todomvc-yew and sauron projects) and for me, has the same issues as I outlined. It wasn't clear to me what would be necessary to call into natively compiled rust library (and after talking I concluded - maybe incorrectly - that it was not possible/feasible)

What you say about the implications of other languages binding to rust, that was also a source of some confusion to me. I was also pointed in this direction for a project that apparently is the most complete example of tying a frontend into rust but haven't been able to make much of it (probably owing to lack of experience).

If you do end up having a look I'd be very interested in hearing about your findings!

One of the Tauri Core devs here. Let me clarify a few things for you guys.

Tauri was originally a part of the Quasar ecosystem. Currently, our Vue and Quasar support is pretty solid as its the framework that we've had a chance to test the most. We have a Vue plugin that you can use and you can find that here. You can use any JavaScript technology with Tauri; you just need to have a bundled JS file and some HTML and you are good to go. This also includes any compile to JS languages/systems such as ClojureScript, Reason, Elm etc.

WASM support in Tauri is experimental but it does work; as someone else pointed out we do have a Yew example. The main reason I say its experimental, is simply because we haven't experimented much with WASM and Tauri just yet. With any other WASM, you would just need to have an HTML/JS intermediate to inject it into the webview and so long as you have that it should work (again in theory).

GuiJS is the most complete Tauri example at this current time but other organizations such as Iota and amethyst are looking into using our technology for their respective projects. Myself and the other devs who work on Tauri are doing it in our spare time. We are looking at potentially pursuing the technology in a full time capacity through other channels. If that happens, progress should pick up speed in regards to getting the technology out of Alpha. For now, we have a mostly solid API in place though we want to stay in Alpha to give ourselves the ability to change it as we add features. There are plans to drive the software out of Alpha sooner rather than later; so don't let that title scare you off.

4 Likes

Thanks for that @tensor-programming. :+1:

Just to be completely clear, you do call native Rust code from a JavaScript ( or potentially WASM ) frontend when using Tauri, correct?

I think that @adante111 was thinking that he couldn't use native Rust for the backend when using Tauri.

Yes, there is an API that you call into which is pure Native Rust. The API exposes features for reading and writing files, accessing the file system, setting the title, calling other binaries, passing around events and commands, and loading assets. The plan is to add more features as we go; multiple windows etc.

As far as having a backend like Rocket or Actix goes, you could use any backend you want to serve data into Tauri or you can use the no-server option which injects the Html/Js/Css directly into the webview. That said, I wouldn't use something as full featured as Rocket or Actix with Tauri. Your GUI app shouldn't need a backend to do its routing.

Tauri itself is written in mostly Rust; the C/C++ layer is just the API that connects to each of the three OS specific webviews; webkit, webkit-gtk and EdgeHtml/IE. We've also got a Node CLI but that isn't really a part of your application; the CLI just sets up your application via code generation. We will also be building a Rust specific CLI in the future.

2 Likes

Thanks for the input and clarification all. Yeah, I guess I misunderstood the tauri yew todomvc example. As far as I could tell this doesn't have a backend (as the logic is simple enough to fold into the frontend), and hence has no example of backend-frontend communication. I mistakenly interpreted that as thinking that was the idiomatic way it was supposed to be done.

Further digging into the guijs code and I can see examples of how to do event listening on the backend side. If anybody knows of any further documentation or code on this or how to make the calls from a yew-rust frontend side please do let me know (I haven't looked too deeply yet)