Rust im Browser: Leptos, Yew und Dioxus im Vergleich

JavaScript dominiert das Web seit über zwei Jahrzehnten. TypeScript hat die Sprache um Typsicherheit erweitert, React und Svelte haben Rendering-Modelle verfeinert, und Frameworks wie Astro oder Next.js optimieren die Auslieferung. Aber was, wenn die Grundlage selbst das Limit ist?

Rust bietet mit WebAssembly einen Weg, kompilierte Performance und echte Typensicherheit in den Browser zu bringen. Nicht als Experiment, sondern mit ausgereiften Frameworks, die reaktive UIs ermöglichen. Drei davon stechen heraus: Leptos, Yew und Dioxus. Jedes mit einem anderen Ansatz, jedes mit eigenen Stärken.

Die Frage ist nicht, ob Rust-WASM funktioniert. Die Frage ist: Für welche Projekte lohnt es sich heute schon – und wo bleibt TypeScript die bessere Wahl?

Was WebAssembly im Browser verändert

WebAssembly (WASM) ist ein kompiliertes Binärformat, das neben JavaScript im Browser läuft. Es bietet vorhersagbare Performance nahe an nativem Code, ein striktes Typsystem und eine Sandbox-Architektur, die Speicherzugriffe isoliert.

Für Rust ist WASM ein natürliches Deployment-Target. Der Compiler (rustc) erzeugt über das wasm32-unknown-unknown-Target direkt WASM-Binaries. Kein Interpreter, keine Runtime – kompilierter Code, der im Browser ausgeführt wird.

Was das praktisch bedeutet:

Deterministische Performance: Kein Garbage Collector, der Pausen verursacht. Rust nutzt Ownership und Borrowing statt GC, was zu vorhersagbaren Laufzeiten führt.
Kleine Binaries: Ein minimales Rust-WASM-Binary beginnt bei wenigen Kilobyte. Mit wasm-opt und Tree-Shaking bleiben auch komplexere Anwendungen schlank.
Interop mit JavaScript: Über wasm-bindgen und web-sys können Rust-Funktionen direkt DOM-APIs aufrufen und mit bestehendem JavaScript interagieren.
Speichersicherheit: Rusts Compiler garantiert zur Compile-Zeit, dass kein Zugriff auf freigegebenen Speicher stattfindet. Keine Null-Pointer, keine Data Races.

Das klingt nach einer Grundlagenverbesserung – ist aber kein Selbstzweck. WASM glänzt dort, wo CPU-intensive Berechnungen im Browser laufen: Bildverarbeitung, Kryptografie, Parsing, komplexe Validierungen. Für einfache CRUD-UIs ist der Overhead der Toolchain schwer zu rechtfertigen.

Leptos: Feingranulare Reaktivität, Web-First

Leptos ist das jüngste der drei Frameworks und gleichzeitig das ambitionierteste im Web-Kontext. Es orientiert sich konzeptionell an SolidJS: Statt eines Virtual DOM nutzt Leptos feingranulare Signale, die Abhängigkeiten automatisch tracken und nur die tatsächlich geänderten DOM-Knoten aktualisieren.

Wie Leptos technisch arbeitet

Das Reaktivitätsmodell basiert auf drei Primitiven:

use leptos::*;

#[component]
fn Counter() -> impl IntoView {
    // Signal: reaktiver Wert mit Getter und Setter
    let (count, set_count) = create_signal(0);

    // Derived Signal: berechnet sich automatisch neu
    let double = move || count() * 2;

    view! {
        <button on:click=move |_| set_count.update(|n| *n + 1)>
            "Klick: " {count} " (doppelt: " {double} ")"
        </button>
    }
}

Was hier passiert: create_signal erzeugt einen reaktiven Wert. Jeder Zugriff auf count() registriert automatisch eine Abhängigkeit. Ändert sich der Wert über set_count, werden nur die DOM-Nodes aktualisiert, die count() lesen – nicht die gesamte Komponente.

Das hat messbare Auswirkungen:

Bundle-Größe: Leptos-Apps starten bei circa 25 KB gzip. Zum Vergleich: Ein leeres React-Projekt bringt schon rund 45 KB mit.
Rendering: Kein Diffing-Overhead. Jedes Signal weiß, welche DOM-Knoten es aktualisieren muss.
SSR: Leptos bietet Server-Side Rendering mit Streaming und progressive Hydration. Server Functions erlauben es, Backend-Logik direkt in Komponenten zu definieren.

Fullstack mit Leptos

Leptos ist nicht nur ein Frontend-Framework. Mit cargo-leptos und Actix oder Axum als Backend entsteht eine Fullstack-Architektur:

#[server(GetArticles, "/api")]
pub async fn get_articles() -> Result<Vec<Article>, ServerFnError> {
    // Läuft auf dem Server, wird vom Client wie eine Funktion aufgerufen
    let articles = db::fetch_articles().await?;
    Ok(articles)
}

#[component]
fn ArticleList() -> impl IntoView {
    let articles = create_resource(|| (), |_| get_articles());

    view! {
        <Suspense fallback=move || view! { <p>"Laden..."</p> }>
            {move || articles.get().map(|data| match data {
                Ok(articles) => view! {
                    <ul>
                        {articles.into_iter().map(|a| view! {
                            <li>{a.title}</li>
                        }).collect_view()}
                    </ul>
                },
                Err(_) => view! { <p>"Fehler beim Laden"</p> },
            })}
        </Suspense>
    }
}

Server Functions werden beim Build automatisch in API-Endpunkte kompiliert. Der Client ruft sie transparent auf – kein manuelles REST-API-Design nötig. Das erinnert an tRPC im TypeScript-Ökosystem, ist aber typsicher über die gesamte Kompilierungskette.

Wo Leptos steht

Leptos ist seit Version 0.6 (Anfang 2025) stabil genug für Produktionsprojekte. Die Community wächst, cargo-leptos bietet Hot-Reloading, und das Framework hat die beste SSR-Geschichte im Rust-WASM-Ökosystem. Einschränkungen: Das Ökosystem an Drittanbieter-Komponenten ist noch dünn, und die Lernkurve für Rust-Neulinge bleibt steil.

Yew: Bewährte Architektur, stabiles Ökosystem

Yew ist das älteste Rust-WASM-Frontend-Framework und orientiert sich an Elm und React. Es nutzt einen Virtual DOM und das Message-Passing-Pattern: Komponenten definieren ein Modell (State), Nachrichten (Actions) und eine Update-Funktion, die State-Übergänge beschreibt.

Wie Yew technisch arbeitet

use yew::prelude::*;

enum Msg {
    Increment,
}

struct Counter {
    count: i32,
}

impl Component for Counter {
    type Message = Msg;
    type Properties = ();

    fn create(_ctx: &Context<Self>) -> Self {
        Self { count: 0 }
    }

    fn update(&mut self, _ctx: &Context<Self>, msg: Self::Message) -> bool {
        match msg {
            Msg::Increment => {
                self.count += 1;
                true // re-render
            }
        }
    }

    fn view(&self, ctx: &Context<Self>) -> Html {
        html! {
            <button onclick={ctx.link().callback(|_| Msg::Increment)}>
                { format!("Klick: {}", self.count) }
            </button>
        }
    }
}

Das Pattern ist explizit: Jede State-Änderung ist eine Nachricht, jeder Update-Schritt gibt an, ob ein Re-Render nötig ist. Das macht den Datenfluss nachvollziehbar, erfordert aber mehr Boilerplate als Signal-basierte Ansätze.

Der Virtual DOM funktioniert wie bei React: Bei jedem Render erzeugt view() einen neuen VDOM-Baum, der gegen den vorherigen gedifft wird. Nur die Unterschiede werden im echten DOM angewendet.

Reife und Ökosystem

Yew ist bei Version 0.21+ und hat das ausgereifteste Ökosystem der drei Frameworks:

yew-router: Client-Side Routing mit verschachtelten Routes
yew-agent: Web Workers Integration für Background-Tasks
gloo: Bindings für Browser-APIs (Fetch, Timer, Storage)
stylist: CSS-in-Rust mit Compile-Time-Checks

Die Bundle-Größe liegt bei circa 110 KB gzip – deutlich mehr als Leptos, bedingt durch die VDOM-Runtime. Für die meisten Anwendungen ist das akzeptabel, aber spürbar bei langsamen Verbindungen.

Wo Yew steht

Yew ist die konservative Wahl. Wer aus React oder Elm kommt, findet sich schnell zurecht. Das Framework ist produktionsreif, gut dokumentiert und hat die größte Community. SSR ist möglich, aber nicht so nahtlos integriert wie bei Leptos – es erfordert manuelle Konfiguration mit Frameworks wie Actix.

Die Schwäche: Yews Architektur fühlt sich zunehmend überholt an. Feingranulare Reaktivität hat sich in der JS-Welt durchgesetzt (Solid, Svelte 5), und der VDOM-Overhead ist ein bekanntes Problem. Für neue Projekte ist Yew nicht mehr die erste Empfehlung – aber für bestehende Codebases stabil und verlässlich.

Dioxus: React-Syntax, Multi-Plattform

Dioxus verfolgt den breitesten Ansatz: Eine Codebase für Web, Desktop (via WebView oder nativ), Mobile und Terminal-UIs. Die Syntax orientiert sich bewusst an React mit JSX-ähnlichem RSX-Makro, und das Rendering nutzt einen optimierten Virtual DOM mit Fiber-Architektur.

Wie Dioxus technisch arbeitet

use dioxus::prelude::*;

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

    rsx! {
        button {
            onclick: move |_| count += 1,
            "Klick: {count}"
        }
    }
}

fn main() {
    // Web:
    dioxus::launch(Counter);
    // Oder Desktop:
    // dioxus::desktop::launch(Counter);
}

Die Hooks-API (use_signal, use_effect, use_resource) ist direkt von React inspiriert. Wer React-Hooks kennt, findet sich sofort zurecht. Unter der Haube arbeitet ein optimierter VDOM, der über eine Fiber-Architektur Render-Arbeit in Chunks aufteilt – ähnlich wie React 18 mit Concurrent Mode.

Cross-Platform als Kernfeature

Das Besondere an Dioxus: Derselbe Komponentencode rendert auf verschiedenen Plattformen:

// Shared Component
fn App() -> Element {
    let articles = use_resource(|| async { fetch_articles().await });

    rsx! {
        div { class: "container",
            h1 { "Meine Artikel" }
            match &*articles.read_unchecked() {
                Some(Ok(list)) => rsx! {
                    for article in list {
                        ArticleCard { article: article.clone() }
                    }
                },
                Some(Err(_)) => rsx! { p { "Fehler beim Laden" } },
                None => rsx! { p { "Laden..." } },
            }
        }
    }
}

Dieser Code läuft im Browser als WASM, als Desktop-App via Webview oder nativem Renderer, und theoretisch auf Mobile. Die CLI (dx) bietet Hot-Reloading, Asset-Bundling und Build-Targets für alle Plattformen.

Bundle-Größe im Web: circa 45 KB gzip – ein guter Mittelweg zwischen Leptos und Yew.

Wo Dioxus steht

Dioxus ist seit Version 0.5 (2025) das am schnellsten wachsende der drei Frameworks. Der Cross-Platform-Ansatz ist das stärkste Differenzierungsmerkmal. Die Web-Performance liegt nah an Leptos, die DX ist durch die React-Nähe niedrigschwellig.

Einschränkungen: Mobile ist noch experimentell. Desktop über Webview funktioniert solide, nativer Rendering ist in Arbeit. SSR existiert, ist aber weniger ausgereift als bei Leptos.

Direktvergleich

Aspekt	Leptos	Yew	Dioxus
Reaktivitätsmodell	Feingranulare Signale	Virtual DOM + Message-Passing	Optimierter VDOM + Hooks
Bundle-Größe (gzip)	circa 25 KB	circa 110 KB	circa 45 KB
SSR	Exzellent (Streaming, Hydration)	Manuell konfigurierbar	Vorhanden, im Aufbau
Plattformen	Web (Fokus)	Web	Web, Desktop, Mobile, TUI
Syntax-Nähe	SolidJS	Elm / React Class Components	React Hooks
Ökosystem	Wachsend	Ausgereift	Solide, wachsend
Lernkurve (mit Rust-Kenntnis)	Mittel	Niedrig	Niedrig
Server Functions	Integriert	Extern	Vorhanden

Ist Rust-WASM eine Alternative zu Astro?

Die kurze Antwort: Nein – zumindest nicht als Ersatz. Astro ist ein Content-Framework, das HTML-First denkt und JavaScript nur dort einsetzt, wo Interaktion nötig ist. Leptos, Yew und Dioxus sind Application-Frameworks für reaktive UIs.

Die differenziertere Antwort: Die Ansätze ergänzen sich.

Wo Astro besser passt:

Content-lastige Websites, Blogs, Dokumentationen
Marketing-Seiten mit minimalem JavaScript
Projekte, in denen SEO und Ladezeit an erster Stelle stehen
Teams, die JavaScript/TypeScript bereits beherrschen

Wo Rust-WASM punktet:

Rechenintensive Client-Logik (Bildverarbeitung, Kryptografie, Parser)
Anwendungen mit komplexem State-Management (Dashboards, Editoren)
Projekte, die Rusts Typensicherheit über die gesamte Kette nutzen wollen
Cross-Platform-Anforderungen (Dioxus)

Ein hybrides Szenario ist nicht nur realistisch – es ist wahrscheinlich der pragmatischste Einstieg in Rust-WASM.

Leptos + Astro + Tailwind: Das Beste aus beiden Welten

Die Kombination funktioniert, weil die Technologien auf verschiedenen Ebenen arbeiten und sich nicht ins Gehege kommen:

Astro liefert die Seiten-Architektur: Routing, SSG/SSR, Content Collections, optimierte Asset-Pipeline. Alles, was Astro gut kann, bleibt in Astro.

Leptos übernimmt interaktive Inseln, die mehr Logik brauchen als ein Svelte- oder React-Component sinnvoll abbilden kann. Ein Leptos-Component wird zu WASM kompiliert und als Custom Element in Astro eingebettet.

Tailwind funktioniert in beiden Welten. Leptos’ view!-Makro akzeptiert CSS-Klassen genauso wie HTML:

view! {
    <div class="max-w-3xl mx-auto p-6 bg-white rounded-lg shadow-md">
        <h2 class="text-2xl font-light text-gray-900 mb-4">
            {title}
        </h2>
        <input
            class="w-full px-4 py-2 border border-gray-300 rounded-md
                   focus:ring-2 focus:ring-blue-500 focus:outline-none"
            type="text"
            on:input=move |ev| set_query(event_target_value(&ev))
        />
    </div>
}

Tailwind-Klassen werden vom Astro-Build-Prozess erkannt, solange die Leptos-Quelldateien im content-Pfad der Tailwind-Konfiguration liegen. Die generierten CSS-Utilities landen im selben Stylesheet – ob sie aus einer .astro-Datei oder einem .rs-File stammen, ist für Tailwind irrelevant.

Der Integrationsweg: Leptos-Komponenten als Web Components (Custom Elements) kompilieren und in Astro-Seiten einbetten. Die WASM-Datei wird als statisches Asset ausgeliefert, das Custom Element registriert sich beim Laden. Für Astro sieht das aus wie jedes andere Client-Side-Element:

---
// Astro-Seite: normales SSG
import Layout from '../layouts/Layout.astro';
---
<Layout title="Produktsuche">
  <h1 class="text-4xl font-light">Produkte</h1>

  <!-- Leptos WASM Component als Custom Element -->
  <product-search data-api="/api/products" />

  <script src="/wasm/product_search.js" type="module"></script>
</Layout>

Das Ergebnis: Astro rendert die Seite statisch mit perfektem SEO und minimaler Ladezeit. Leptos übernimmt die interaktive Suche mit 100.000 Datensätzen im Browser – typsicher, schnell, ohne JavaScript-Runtime-Overhead. Tailwind stylt beides konsistent.

Für mich ist genau diese Kombination der interessanteste Weg, Leptos schrittweise in bestehende Astro-Projekte einzuführen, ohne alles auf einmal umzubauen.

Rust-WASM vs. TypeScript: Wann lohnt der Wechsel?

TypeScript ist und bleibt die pragmatische Wahl für die meisten Webprojekte. Das Ökosystem ist riesig, die Toolchain ausgereift, und die Einarbeitungszeit minimal. Rust-WASM muss sich an diesem Standard messen.

Wo TypeScript reicht

CRUD-Anwendungen mit Standard-UI-Patterns
Projekte mit kurzen Iterationszyklen (Prototyping, MVPs)
Teams ohne Rust-Erfahrung
Anwendungen, die primär I/O-bound sind (API-Calls, Datenbankabfragen)

Wo Rust-WASM besser sein kann

Rechenintensive Logik: Ein JSON-Parser in Rust-WASM kann 3-10x schneller sein als die JavaScript-Variante. Bildfilter, Kryptografie-Operationen oder Physik-Simulationen profitieren messbar.

Typensicherheit ohne Lücken: TypeScript ist strukturell typisiert – any und Type Assertions umgehen das System. Rusts Typsystem ist nominal und lückenlos. Was kompiliert, hat garantiert keine Null-Pointer oder Race Conditions.

Langfristige Wartbarkeit: Rust erzwingt explizite Fehlerbehandlung über Result<T, E>. Kein vergessenes try/catch, keine unbehandelten Promise-Rejections. Bei komplexen Businesslogik-Systemen zahlt sich das über die Lebensdauer aus.

Vorhersagbare Performance: Kein Garbage Collector bedeutet keine GC-Pausen. Für Echtzeit-Anwendungen (Audio, Video, Spiele) ist das entscheidend.

Die ehrliche Einschränkung

Compile-Zeiten in Rust sind lang. Ein vollständiger Build einer Leptos-App dauert 30-60 Sekunden, inkrementelle Builds 5-15 Sekunden. Verglichen mit dem sofortigen Hot-Reload einer Vite/React-App ist das spürbar. cargo-leptos und dx mildern das mit Hot-Reloading ab, aber der Feedback-Loop bleibt langsamer.

Und: Das Ökosystem ist kleiner. Für eine Datepicker-Komponente, einen Rich-Text-Editor oder eine Charting-Bibliothek gibt es in JavaScript hunderte Optionen. In Rust-WASM gibt es vielleicht drei – oder keine.

Hosting: Cloudflare, Fly.io und EU-Hoster

Die Hosting-Frage ist weniger kompliziert als erwartet, weil WASM-Frontends letztlich statische Dateien sind. Der Server-Teil (SSR, Server Functions) bestimmt die Anforderungen.

Cloudflare Workers und Pages

Client-Side Rendering (CSR): Funktioniert sofort. WASM-Dateien werden als statische Assets über Cloudflare Pages ausgeliefert. Konfiguration in wrangler.toml, Deploy via wrangler deploy. Das ist identisch mit jeder statischen Website.

Server-Side Rendering: Hier wird es interessant. Cloudflare Workers unterstützen WASM-Ausführung nativ – aber die Frameworks erwarten typischerweise eine Node-kompatible oder native Rust-Runtime. Leptos mit Actix oder Axum läuft nicht direkt auf Workers. Es gibt experimentelle Adapter (leptos_cloudflare), die aber noch nicht produktionsreif sind.

Empfehlung: CSR-only-Apps auf Cloudflare Pages. Für SSR andere Plattformen wählen.

Fly.io

Fly.io ist die beste Option für Rust-WASM-Fullstack-Apps. Es deployt Docker-Container auf Edge-Servern weltweit. Ein Leptos-App mit Actix-Backend läuft als normales Rust-Binary in einem Container:

# fly.toml
[build]
  dockerfile = "Dockerfile"

[http_service]
  internal_port = 3000
  force_https = true

[[vm]]
  size = "shared-cpu-1x"
  memory = "256mb"

Vorteile: Geringe Latenz durch Edge-Deployment, einfaches Scaling, integriertes TLS. Nachteil: Fly.io ist ein US-Unternehmen mit Rechenzentren in Europa (Amsterdam, Frankfurt), aber kein EU-Anbieter im rechtlichen Sinn.

Deutsche und EU-Hoster

Für Projekte mit strikten Datenschutzanforderungen gibt es mehrere Optionen:

Hetzner Cloud: Rust-Binaries laufen direkt auf VPS-Instanzen oder in Docker-Containern. Hetzner bietet Rechenzentren in Falkenstein, Nürnberg und Helsinki. Preis-Leistung ist hervorragend (CX22 ab 4,50 Euro/Monat). Kein Managed Platform – man betreibt den Server selbst.

Uberspace: Shared Hosting mit SSH-Zugang. Rust-Binaries können kompiliert und als Daemon gestartet werden. Unkonventionell, aber für kleinere Projekte machbar. Rechenzentren in Deutschland.

IONOS / Strato: VPS-Angebote, auf denen Docker oder Rust-Binaries direkt laufen. Weniger Developer-freundlich als Hetzner, aber für Unternehmen mit bestehenden Verträgen eine Option.

Scaleway (EU): Französischer Cloud-Anbieter mit Kubernetes-Support und Container-Registry. Gut geeignet für Container-basierte Deployments. DSGVO-konform.

Generelle Empfehlung: Leptos/Dioxus-Apps als Docker-Container bauen. Das entkoppelt vom Hoster und macht Migration einfach. Ein Multi-Stage-Dockerfile mit rust:alpine als Build-Stage und alpine:latest als Runtime hält Images unter 20 MB.

Wann welches Framework?

Leptos wählen, wenn:

Web-Performance und SSR Priorität haben
Fullstack in einer Sprache gewünscht ist
Das Team bereit ist, in ein neueres Ökosystem zu investieren
Streaming-SSR und Server Functions gebraucht werden

Yew wählen, wenn:

Stabilität und ein reifes Ökosystem wichtiger sind als Cutting-Edge
Das Team aus der Elm-Welt kommt oder explizites State-Management bevorzugt
Eine bestehende Yew-Codebase weiterentwickelt wird
Kein SSR benötigt wird

Dioxus wählen, wenn:

Cross-Platform ein Kernziel ist (Web + Desktop)
Das Team React-Erfahrung mitbringt
Schneller Einstieg in Rust-UI gewünscht ist
Mobile-Unterstützung perspektivisch relevant wird

Bei TypeScript bleiben, wenn:

Das Team kein Rust kennt und kurzfristig liefern muss
Standard-CRUD-UIs gebaut werden
Das JavaScript-Ökosystem (npm-Packages, Component Libraries) essenziell ist
Prototyping-Geschwindigkeit entscheidend ist

Praxistest: Zwei konkrete Szenarien

Theorie ist das eine. Aber was passiert, wenn man Rust-WASM an realen Projektanforderungen misst? Zwei Szenarien, die in meinem Arbeitsalltag regelmäßig auftauchen.

Szenario 1: Datenbank-Webanwendung ablösen

Die Ausgangslage: Eine bestehende Vue-Anwendung verwaltet 20-30 Entities, einige davon mit über 100.000 Datensätzen. Formulare, Listenansichten mit Suche, Filter und Sortierung, Bulk-Operationen. Klassische Business-Software, die über Jahre gewachsen ist.

Wäre Rust-WASM hier eine Alternative?

Ja – aber mit Einschränkungen. Die Stärken von Rust-WASM zeigen sich genau dort, wo Vue an Grenzen stößt:

Wo Rust-WASM punkten würde:

Große Listen: 100.000 Datensätze clientseitig filtern, sortieren und durchsuchen – das ist CPU-intensive Arbeit. Rust-WASM kann solche Operationen 3-10x schneller ausführen als JavaScript. Eine Volltextsuche über 100.000 Einträge, die in JavaScript 200ms dauert, liegt in Rust-WASM bei 20-50ms.
Komplexe Validierungen: 30 Entities mit Abhängigkeiten untereinander bedeuten Validierungslogik, die schnell verschachtelt wird. Rusts Typsystem und Pattern Matching machen solche Regeln explizit und compile-time-sicher. Kein vergessener Edge-Case, der erst im Produktivbetrieb auffällt.
Datenintegrität: Rust erzwingt über Result<T, E>, dass jeder Fehlerfall behandelt wird. Bei einer Anwendung mit 30 Entities und komplexen Abhängigkeiten ist das kein akademischer Vorteil – es ist der Unterschied zwischen “funktioniert meistens” und “funktioniert nachweisbar”.

Wo es schwierig wird:

Formulare: Das JavaScript-Ökosystem hat jahrelang an Form-Libraries gearbeitet – Formik, React Hook Form, VeeValidate. In Rust-WASM gibt es nichts Vergleichbares. Formulare für 30 Entities müssen weitgehend von Hand gebaut werden.
UI-Komponenten: Datepicker, Autocomplete, Drag-and-Drop-Tables, Rich-Text-Felder – in Vue gibt es fertige Libraries. In Leptos oder Dioxus muss man vieles selbst implementieren oder auf wenige Community-Projekte hoffen.
Migrationsaufwand: Eine gewachsene Vue-Codebase mit 20-30 Entities komplett nach Rust zu portieren, ist ein Projekt von Monaten, nicht Wochen. Und das Team muss Rust lernen.

Pragmatische Empfehlung: Nicht die gesamte Anwendung ablösen. Stattdessen die rechenintensiven Teile als WASM-Module in die bestehende Vue-App einbinden – etwa die Suchlogik, Filteroperationen oder komplexe Validierungen. Die Formulare und UI bleiben in Vue/TypeScript, wo das Ökosystem stark ist. Wenn die Erfahrung positiv ausfällt und das Team Rust beherrscht, kann ein Neuschrieb in Leptos für die nächste Major-Version evaluiert werden.

Szenario 2: Shopsystem mit Kauflogik und Backends

Die Ausgangslage: Ein Shopsystem mit drei Bereichen – Kauflogik (Warenkorb, Checkout, Bezahlung), Kundenbackend (Bestellhistorie, Profil, Retouren) und Adminbackend (Produktverwaltung, Bestellmanagement, Reporting).

Wäre Rust-WASM hier sinnvoll?

Teilweise – aber nicht als Gesamtlösung.

Wo Rust-WASM Sinn macht:

Kauflogik: Preisberechnung mit Rabatten, Staffelpreisen, Steuersätzen für verschiedene Länder, Gutschein-Kombinationen – das ist Businesslogik, die fehlerfrei sein muss. Rust macht ungültige Zustände durch das Typsystem undarstellbar. Eine Preisberechnung, die kompiliert, berechnet korrekt. Das ist bei einem Shopsystem keine Spielerei, sondern geschäftskritisch.
Server Functions: Leptos’ Server Functions erlauben es, die Kauflogik auf dem Server auszuführen und trotzdem typsicher vom Client aus aufzurufen. Kein REST-API-Design, keine OpenAPI-Specs, keine Codegenerierung – ein einziger Rust-Typ fließt vom Backend bis zum Checkout-Formular.
Performance bei Reporting: Das Adminbackend aggregiert Bestelldaten, berechnet Umsätze, filtert nach Zeiträumen. WASM kann solche Berechnungen clientseitig durchführen und den Server entlasten.

Wo TypeScript besser bleibt:

Kundenbackend: Bestellhistorie anzeigen, Profil bearbeiten, Retoure einleiten – das sind Standard-CRUD-Operationen. Kein Performance-Problem, kein komplexer State. Hier überwiegt der Vorteil des JavaScript-Ökosystems (fertige Komponenten, schnelle Iteration).
Payment-Integration: Stripe, PayPal, Klarna – alle bieten JavaScript-SDKs. Rust-Bindings existieren teilweise, sind aber weniger getestet und dokumentiert.
SEO für den Shop-Frontend: Produktseiten müssen für Google optimiert sein. Astro oder Next.js mit SSG/SSR sind hier etabliert und erprobt. Leptos kann SSR, aber das SEO-Tooling drumherum ist im JavaScript-Ökosystem ausgereifter.

Pragmatische Empfehlung: Die Kauflogik (Preisberechnung, Warenkorbregeln, Validierung) als Rust-Crate entwickeln, das sowohl auf dem Server als auch als WASM im Browser läuft. Denselben Code für Server-Validierung und Client-Preview nutzen. Das Frontend selbst – Produktseiten, Kundenbereich, Admin-UI – in TypeScript mit einem bewährten Framework bauen. Die Businesslogik ist in Rust kugelsicher, die UI profitiert vom JavaScript-Ökosystem.

Einordnung

Rust-WASM-Frameworks sind 2026 keine Spielzeuge mehr. Leptos bietet eine SSR-Geschichte, die sich mit Next.js messen kann. Dioxus’ Cross-Platform-Ansatz hat kein Äquivalent im JavaScript-Ökosystem. Und selbst Yew als konservativste Option liefert Typensicherheit, die TypeScript nicht erreicht.

Aber die Hürden sind real: Rust hat eine steile Lernkurve, Compile-Zeiten bremsen den Feedback-Loop, und das Komponentenökosystem ist eine Größenordnung kleiner als im JavaScript-Universum. Für die meisten Webprojekte bleibt TypeScript mit Astro, Svelte oder React die pragmatische Wahl.

Rust setze ich bereits in Webprojekten als WebAssembly ein – aber bisher ohne ein dediziertes UI-Framework wie Leptos, Yew oder Dioxus. Von den dreien finde ich Leptos am interessantesten. Der feingranulare Reaktivitätsansatz überzeugt mich technisch, die SSR-Integration ist durchdacht, und die SolidJS-Nähe trifft meinen Geschmack besser als die Alternativen. Ich werde in den kommenden Monaten einiges in diese Richtung ausprobieren und Erfahrung sammeln, ob Leptos sich für die Anforderungen meiner Kundenprojekte eignet.

Dioxus fällt für mich vorerst raus – nicht wegen der technischen Qualität, sondern weil der React-Ansatz als Vorbild mich nicht anspricht. Wer jahrelang mit React gearbeitet hat, wird Dioxus’ RSX-Syntax sofort mögen. Ich komme aus einer anderen Richtung und suche bewusst nach Alternativen zu den React-Patterns, nicht nach deren Portierung in eine andere Sprache.

WebAssembly selbst halte ich für eine der wichtigsten Entwicklungen im Web der letzten Jahre. Die Frage ist nicht mehr ob, sondern wann und wo es zum Standard wird. Und Leptos ist aktuell der überzeugendste Weg, das auszuprobieren.

Weiterführende Ressourcen

Leptos Book – Offizielle Dokumentation und Tutorials
Yew Docs – Einführung und API-Referenz
Dioxus Guide – Getting Started und Plattform-Guides
Rust and WebAssembly – Das offizielle Rust-WASM-Buch
wasm-bindgen Guide – JavaScript-Interop im Detail