Why Wisp, and When Not
Wisp is a framework for server-rendered sites and apps in Rust. This page names the other frameworks, says how Wisp differs, and says when to pick them instead. Benchmarks measures instructions per request and throughput against Leptos and Dioxus. For other numbers, see Benchmarks and Tokens.
What Each One Is
| What it is | Where your code runs | |
|---|---|---|
| Wisp | A full-stack web framework: file routes, .wisp templates compiled to Rust, form actions, one binary. | On the server. Browser code is optional and plain JavaScript. |
| Axum | A routing and request-handling library built on hyper and tower. You choose templates, forms, sessions and the rest. | On the server. |
| Leptos | A full-stack framework with fine-grained reactivity. Components are Rust and can render in the browser (compiled to WebAssembly), on the server, or on the server and then hydrate. Client code calls server functions like local functions. | Server, and in the browser as WebAssembly. |
| Dioxus | A cross-platform UI framework: web, desktop and mobile from one codebase, with rsx! markup. It has a fullstack mode with server rendering and server functions. | Server, and on the client as WebAssembly, a desktop window or a phone. |
| SvelteKit, Next.js | JavaScript full-stack frameworks with file routes, form handling and server rendering. | Node or an edge runtime, plus the browser. |
How Wisp Is Different
- Server first, the browser optional. Leptos and Dioxus can render on the server too. In Wisp, the server is the only place your Rust runs. A page is HTML from the server, and a form posts to an
#[action]that works with JavaScript off. With JavaScript on, the page updates in place. See Without JavaScript. - File routes and one-file pages. A folder is a URL, and
+page.wispholds the page logic and the markup. Axum has no file routes. Leptos and Dioxus declare routes in Rust code. - Templates compiled to Rust. Markup becomes plain Rust at build time. The browser gets HTML, not a WebAssembly bundle, unless you add your own script.
- Form actions and validation built in.
#[model],#[validate]and<form fields>write inputs and error messages. - One binary, many hosts. The app, styles and static files become one binary, or a build for static hosting, a container, or an edge or serverless host. See Hosting.
- Tools, not services. Wisp imposes no auth or database layer. See Why Wisp.
When to Pick Something Else
-
Axum, if you want a library and your own choices. Examples: a JSON API or a service with no pages, an existing tower stack, or full control of every layer. Wisp can run inside an Axum app through its
towerfeature (Embedding), so you can combine the two. -
Leptos, if you want components written in Rust that run in the browser, with fine-grained reactivity and server functions. You must accept a WebAssembly bundle and
cargo-leptosin the build. Wisp does not run your Rust in the browser. -
Dioxus, if you want one codebase for web, desktop and mobile, or a UI written in Rust across those targets. Wisp makes web pages only.
-
SvelteKit or Next.js, if your team writes JavaScript or TypeScript, you want the npm component ecosystem, or you need a client-heavy app with mature tooling and a large hiring pool. Wisp is Rust only, so a team that does not know Rust pays to learn it.
-
Ecosystem, plainly. You cannot use Svelte components from npm as Wisp components. A
.wispcomponent compiles to Rust on the server, not to Svelte's runtime. Wisp offers these instead:- Mount any React, Vue, Svelte or Preact component, or a web component, as an island (Islands).
- Bundle an npm UI library with your own tool and mount it from a
use:action (Your Own Bundle). - Import plain npm packages in browser code.
- Use
wisp ui addandwisp addrecipes (Tooling). - Share Wisp components as crates (Component Libraries).
Wisp has fewer ready-made pieces than npm, so budget for writing more of your own UI.
-
Anything mature, if you need a long track record. Wisp is new, so it has no long production record. It gets an audit line by line. See Security.
What the Numbers Say
- Benchmarks has Wisp's own measurements against Axum, Actix Web and several JavaScript frameworks, each with its source file, date and machine.
- Tokens has token counts for the same app in Wisp, SvelteKit and Next.js.
- Against Leptos, Dioxus and Actix Web, the instructions per request on the server thread are as follows (the same harness for each, 2026-10-17). Wisp 7,816 on plaintext against 13,859 to 17,187, and 14,467 on fortunes against 43,876 to 470,073 (Benchmarks). Wisp's own counts rose from 2026-10-09: plaintext 5,239 to 7,816 (+49%), JSON 5,055 to 7,520 (+49%), fortunes 12,102 to 14,467 (+20%), because this kernel now runs io_uring, which serves more requests a second at more instructions each; on epoll the same build counts 4,727 on plaintext (Benchmarks). Throughput on the same apps: Wisp is first on plaintext and fortunes. Json at 64 connections is a tie (Wisp 103k requests a second, Dioxus 98k, Actix Web 96k, Leptos 80k), and at 256 connections Actix Web is ahead (87k against 78k).
Is This Page Useful?