Using Rust Back End to Serve an SPA | Hacker News Reader

Using Rust Back End to Serve an SPA

nguyenhuythanh.com

Are there any approaches which implement server-side rendered SPAs with Rust? In that case Rust would render the HTML for the first load and server JSON APIs for changes in the SPA. Rendering the HTML is performance-intensive in my experience, using Rust could save up quite some computational resources.

Just serving static files from Rust is not that interesting. It definitely does not sound easier to me, since you are coupling deployment of both BE and FE with no resource optimization to get. Also, since built SPAs are essentially static files, their deployment could be just uploading these files to your CDN.

> Are there any approaches which implement server-side rendered SPAs with Rust? In that case Rust would render the HTML for the first load and server JSON APIs for changes in the SPA

Yes, frameworks like Dioxus (https://github.com/dioxuslabs/dioxus) implement next.js-like "fullstack" SPAs in Rust (the client-side code compiles to WASM).

> Rendering the HTML is performance-intensive in my experience, using Rust could save up quite some computational resources.

The server-side performance is indeed much better than JS alternatives (client-side performance is more or less the same).

I think there is Dioxus and Leptos if you want full-Rust solutions for SPAs. You're right that CDN is another thing that I forgot considering, too. Can you elaborate more on "coupling deployment of both BE and FE with no resource optimization"

How would you compare the two (Dioxus and Leptos)?

The link to Leptos is https://github.com/leptos-rs/leptos for those who need it.

There are some comparisons at their repository

> Dioxus vs Leptos

> Leptos is a library for building fullstack web-apps, similar to SolidJS and SolidStart. The two libraries share similar goals on the web, but have several key differences:

> Reactivity model: Leptos uses signals to drive both reactivity and rendering, while Dioxus uses signals just for reactivity. For managing re-renders, Dioxus uses a highly optimized VirtualDOM to support desktop and mobile architectures. Both Dioxus and Leptos are extremely fast.

> Different scopes: Dioxus provides renderers for web, desktop, mobile, LiveView, and more. We also maintain community libraries and a cross-platform SDK. Leptos has a tighter focus on the fullstack web with features that Dioxus doesn't have like islands, <Form /> components, and other web-specific utilities.

> Different DSLs: Dioxus uses its own custom Rust-like DSL for building UIs while Leptos uses an HTML-like syntax. We chose this to retain compatibility with IDE features like code-folding and syntax highlighting. Generally, Dioxus leans into more "magic" with its DSL including automatic formatting of strings and hot-reloading of simple Rust expressions.

For Go, sadly I don't know any framework in the scope of Rust land's Dioxus/Leptos. You continue to have two choices:

- Either to go down the SSR route (and add HTMX for a more SPA-like experience, and use Templ for HTML templating)

- Or to use Go in the backend and something else for the frontend (NextJS or SvelteKit or React Router, you name it; I went with SvelteKit as it fits my needs well, and seems to be "the most popular niche" frontend framework)

Hope it helps

Usually FE and BE are developed by different people or even teams. It's helpful to decouple release cycles of both components, or else a bug on one component could block deployment of a different component. It's important not to decouple deployments of two components when doing so would save up significant resources, but here decoupling could be achieved by deploying a separate nginx server with static files – this is incredibly cheap, as there is very little static overhead, and performance is comparable.

Dropping the static files on a CDN (eg. cloudflare pages) is pretty straightforward, cheap (and free), and doesn't impact your backend in terms of complexity or performance.

Your usecase can be useful for "local web applications" where you ship a binary and you get a local webui - but at that point, why not just build a Tauri app? (not electron as you would be shipping an extra browser instead of reusing the system one)

Thanks for the suggestion! I did not consider Tauri as it seems to be one machine only, while I'm developing my project to be a web app for multiple local machines.

Tauri will render a window with a web app inside on one machine. But that web app can communicate with a local backend that is either hosted by the same program, or some other program, locally or remotely.

Reply on news.ycombinator.com