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.
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 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 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.
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.
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.
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...
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.
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.
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.
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?
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.
Nevertheless, it seems like a very cool framework and interested to see where it goes.
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.
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.
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.
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.
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)