[vilunov]

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.

[nicoburns]

> 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).

[thanhnguyen2187]

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"

[vilunov]

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.

[OutOfHere]

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.

[thanhnguyen2187]

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