Kweb/threepenny for Rust?

  1. Kotlin has kweb:

  2. Haskell has

  3. Does Rust have anything similar ?

The “key idea of interest” here is:

  1. On localhost, websocket is insanely fast, and there’s no noticable latency.

  2. Therefore, when developing GUI apps meant to run locally, we can:

5a. do all business logic “server side”
5b. have client be “very thin”, and do all communication over websocket

In particular, I’m looking for crate that provides:

  1. index.html, client.js

  2. some server that fires up a websocket

  3. all GUI state synchronized bidirectionally over websocket

  4. app logic runs entirely server side (no wasm)

There’s web-view, which I’ve experimented with a bit. If you want websockets, you’ll have to include one of the many implementations (most depend on Tokio/Futures, some do not…)

When I used it, I built the RPC using the web-view invoke callback and eval so I wouldn’t have to start up and manage an HTTP server. It made prototyping incredibly quick.

1 Like

@parasyte : Thanks! web-view is a very interesting crate. Is there a way to create DOM elements in Rust? Either (1) with the web-view crate [I could not find said functions] or (2) some external crate, which builds on the eval function you linked to.

It appears that currently, if I want to build a simple GUI app, it won’t be pure Rust – I’ll have to write some JS fragments for creating the DOM elements + setting up the callbacks, and calling eval on that.

I am wondering if there is something that abstracts this all away, so we can build the app in pure Rust. (again, without wasm)

Yes, there is still some minimal JavaScript required for interacting with the DOM. It is plausible to build a crate that implements the RPC functions for it, which then abstracts all the JS/DOM away from the Rust portion. I don’t know of any existing crates for that.

You might also be interested in azul, which has absolutely no JavaScript!

I started playing round with a similar idea a while ago: I haven’t touched this in a few months, and it definitely needs a lot more work on how to transport UI interaction back to the server; but it was working for the project I prototyped on it.