Dioxus: one CLI, five renderers, and documentation pinned to 0.7

One verb runs it, and the Rust reload path is the experimental one

With one command, dx serve, and your app is running. Edit your markup and styles and the change lands in milliseconds, because rsx markup and CSS go through the built-in dev server and asset hot reloading. Rust code is a different path. The README scopes dx serve --hotpatch to updating Rust code in real time and calls that flag experimental, and it advertises subsecond hot patching as a feature. The same CLI reaches mobile through a platform flag, dx serve --platform android, which runs the app in an emulator or on device and lets you call directly into JNI and native APIs.

The consequence is that two kinds of edit carry two different risk levels. Markup and style changes go through the supported reload path, and logic changes go through a flag the project itself marks unfinished. Nothing in the README states which Rust edits are safe to hot patch and which force a rebuild, so a developer who assumes every code change is instant learns the boundary from a failed patch rather than from documentation.

The whole example app is one function and one signal

The smallest complete program in this framework is short enough to read in full, and it is the whole mental model:

fn app() -> Element {
    let mut count = use_signal(|| 0);

    rsx! {
        h1 { "High-Five counter: {count}" }
        button { onclick: move |_| count += 1, "Up high!" }
        button { onclick: move |_| count -= 1, "Down low!" }
    }
}

use_signal(|| 0) creates the counter, rsx! builds the tree, and the two onclick closures capture the signal with move so the integer survives re-renders. The count is read back inside the heading as {count}, so the markup and the state are one expression.

The consequence is that what the snippet leaves out is what fills a real application. There are no props, no children, no error path, no async, and no list rendering in thirteen lines. That is an honest way to show that state lives in a signal rather than in a store, and a poor way to price a real component. The numbered example folders in the repository, from 01-app-demos through 10-integrations, are where that difference actually shows up.

Five renderers, and the WGPU one is called experimental

The renderer is picked per target, and the list is longer than most frameworks of this size admit to. Web builds render directly to the DOM using WebAssembly, and a second web path pre-renders with server side rendering and rehydrates on the client. Desktop goes through a webview. There is a liveview renderer and an experimental WGPU based renderer. The README also names embedding Dioxus in Bevy, in WGPU, or running on embedded Linux.

Two consequences follow. The answer to whether Dioxus is WebAssembly depends on the build target: the web renderer is WebAssembly, the desktop path is a webview, and the WGPU path is neither. And the WGPU renderer is labelled experimental in the same sentence that offers it, so choosing it for an embedded device means owning the part of the stack the project has marked as unfinished. The README does not say which renderer is the default, or what it costs to move an application from one to another.

The server half is axum, and your own axum backend stays an option

Server side work is built on axum rather than on a bespoke runtime, and the integration runs deep enough that the workspace carries four crates for it: fullstack, fullstack-core, fullstack-macro, and fullstack-server. Server Functions are the mechanism a client uses to call in. The built-in pieces are named directly: WebSockets, SSE, Streaming, File Upload and Download, Server-Side-Rendering, Forms, Middleware, and Hot-Reload.

The consequence is a clear architectural boundary. If your backend is already axum, the README says you can go fully custom and integrate your existing axum backend, so nothing has to be rewritten. If it is not axum, the server side of every Server Function is coupled to that choice, and the list above is a menu you are choosing from rather than a set of adapters you can swap out. Middleware and Hot-Reload on the server are part of the same arrangement, so the dev server assumptions reach into your backend as well as your UI.

Every docs link ends in 0.7 while 0.8 sits in alpha

The tutorial link, the tour link, and the documentation link all end in /learn/0.7/. The release line says something different: v0.7.10 dated 2026-07-30, then v0.8.0-alpha.1 dated 2026-07-31, with v0.8.0-alpha.0 earlier at 2026-05-19.

The consequence is that the guide you are reading and the version you compile are separated by a decision the project has not made for you. On 0.7.10 the written material matches the code you build. On an 0.8 alpha the same URLs describe an older API surface, and nothing in the repository marks which sections moved. The front page shows the same mismatch in a smaller way: the banner announcing Dioxus 0.7 is present in the README file but commented out inside its HTML, so the page carries no release announcement at all. The repository is not archived and was last pushed on 2026-09-26, so this churn is current rather than historical.

The 50kb figure is a bundle size claim, not a speed claim

Packaging is a second verb, dx bundle, which builds with maximization optimizations. On the web the bundler does .avif generation, .wasm compression, and minification, and two size targets are quoted: web apps under 50kb, and desktop or mobile apps under 5mb. The platforms table repeats the smaller figure, describing a simple hello world at about 50kb and calling that comparable to React.

The consequence is that these are numbers for the smallest thing the framework can produce, and they measure size rather than speed. Nothing in the README measures runtime, and the React comparison is attached to bundle size alone, so a reader looking for a performance answer will not find one here. The levers you actually get are the three documented ones, image format, wasm compression, and minification, applied by the bundler rather than configured by hand. Where your assets come from and how large they are stays your problem, and that is exactly where a 50kb hello world stops telling you anything.

One workspace, about fifty members, and a committed lockfile

The repository is a single Cargo workspace with resolver = "2" and roughly fifty named members under packages/, running from dioxus and core through core-macro, router, html, hooks, web, ssr, desktop, interpreter, liveview, autofmt, devtools, document, the four fullstack crates, generational-box, history, lazy-js-bundle, rsx, signals, stores, native, native-dom, asset-resolver, depinfo, and component-manifest. Two globs are members as well: packages/cli-harnesses/* and a block of packages/playwright-tests/* covering liveview, web, web-routing, web-hash-routing, barebones-template, fullstack, and fullstack-errors. Cargo.lock is committed.

The consequence is that a clone gives you a build of the framework, its CLI, and its browser tests, and adding a crate of your own means editing the workspace member list rather than dropping in a directory. The committed lockfile is what makes the build reproducible, and it also means you inherit the exact dependency set the maintainers chose. Around the workspace sit the standard signals of a project this size: flake.nix with flake.lock for Nix, a .devcontainer directory, a .zed directory, codecov.yml, lychee.toml for link checking, and _typos.toml.

Apache and MIT at the root, but the SDK is community-run

Two license files sit at the repository root, LICENSE-APACHE and LICENSE-MIT, and the project describes itself as community-driven with an active Discord and GitHub community. The funding is named rather than implied: the full-time core team credits FutureWei, Satellite.im, and the GitHub Accelerator program, and states a long term goal of becoming self sustaining by providing paid high quality enterprise tools.

The consequence is a support boundary that is easy to misread. The framework is dual licensed and the core is staffed, but the SDK at dioxus-std is described as community-run, and the crates in the separate dioxus-community GitHub organization are the ones described as receiving free upgrades and support, which places them outside the full-time team's remit. Anyone shipping a product will build on the framework plus a layer of community packages, and the enterprise tools the project wants to sell are not identified anywhere in the README, so what is paid and what is free is not something the repository answers.

Editorial conclusion

Dioxus fits a Rust team that wants one component model across a web target, a desktop webview, and an Android build, and that is willing to treat server side code as axum code. It does not fit a team that needs one documented API across versions, because the guides describe 0.7 and the 0.8 line is alpha, nor a team that needs the layer closest to its product to be first-party, since the SDK is community-run. Before you commit, decide which release line you are targeting and read the 0.7 docs against that choice, confirm the renderer you need is not the experimental WGPU one, and check which axum batteries you actually have to adopt.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes