I enjoy it a lot. It’s the first time that I find frontend actually fun.
A lot of the memory management aspects of Rust are bypassed by Leptos, so that doesn’t come up as much as one might think.
And I do find Rust’s type system really helpful for actually portraying the UI state. For example, if you execute a function that can fail, you don’t have to catch some exception and then pass the error message separately into the UI or whatever.
Instead, you get a Result-type from that function, which contains either the data you want to render in the UI or the error information you want to render instead.
So, you can just pass that right through to your rendering code. And then there’s pseudo-HTML inline in the code, where you can do full-blown Rust-pattern-matching to properly handle such a Result-type and simply render the appropriate UI element.
No horrid multi-line ternaries, no uninitialized variables, no separate boolean checks before accessing a variable. You simply know at all times what information is actually available.
What’s also really nice with backend and frontend in the same language, is that you get compile-time-guaranteed compatibility between them, because you can simply use the exact same model types and API route constants.
It is still a relatively young ecosystem, so there are still breaking changes every so often. And well, obviously you won’t find anywhere close to the number of UI component libraries as you can find for JS. So, for an experienced JS dev, it is likely a step back in productivity.
But if you’ve got Rust expertise instead or only backend folks on your team, then I heartily recommend it.
Check out Greg Johnston’s interview with Primeagen. Greg’s just an awesome dude all around. I just hope one day there comes a solution for the large bundle sizes associated with wasm frameworks
How do you find Rust for the frontend?
I enjoy it a lot. It’s the first time that I find frontend actually fun.
A lot of the memory management aspects of Rust are bypassed by Leptos, so that doesn’t come up as much as one might think.
And I do find Rust’s type system really helpful for actually portraying the UI state. For example, if you execute a function that can fail, you don’t have to catch some exception and then pass the error message separately into the UI or whatever.
Instead, you get a
Result-type from that function, which contains either the data you want to render in the UI or the error information you want to render instead.So, you can just pass that right through to your rendering code. And then there’s pseudo-HTML inline in the code, where you can do full-blown Rust-pattern-matching to properly handle such a
Result-type and simply render the appropriate UI element.No horrid multi-line ternaries, no uninitialized variables, no separate boolean checks before accessing a variable. You simply know at all times what information is actually available.
What’s also really nice with backend and frontend in the same language, is that you get compile-time-guaranteed compatibility between them, because you can simply use the exact same model types and API route constants.
It is still a relatively young ecosystem, so there are still breaking changes every so often. And well, obviously you won’t find anywhere close to the number of UI component libraries as you can find for JS. So, for an experienced JS dev, it is likely a step back in productivity.
But if you’ve got Rust expertise instead or only backend folks on your team, then I heartily recommend it.
Check out Greg Johnston’s interview with Primeagen. Greg’s just an awesome dude all around. I just hope one day there comes a solution for the large bundle sizes associated with wasm frameworks