cloudparts

Leptos

A full-stack Rust web framework: components compile to WebAssembly for the browser and to a native server binary, with fine-grained signals that update single DOM nodes and server functions that replace a hand-written API.

What it is
WebAssembly
Type
Open source
Made by
Greg Johnston and the Leptos contributors
License
MIT
Facts checked
24 October 2026
Website Source code

What it is

A Leptos app is written entirely in Rust. Components are functions that return a view, written with the JSX-like view! macro, and state lives in signals: let (count, set_count) = signal(0);. A component runs once. It creates the real DOM nodes and sets up effects that depend on the signals they read, so when count changes, only the text node that shows it is updated: there is no virtual DOM to diff and no component re-render. Leptos is closest to SolidJS in JavaScript and Sycamore in Rust.

The browser half is compiled to WebAssembly for the wasm32-unknown-unknown target. A client-side app is built with Trunk and served as a single-page app. A full-stack app is built with cargo-leptos, which compiles the same crate twice: a native server, on Axum or Actix, that renders HTML and streams it to the browser, and a Wasm bundle that hydrates that HTML into a live app. Islands mode goes further and ships Wasm only for components marked #[island]; the guide’s demo shrank from about 274 KB of Wasm to about 24 KB. A #[server] function becomes an HTTP endpoint in the server build and, in the browser build, a stub that serializes the arguments and calls it, so database queries can sit next to the components that use them. The current stable line is 0.8; 0.9 is at its first release candidate.

Why teams pick it

  • Fine-grained updates: a changed signal touches one text node or class, without re-running components or diffing a virtual DOM
  • One language and one type system from database to DOM, with server functions instead of a separately maintained REST API
  • Server rendering with streaming HTML and hydration, and islands mode to ship Wasm only for the interactive parts
  • Runs as a static front end inside Tauri for desktop and mobile apps

Watch out for

  • Still 0.x: each minor release can break APIs, and 0.7 rewrote the framework’s internals
  • Server functions are a public HTTP API in disguise: anything they return is exposed, so they need the same authentication and rate limits as any endpoint
  • Everything goes through Rust compile times, and the browser must download and compile a Wasm binary before the page becomes interactive
  • Inside Tauri only a static front end works, since Tauri doesn’t officially support server-based setups, so server rendering and server functions are left out

Alternatives

What all webassembly have in common →Compare side by side →
WASIOpen sourceThe WebAssembly System Interface: standard APIs for files, clocks, random numbers, sockets and HTTP that let one .wasm binary run outside the browser, with only the capabilities its host grants.

How it fits with other technologies

A counter: the component runs once, the signal updates one text node · rust

use leptos::prelude::*;

#[component]
pub fn SimpleCounter(initial_value: i32) -> impl IntoView {
    // a reactive signal with the initial value
    let (value, set_value) = signal(initial_value);

    let clear = move |_| set_value.set(0);
    let decrement = move |_| set_value.update(|value| *value -= 1);
    let increment = move |_| set_value.update(|value| *value += 1);

    view! {
        <div>
            <button on:click=clear>"Clear"</button>
            <button on:click=decrement>"-1"</button>
            // only this text changes when `value` does
            <span>"Value: " {value} "!"</span>
            <button on:click=increment>"+1"</button>
        </div>
    }
}

See it in a real stack

No architecture uses Leptos yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2022–2026

Rust could already run in browsers through WebAssembly, and Yew, an earlier Rust framework, used a virtual DOM: state changes re-run components, which produce a new virtual tree to diff against the old one. Greg Johnston, who describes himself as a classicist, started Leptos in 2022 under the influence of SolidJS instead, and named it after the Greek λεπτός, “thin, light, refined, fine-grained”. Version 0.1 came out in January 2023.

Leptos grew into a full-stack framework: server rendering with streaming, hydration, a router and isomorphic server functions, which Dioxus also uses in its full-stack mode. Version 0.7, in November 2024, was a nearly complete rewrite of the internals after more than a year of work, aimed at smaller Wasm binaries, faster HTML rendering, better async support and signals that can cross threads. 0.8 followed in May 2025, and 0.9 reached its first release candidate in October 2026, promising that most 0.8 code upgrades without changes.

Why it’s built this way

Fine-grained signals instead of a virtual DOM
Re-running a component and diffing its output costs work on every change. Running components once and wiring signals to the exact DOM nodes that read them means a change touches only those nodes.
Isomorphic server functions
Server-only logic such as database queries and authentication can live beside the components that use it, called like a local async function, without designing and maintaining a separate REST API.
Rewrite the internals in 0.7
Suspense had edge cases, Wasm binaries and HTML were larger than they needed to be, and signals couldn’t be sent across threads; the rewrite fixed these while keeping most application code compatible.

Timeline

  1. 2022

    Greg Johnston starts Leptos

  2. 2023

    Leptos 0.1 released in January

  3. 2024

    Leptos 0.7, a near-complete rewrite of the internals, in November

  4. 2025

    Leptos 0.8 released in May

  5. 2026

    Leptos 0.9 reaches its first release candidate in October

Sources10 · facts checked 24 October 2026

Improve this page on GitHub