Single Page Applications using Rust (with WASM) | Hacker News Reader

Single Page Applications using Rust (with WASM)

sheshbabu.com

102 pointsossusermivami28 comments

I felt that yew was pretty verbose so I made a library that's closer to React with hooks.

It's pretty young but solves a lot of ergonomic issues with UI in Rust. It's probably the closest you can get to React-level ergonomics (better in some ways) with Rust.

I like seeing stuff like this. Not because I would use this "in production" or even that I'm a Rust programmer (I'm not), but because the JavaScript hegemony re: supported client-side languages is long overdue for a challenge. I'd love to see any number of languages fully supported in real-life workflows. Sure we have many transpile-to-JS languages already, and I've used some myself, but WASM seems like it closes the gap in some respects for both versatility and performance (though not all problem domains are fully fleshed out yet).

For folks looking to learn rust, I'd highly recommend the educative.io course "Learn Rust from scratch". Rust has a lot of seemingly valid syntaxes for common things that can turn into a rabbit hole e.g. the difference between &str, str, String, and &String. The educative course does a good job working through the thorns and pointing out things that won't work.

First of all, that site (sheshbabu.com) is a great resource, and I have used it a lot.

For my app (triviamaze.com), I ended up trying yew (which is referenced here) and then decided on seed (which is another rust WASM frontend framework which I preferred because it felt like the JSX syntax of yew did not play well with code completion, etc and felt weird to me inside Rust code).

However, for the followup web app (triviarex.com) I ended up using React for the frontend.

The big reason I did this was because React has a lot of tooling and compatibility. If I wanted a different CSS framework or to include one of the many available React components, it was easy. React also supports hot reloading, inbrowser debugging, etc.

What I did do, was use web sockets and Actix actors to manage all the state server side. Basically, all the React frontend code did was send messages to the server, and render the state the server sent back.

This to me felt like playing to the strengths of both languages. On the front-end, I got the flexibility and compatibility of Javascript. On the back end, I got to use all the Rust goodies such as pattern matching and strong typing for managing the state.

That sounds very interesting. Do you have a blog post or other demonstration about it?

Not yet :). I have been thinking about writing up that approach and maybe releasing a library to make it a bit easier.

out of curiosity did you look at dioxis? I was thinking of playing with it for a side project.

https://github.com/DioxusLabs/dioxus

This is a very interesting concept, but what's the actual benefit? From what I've heard, the WASM <-> DOM interactions are quite slow. Rust is also not exactly known for its tiny executables.

Is all the generated WASM worth it in terms of size and performance compared to using Typescript + a regular old front-end framework?

I use it because Rust is a nicer language than Typescript. Even though Typescript is pretty good the JS standard library is rubbish and value based languages are so much easier to use than reference based ones once you get above a certain size.

I can't remember where I read it but someone said reference based languages are kind of like using global variables everywhere.

WASM is not there for individual DOM ops, it's about fast string and data structure processing. That's where the potential improvement is.

I know, but this library compiles Rust to WASM. That suggests that the Rust code is somehow being turned into DOM operations and responses.

It's possible that the compiler is turning all DOM operations into JS and the rest into WASM, but I don't think that's the case here.

Does Rust have the same kind of WASM layers that C# does with Blazor? they seem to have made alot of headway in the .NET community with Blazor in getting a WASM based frontend up and going and it can do...well, just about anything you'd expect an SPA to do.

Ahh JSP files, how I've missed you.

This isn't server-rendered HTML though, this is Rust compiled to WebAssembly loaded from Javascript to run a compiled version of sort-of React.

I'm experimenting with WASM & Rust but with a different framework named wagi [1], there's a great video by Rainer Stropek & Stefan Baumgartner that gives a little introduction to it [0]

[0]: https://www.youtube.com/watch?v=9NDwHBjLlhQ

[1]: https://github.com/deislabs/wagi

I built the user management UI for my LDAP server implementation like that [0]. It's quite nice (I don't like JS), but it's not super stable yet, the 0.18 update of yew changed many things in an incompatible way. It looks way more like react now, with hooks.

[0]: https://github.com/nitnelave/lldap

As someone who adores Rust, built a similar Rust WASM library (Seed), and uses the language regularly for embedded... Rust is the wrong tool for the job. You'll get a cleaner build process, much better performance, and much smaller download by using HTML, CSS, and targeted JS. If doing something heavy, add React etc with a minimal webpack setup.

Svelte is probably a better choice than React nowadays. But these SPA approaches start to become inefficient when a single change to the page involves a massive amount of individual DOM operations (whether derived from a VDOM or not) slowing down rerendering of the page. A WASM-driven approach of just rewriting the HTML for a big chunk of the page in one go and letting the optimized browser code deal with rerendering will likely become optimal for some things.

Svelte was interesting but lacked basic error handling for years so I quit using it. I'm more excited about Vue 3's composition API.

I don't think that Rust is good for a typical web app (for example, a newsfeed with likeable images or an online store). Rust is very low-level language and doesn't have a garbage collector, so development with it will be slower than using JS.

It is good if you need to do maths or process videos, but doesn't give much advantage in processing JSON trees.

Also, I don't think it is necessary to make a SPA for a simple web store. Looks like overengineering to me. If you don't like that pages are reloading then use any library that automagically replaces the page content on link click. You can turn any "classic" server-side rendered site into something that feels like a SPA but without writing any JS code.

Regarding languages that are best for developers' performance, I guess it is Python? Are there languages that allow to solve typical web tasks using less tokens?

So many misconceptions to comment here, I’ll focus on a one:

> Rust is very low-level language and doesn't have a garbage collector, so development with it will be slower than using JS.

Rust doesn’t have to be low level, and you rarely have to manage memory manually despite the lack of a garbage collector. That is actually one of the coolest features Rust provides: the borrow checker.

I’ve often found my development with it is orders of magnitudes faster than when I develop with javascript because of all the cool features Rust provides.

Rust's serde library is great for processing JSON. It automatically serializes/deserializes objects to json, and you can write arbitrary validation methods. It's also extremely fast.

Since rust has a rich type system and generics, it is able to automatically generate all sorts of useful things at compile time. JSON boilerplate is only one example.

Also, the html! macro in the article allows for some nice syntactic sugar, presumably without giving up compile time type checking.

The SPA part feels like overkill, but they're demoing an SPA framework. There are many other rust web service frameworks.

> It is good if you need to do maths or process videos, but doesn't give much advantage in processing JSON trees.

This seems like a great reason to use Rust in the browser, or any other high performance statically typed language. We'd still expect substantial overhead from WASM for a while, but the idea that I can/could natively compile OpenCV to wasm and directly invoke it on the browser seems like a huge win.

Most of these read as coarse/superficial takes that aren’t really informed by the nuances of the real world

What is the time to first render?

I ran the demo site (https://rustmart-yew.netlify.app/) through Lighthouse and got the following results:

    First Contentful Paint    2.3s
    Time to Interactive       2.3s
    Largest Contentful Paint  3.9s
    Cumulative Layout Shift   0.42

All numbers are coloured orange or red, so even Google isn't a fan.

That said, 2*760ms of loading time comes from Google Fonts and Cloudflare's CDN for normalize.min.css. Were those hosted locally instead of on two useless CDNs, the times would probably almost less than a second, which, depressingly, is considered acceptable these days.

WASM typically has very good startup time only because the binary WASM format is so much faster to parse than javascript. See js-framework-benchmark, "Consistently interactive", Yew even beats vanillajs by about 4%.

https://krausest.github.io/js-framework-benchmark/2022/table...

Having said that, I still wouldn't try to use Rust as a React replacement for other reasons. Maybe in a few years.

(2020)

Reply on news.ycombinator.com