MudEngine Part 1: Requirements

SSR renders your Dioxus components to HTML on the server and sends a fully-formed page to the browser. The client gets markup immediately instead of waiting for WASM to download, parse, and execute. This improves perceived load time and is required for SEO since crawlers often do not execute JavaScript/WASM.

Dioxus SSR works by running rsx! through a string-based renderer (dioxus-ssr) that walks the virtual DOM and emits HTML. The same component code runs on both server and client — there's no separate template language.

Hydration is the process that makes server-rendered HTML interactive. After the browser receives the SSR HTML, Dioxus loads as WASM in the background, reconstructs its virtual DOM from the existing markup, and attaches event listeners to the already-present DOM nodes — without re-creating or flashing them.

The key constraint: the initial UI rendered by the component on the client must produce the exact same HTML tree as the server rendered. Any mismatch causes Dioxus to discard the server DOM and re-render from scratch. Hooks like use_server_future exist specifically to ensure async data serialized on the server is available synchronously during client-side hydration.

Axum is a Rust web framework built on top of tower and hyper. It uses a handler/service pattern where each route is an async function that extracts typed data from the request and returns a response.

Dioxus Fullstack uses axum internally as its HTTP layer. The server feature adds axum as a dependency and sets up a router that serves your SSR-rendered pages, handles server function POST requests, and serves static assets. You can also extend the axum router with custom middleware, WebSocket handlers, or additional API routes.