One Rust component model targets four application surfaces
Dioxus lets the same component style target the browser, desktop, mobile, and server-rendered web. Its rsx! syntax will look familiar to a React developer, while signals hold state and Rust checks component inputs. HTML and CSS handle presentation. The dx command runs development, reloads assets, and bundles applications. Server functions can place backend work beside the UI code, with Axum available when a project needs direct control of routing or middleware.
Those 4 surfaces do not render in exactly the same way. Web builds use WebAssembly and the DOM. Desktop and mobile normally use a webview, with direct access to Objective-C, JNI, or other native APIs when required. Server rendering can hydrate a browser client. The WGPU renderer and Rust hot patching are explicitly experimental. Dioxus provides one programming model, but a buyer should still choose which renderer, platform APIs, and deployment shape the product will rely on.
What happened when we ran it
Our sandbox installed 128 packages in 73 seconds. The build succeeded in 8 seconds, and tests completed successfully in 354 seconds. We measured commit 33f6d7e in an unprivileged Rust container with 3 CPUs, 12 GB of RAM, and no secrets. The repository occupied 22.3 MB before installation and contained 1,518 files with about 205,388 lines of source. This was a clean result for a framework of this scope.
The source scan found 2 CI workflow files, no Dockerfile, and no top-level tests directory. The successful test command matters more than the directory convention, since Rust projects commonly keep unit tests beside the code. Our run did not build an Android package, sign an iOS app, open a desktop window, deploy server functions, or measure interface performance. It established that the supplied install, build, and test steps worked in the stated Linux environment.
An 8-second build does not install every native SDK
The basic learning path needs Rust and the Dioxus CLI. A simple browser or local desktop project can start without an external account or API key. The CLI supports serving, hot reload, asset handling, and bundling for several targets. Tailwind support is built in but optional, and ordinary CSS libraries remain usable. This is a friendly entry for a Rust developer, particularly when compared with assembling a renderer, router, dev server, and packaging scripts separately.
Moving beyond 1 local target brings the normal platform obligations back. Android needs its SDK, an emulator or device, and release signing. iOS needs Apple's tools and signing. Desktop builds depend on operating-system libraries and the chosen webview. Full-stack deployment needs a server host, TLS, persistence decisions, secrets, and monitoring even though server functions reduce client-server boilerplate. The framework coordinates application code; it does not supply every account, certificate, database, or operating environment.
Main examples follow Git while the latest release is v0.7.10
The README says top-level examples on main target the Git version of Dioxus and its CLI. It then sends people seeking stable examples to the 0.6 branch, even though GitHub's latest release is v0.7.10 and the linked tutorial is for 0.7. That is a small but important documentation snag. Pin the crate and CLI together, then use examples from the matching tag or documentation version instead of assuming main will compile against a published dependency.
Experimental hot patching deserves the same version discipline. Issue 5813 reports that a Bevy example failed to hot patch on Windows with Dioxus 0.7.10 under both stable Rust 1.98.1 and a nightly compiler, although ordinary building worked in part of the report. Issue 4911 separately describes missing Windows system libraries when hot patching outside a Visual Studio Native Tools prompt. Neither report undermines standard hot reload, but both narrow what --hotpatch should promise.
September work is active despite 776 issues and pull requests
GitHub showed 39,051 stars and 776 combined open issues and pull requests when fetched. The last push was September 12, 2026, and same-day pull requests addressed compile-time code generation, a proposed multi-platform test runner, and CLI checking. Release v0.7.10 was published on July 30 with a hot-patching fix. The open count is not a bug count, and the recent issue and pull request activity makes it poor evidence of neglect.
The project is mature enough to ship versioned CLI binaries, keep a large Rust workspace, and pass our 354-second test run. It is still below 1.0, and several attractive features carry experimental labels. That combination calls for a prototype on the exact target mix, not dismissal. Browser-only teams should compare Leptos or Yew. Teams bringing an existing web front end to desktop should compare Tauri. Dioxus makes the most sense when sharing Rust components across 2 or more surfaces will repay the platform-specific work.