Balancing Rust's Power with User-Friendly Abstractions: A Comparison of Leptos and JavaScript Frameworks

[revoltez]

Having spent a considerable amount of time in web development, I've observed that frameworks like React (yes, it's a framework), Svelte, and others have done an excellent job of shifting the developer's focus away from mastering the underlying programming language. Instead, these frameworks encourage developers to concentrate on becoming proficient in using the framework itself. This is why many web developers are well-versed in these frameworks, but if you were to ask them to write plain JavaScript, they might find it quite challenging.

When I first encountered Leptos, despite being a Rust enthusiast, my initial impression was how much verbose it was compared to Svelte or React while accomplishing the same tasks.

When web developers hear about Rust and seek an example, they often turn to Leptos or another web framework in Rust. However, i assume they'll tend to have numerous questions when examining the code, unlike their experience with JavaScript frameworks. For instance, they might inquire about the following:

• what is impl => which means you'll need to understand traits
• what is move and what is the * sign and is it necessary? => you'll have to understand borrowing and ownership
• what is that undescore and the two bars |_| => you'll have to understand closures

As you can see, getting started with Leptos requires a significant investment of time in learning Rust. In comparison, when using JavaScript frameworks like Svelte or React, all you need to grasp are basic programming concepts like functions and variable declarations, making the code appear less intimidating. If you follow the framework's conventions, you'll usually be in good shape.

We are already leveraging macros to abstract what's happening beneath the surface, such as view! or #[component] and I propose that we utilize even more macros (until the code resembles JavaScript to some extent 😆)

[gbj]

Thanks for this interesting perspective! I have to say I almost completely disagree, but appreciate the feedback.

From my perspective, the only reason to use this framework is that you prefer writing Rust to JavaScript, or have significant parts of business logic that are written in Rust or use Rust libraries. If anyone ever asks me, I'd always tell them that the best way to learn Rust is by learning Rust; in the same way that I'd say someone should learn JavaScript before learning how to use Svelte (a language that compiles to JavaScript) or React (a JavaScript library), they should learn Rust before learning how to use Leptos (a Rust library).

I don't think it's that surprising that someone who doesn't have experience with Rust and looks at a Rust web framework for the first time would have questions about Rust syntax or semantics.

I hope that this will be a framework that makes it easy for people who enjoy using the Rust programming language or are interested in learning it to make web apps and sites. If we ever live in a world in which people "learn Leptos" rather than "learning Rust" in the way that people now talk about "learning React" (and maybe even "learning Svelte"?) rather than "learning JavaScript," that will have been a failure on my part.

I'm sure not everyone agrees with my opinion on this, and that's fine!

[yamiteru]

Hey I want to give a feedback from a perspective of a web developer (about 8 years od experience) who has never done Rust before.

After one day of fighting with both Rust and Leptos I've resolved most of the problems and now I'm able to code without any interruptions or hiccups.

So I disagree with the OP. It's fairly simple and if someone really wants to use Leptos (like me) they'll learn it quite fast.

[vjau]

I consider myself an intermediate Rust developer.
I wanted to try something new to develop SPAs with a type system more sound that typescript.

But then came the difficulties

Writing a closure with move, getters and setters on signals, made my raise an eyebrow.

Seeing that the boxed value of a signal can be directly accessed but must be wrapped in a closure when you want to add +1 to it, made me a bit confused, but i figured this was probably an habit to get.

Then discovering than to accept a derived signal, you have to use

#[prop(into)]
progress: Signal<i32>

began to make me start to ask myself "do i really want to do all this ceremony when defining the prop of a component ?"

Going to the next paragraph and learning that for the component to accept an optionnal generic prop, you will have to use Box dyn and define the prop like this

#[prop(optional)] progress:
 Option<Box<dyn Fn() -> i32 + Send + Sync>>

just made me close all windows and ragequit on the spot.

This may be useful for some people, but for me, this feels like writing a webapp in C. Can probably be done, but not the first tool i would grab for the job.

[lukexor]

Some context of my own. My team recently migrated from a modest React + PrimeReact + Typescript frontend (around 20k SLOC) and existing Rust http backend to fully Rust with Leptos. It took us about 2 months with 2 engineers

I'm very comfortable with advanced Rust, my team has a more mixed experience and while there were some initial difficulties transitioning away from the flexibility of Typescript, the gains have been huge and well worth the pain of generics, closures, and all the "ceremony".

I have had years of experience with traditional JavaScript frameworks with and without Typescript and I can attest that the time spent chasing down esoteric issues not related to rendering or logic has been as much, if not more time spent wrangling Rust types and pleasing the borrow checker/compiler. So no love lost there.

However, the benefits of shared types between frontend and backend, fearless refactoring, excellent performance (lighthouse scores near 100 vs struggling to get above 70) and the ability to reason about my code through compile-time type abstractions far outweighs both the initial learning hurdles and the ongoing maintenance cost or faster iteration speed of traditional web frameworks. The recent changes to wasm code splitting and hot reloading go a long way to reducing those tradeoffs as well.

I will grant that this situation isn't ideal for every team or company due to team dynamics, market forces for hiring talent, etc but for teams who have engineers who use or want to Rust and are willing to learn, it's worth it imo

[yamiteru]

What's the app? How big is the compiled Rust to WASM?

[lukexor]

It's an operator dashboard for a containerized application management system. The total was size in release is around 3MB. It's also built for optimizing size by default with "z". There are about 8 routes so the wasm splitting should bring down the per-route download quite nicely. It's only slightly more than the equivalent amount of JS which was around 2.5MB. Granted because it was a rewrite/migration we were able to fix a lot of issues and trim some code, but also greatly benefited from Rusts dead-code elimination

[lukexor]

I'll also say that this is in the DoD space where we consider security and safety a high priority. Having an overall lower occurrence of CVEs and backwards breaking semver changes in Rust crates saves so many maintenance hours

[lukexor]

This might be an opinionated take, but I don't consider

shifting the developer's focus away from mastering the underlying programming language

To be a good thing about a framework, and IMHO is why so many pieces of software (especially on the web) are prone to be slow, buggy or vulnerable to security attacks.

Mastering a programming language shouldn't be a requirement to start using a framework, but it shouldn't hide critical details such that developers never learn skills required to build performant and stable software.

[revoltez]

But in order to gain adoption (if we can agree on this goal), you have to make it easy to see quick rewards without learning too much, and i believe this is what made Js rule the web, it takes years to master but its so easy to see quick results. I concede that if the target of leptos are only rust devs then understanding ownership and closures and so on is not a big deal, but for the average JS dev it is.

The idea is that we have a safe language, so shifting the developer's focus from mastering the language isn't going to produce buggy software (at least not like with JS frameworks), and we are already using macros to abstract many things, im just saying do more and abstract a bit more.

[lukexor]

That's certainly a very reasonable goal. Adoption is important for growth and stability. To Greg's point, it's also important (and I'd argue more important than adoption) that Leptos users learn Rust first because Rust is much more strict about what programs it will compile whereas Javascript/Typescript is more lax and defers to runtime errors. This means that adoption may actually be negatively impacted as users struggle with compilation errors they can't reason about and they may inadvertently attribute it to Leptos instead of a it being core to the language and compiler.

Greg and the Leptos community have done incredible work in trying to prevent esoteric compiler errors through example, documentation, and lints/log warnings, but there's a limit to what's possible with Rust today, especially as it relates to WASM and wasm-bindgen. Hopefully the tooling here will keep improving.