Stack advice
from Matty_r@programming.dev to rust@programming.dev on 07 May 06:36
https://programming.dev/post/29890406
from Matty_r@programming.dev to rust@programming.dev on 07 May 06:36
https://programming.dev/post/29890406
Hey all, just looking for some advice. I’d like to do a WASM application, just generally like a calendar + notes app. I’d like it to work on mobile and desktop through the browser. It’ll be served through Actix with Diesel for the backend. For the “frontend” I was thinking egui or leptos.
I’d like to avoid any JavaScript, so thought SSR might be the best approach.
Any thoughts/pitfalls? Should I look at something else for the frontend?
Its a lot of working parts for a calendar + notes app, but this will be a testing ground to see if I can get it all going :S
threaded - newest
You will be writing JavaScript. You will not be avoiding JavaScript. WASM is still glued to the DOM with JavaScript, if you are lucky and your idea isn’t that novel you won’t need to write any JavaScript, I guess.
This is so true! Tried “nice crossplatform WASM” multiple times - every time you need a system call, drawing single pixel, networking, or catching input - you just start debugging JS. If the logic is simple, whole code ends up being JS mess with small inclusions of Rust. Very unpleasant experience, even with all the modern frontend code generator tools.
I ended up deciding that making custom bindings instead (edit: mention uniffi here) and building frontend in native (Qt/Kotlin/Swift) ends up being simpler, more pleasant, and the end result is faster and prettier (and no wasm limitations). The downside is having to actually use XCode if you do want iOS app to work (which is quite simple but unpleasant and requires you to have Apple hardware or suffer a lot), but if not and you don’t care for Apple worshipers - it’s pure win.
We have a web-UI of medium complexity in Leptos at $DAYJOB and haven’t written a single line of JavaScript. Occasionally, you need to read the JS documentation on MDN, because the Rust code is generated like the JS, but that’s also why you don’t need to write JS, because there’s a corresponding Rust API.
Really? I thought part of the attraction for WASM was that it could be native code without needing JS. That’s good to know though. Thanks.
Not yet. WASM unfortunately does not have DOM access or the ability to call any native JS functions without glue code.
There are packages that work with wasm_bindgen in Rust that can generate that JS for you, but it’s all still super early.
OK, guess I’ll avoid WASM for now then. Someone else mentioned HTMX and pair that with Leptos, I should be able to get away with no JS.
Egui seems great to me so far, not super experienced with it yet though. I think you can get away with very little js using egui for rendering.
How do you find working with it? Especially the debugging side?
Id just use leptos. There will be a little bit of js to load the WASM but that would be it.
If it’s a performance concern, i think solid-js had better performance than both egui and leptos anyway plus you get some niceties like codemirror (vim bindings), marked.js etc.
Egui is really nice dx wise but you will be restricted to those widgets, immediate mode may not scale as well as signals/{slots, effects}.
If it’s a general dislike of JavaScript, you may want to look at QML.
I personally found QML to have really poor documentation around a lot of the widgets. Leptos is good, but I found SolidJS to have more of what I needed and the performance was good enough that I went without for my own personal stuff. But I also had different needs. I really needed something that could do charts, data tables, and your general GUI stuff as well.
OK, I was hoping to have it usable with JS disabled entirely, but that sounds impossible based on what you and others are saying. At least I can level my expectations somewhat before diving in.
Well you will write 0 js in leptos, however js is used to initialize the WASM.
What is your goal and the reason against JS and maybe I could provide more recommendations.
If it’s a personal choice against Js, leptos will be the best compromise. One could use Axum with minijinja but if you’re not careful about routes etc. performance will be shit.
The end goal is to try and have a web app that is usable on both desktop and mobile, I would use what I learn from this simple app to hopefully get something bigger going.
I have nothing specifically against JS I just was (somewhat ignorantly) hoping I could avoid it altogether. I also don’t like having to double up on defining classes, one for backend and one for frontend. I tried React and it really felt like I was wasting my time redefining stuff that I had already defined in my backend.
In my previous attempt, I basically had 3 definitions. The database definition, the Rust definition, then the frontend (JS).
Yeah, it’s funny because I’ve been doing the same thing with my wife on some personal projects like family wiki and event calendar and things where we wanted a web application that could be used on both desktop and mobile.
Here’s what I found so far, Avoiding JavaScript entirely by using a templating language and a HTTP server like Axum Produces fairly sub-par results if you are hoping for interactivity ( Frequent page reloads mean that you can’t have big sodebars etc.)
Qt/qml are OK, but no mobile.
Leptos is what I was looking at, but in the end TypeScript with solid-js was simpler, more performant and more features (although I absolutely hope to revisit leptos down the line).
What you get with solid is signals/slots for state, server side functions to avoid the need for an api, routing for template management, easy tailwind integration and of course any js you may want (eg full calendar io).
I wouldn’t recommend egui if your focus was web.
Oh, and finally, the other issue with Leptos over Solid is that it’s a bit more work to get into Electron from what I understand. Tauri Does not support Linux, so that’s not really an option for a cross-platform.
As someone who regularly disables JS on websites (or rather refuses to enable it for a lot of websites) I am very glad WASM does not work around that restriction.
I would use leptos for a wasm app, but you would need to figure styling out yourself, cause afaik there aren’t any rellay usable ui frameworks for leptos yet
You could also use htmx for the frontend and render the html entirely on the server, then you wouldn’t need a wasm build. For rendering on the server i like to use leptos’ view! macro. Although if you need heavy interactivity you would probably still need to write at least some js, even when using htmx
I think I’m going to go this route - Leptos + HTMX. I’ll see how far this gets me without any JS. What type of interactivity do you think might require JS? I assume I should be able to do form validation etc without it?
Depending on how powerful you want to make the calendar feature, that might require some amount of javascript. Things like dropdowns with more functionality than the standard select element, or autocomplete inputs, too. Generally anything that has some amount of client-side state, although many of them can easily be done with something like alpinejs or petitevue. Since form validation should be done on the server anyways and the html elements for inputs already have relatively powerful validation built in as well, form validation should not require any js.
OK, that’s fine. Just means I’d need to think more about how stuff is implemented. I’m thinking like input fields for date and time selection etc. Could be an interesting challenge for sure.
Surely its all been done before ha ha
There is yew, which I like, but I think development may have stagnated on the project. There have been a few commits to master within the last week, but no new releases since 2023.
There is dioxus, which I haven’t used, but looks pretty cool and seems like it fills the same niche.