Leptos, Dioxus e Yew são os três frameworks que respondem à pergunta dá para fazer frontend (e full-stack) em Rust? Em 2026 a resposta não é mais experimental: os três compilam UI para WebAssembly, usam componentes reativos e têm projetos em produção. A diferença está no modelo de reatividade, no suporte a SSR, no alcance multiplataforma e na maturidade do tooling.
Resposta curta para quem precisa decidir agora:
| Precisa de… | Escolha |
|---|---|
| Web full-stack com SSR, SEO e server functions | Leptos |
| Uma base de UI para web + desktop + mobile + TUI | Dioxus |
| SPA no navegador no estilo React, só client-side | Yew |
Este comparativo aprofunda arquitetura, exemplos de código, performance, tooling e mercado no Brasil. Complementa o panorama de GUI em Rust 2026 (foco desktop: Iced, Tauri, egui) e o guia de aplicações web com WebAssembly. Se você está vindo de JavaScript, veja também Rust para programadores JavaScript e o comparativo Rust vs JavaScript 2026.
Visão Geral: Três Filosofias
Antes dos detalhes, o mapa mental:
| Aspecto | Leptos | Dioxus | Yew |
|---|---|---|---|
| Modelo mental | Solid/Svelte (signals fine-grained) | React + multi-target | React (VDOM) |
| Reatividade | Signals + effects | Signals (desde 0.5+) | Virtual DOM + use_state |
| SSR / hidratação | Excelente (foco do projeto) | Bom (fullstack mode) | Limitado / secundário |
| Server functions | Nativo (#[server]) | Nativo (server fns) | Não é o foco |
| Targets | Web (CSR/SSR) | Web, desktop, mobile, TUI | Web (CSR) |
| Tooling oficial | cargo-leptos | dx (CLI Dioxus) | Trunk + wasm-bindgen |
| Sintaxe de view | view! (RSX-like) | rsx! (JSX-like) | html! (JSX-like) |
| Backend típico | Axum / Actix | Axum / próprio | Qualquer (API separada) |
| Curva para dev React | Média (signals ≠ VDOM) | Baixa (RSX familiar) | Baixa (mais próximo do React) |
| Melhor para | Apps web com SEO e latência | Produtos multiplataforma | SPAs e aprendizado |
A frase que resume: Leptos é o full-stack web nativo em Rust; Dioxus é o “escreva uma vez, rode em tudo”; Yew é o React-like consolidado no navegador.
Leptos: Full-Stack Web com Signals
O Leptos nasceu com a meta de ser um framework web isomorphic: o mesmo componente roda no servidor (HTML streaming) e no cliente (WASM hidratado). A reatividade é fine-grained — signals e derived values atualizam só o pedaço do DOM que mudou, sem re-renderizar a árvore inteira como um Virtual DOM clássico.
Quando usar Leptos
- Produto web com SEO, first contentful paint e rotas públicas
- Time que já usa Axum ou Actix e quer unificar a linguagem
- Dashboards e apps internos onde type-safety end-to-end importa
- Casos em que server functions eliminam boilerplate de API REST
Exemplo mínimo (contador reativo)
use leptos::prelude::*;
#[component]
fn Contador() -> impl IntoView {
let (valor, set_valor) = signal(0);
view! {
<button on:click=move |_| *set_valor.write() += 1>
"Cliques: " {valor}
</button>
}
}
No modo full-stack, você anota funções de servidor com #[server] e o framework gera a ponte tipada cliente↔servidor — padrão parecido com tRPC ou Server Actions, mas com o type system do Rust dos dois lados. O CLI cargo-leptos cuida de build, watch e bundle do WASM.
Prós e contras
Prós: SSR/streaming de primeira classe; signals eficientes; integração natural com Axum; ecossistema de crates (leptos_router, leptos_meta) maduro em 2026.
Contras: Foco em web (não é a melhor opção se o produto precisa de desktop nativo); curva dos signals para quem só conhece VDOM; tempo de compilação de projetos grandes ainda dói (mitigue com workspaces e features e o guia de tempo de compilação).
Dioxus: React para Rust em Vários Targets
O Dioxus leva a metáfora do React a sério: componentes, hooks e a macro rsx! no estilo JSX. A grande diferença em relação ao Yew e ao Leptos é o alcance de plataforma: a mesma árvore de componentes pode renderizar na web (WASM), no desktop (WebView ou WGPU), no mobile e até em TUI no terminal — tema que já aparece no nosso guia de TUI com Ratatui e no comparativo Tauri vs Electron.
Quando usar Dioxus
- Produto que precisa de web e desktop (ou mobile) com o máximo de código compartilhado
- Times vindos de React que querem RSX familiar sem largar Rust
- Ferramentas internas, painéis e apps de borda com UI rica
- Experimentos de multiplataforma sem reescrever a view layer
Exemplo mínimo
use dioxus::prelude::*;
fn main() {
dioxus::launch(App);
}
#[component]
fn App() -> Element {
let mut count = use_signal(|| 0);
rsx! {
h1 { "Contador Dioxus: {count}" }
button { onclick: move |_| count += 1, "+1" }
}
}
O CLI dx simplifica serve, hot-reload e empacotamento. A partir das versões recentes o Dioxus também adotou signals (saindo do modelo 100% VDOM), o que aproximou a performance do Leptos em atualizações granulares.
Prós e contras
Prós: multiplataforma de verdade; DX próxima do React; hot-reload; server functions no modo fullstack; comunidade ativa.
Contras: maturidade mobile ainda evolui caso a caso; desktop via WebView herda trade-offs de WebView (ver Tauri vs Electron); a flexibilidade de targets aumenta a superfície de bugs “só nesta plataforma”.
Yew: O Pioneiro SPA em Rust
O Yew foi, por anos, o framework web em Rust. Modelo de componentes com html!, mensagens e Virtual DOM — a ponte mental para quem vem de React/Elm é quase direta. Continua excelente para SPAs que rodam só no cliente e para material didático (nosso tutorial de WebAssembly ainda usa Yew como exemplo de SPA).
Quando usar Yew
- SPA client-side sem requisito forte de SSR
- Código legado ou tutoriais baseados em Yew
- Projetos que preferem o modelo clássico de VDOM + mensagens
- Protótipos e aprendizado de WASM no navegador
Exemplo mínimo
use yew::prelude::*;
#[function_component]
fn Contador() -> Html {
let counter = use_state(|| 0);
let onclick = {
let counter = counter.clone();
Callback::from(move |_| counter.set(*counter + 1))
};
html! {
<button {onclick}>{ format!("Cliques: {}", *counter) }</button>
}
}
fn main() {
yew::Renderer::<Contador>::new().render();
}
O fluxo típico usa Trunk para servir e empacotar o WASM. O backend fica separado — Axum, gRPC com Tonic ou o que o time já usa — falando via HTTP/JSON com reqwest ou gloo-net.
Prós e contras
Prós: documentação e exemplos abundantes; modelo mental familiar; estável para CSR; ótimo para aprender WASM.
Contras: SSR e full-stack não são o centro do projeto; VDOM costuma perder para signals em atualizações finas; momentum da comunidade migrou em parte para Leptos/Dioxus em 2025–2026.
Comparativo Prático: O Que Pesa na Decisão
1. SSR, SEO e first paint
Se a página precisa ranquear no Google ou abrir rápido em 3G, Leptos lidera: HTML sai do servidor, depois hidrata. Dioxus fullstack cobre bem o caso, mas o storytelling e o ecossistema de SSR do Leptos estão mais maduros. Yew é CSR-first — para SEO você depende de pré-render externo ou de um backend que sirva shells.
2. Multiplataforma
Só o Dioxus trata desktop/mobile/TUI como cidadãos de primeira classe. Leptos e Yew são web. Se o roadmap inclui app desktop com a mesma UI, Dioxus (ou UI web + Tauri) é o caminho.
3. Integração com backend Rust
Leptos + Axum e Dioxus fullstack eliminam boa parte do contrato OpenAPI manual via server functions tipadas. Com Yew você monta a API à parte — o que pode ser vantagem se o backend já existe ou é compartilhado com apps mobile nativos.
4. Curva de aprendizado
- Dev React/JS: Dioxus ≈ Yew (mais fáceis) → depois Leptos (signals).
- Dev Rust backend (Axum/Tokio): Leptos costuma “clicar” mais rápido, porque o mental model de ownership e tipos no servidor já é o dia a dia — veja async Rust e serviços resilientes com Tower/Axum.
- Iniciante em Rust: comece pelo curso de Rust 2026 e como aprender Rust antes de full-stack WASM; o borrow checker + WASM + framework é muita coisa de uma vez.
5. Tooling e DX
| Ferramenta | Papel |
|---|---|
cargo-leptos | Dev server, build SSR+WASM, watch |
dx (Dioxus CLI) | Serve, hot-reload, bundle multi-target |
| Trunk | Serve/bundle clássico para Yew (e outros CSR) |
wasm-bindgen / wasm-pack | Ponte JS↔Rust (ecossistema) |
rust-analyzer | IDE — obrigatório nos três |
Tempo de compilação incremental ainda é o ponto frágil dos três. Use cargo check no loop, features granulares e CI com cache (veja Docker builds otimizados e deploy de Axum).
Exemplo de Decisão por Cenário
SaaS B2B com landing pública e app autenticado. Leptos: landing com SSR para SEO, app com signals, auth e server functions no mesmo binário Axum.
Ferramenta de produtividade com versão web e .dmg/.exe. Dioxus: mesma UI, targets web + desktop; lógica de domínio em crates compartilhados.
Dashboard interno atrás de VPN, API já pronta em Axum. Yew ou Dioxus CSR consumindo a API; time ganha velocidade sem reescrever o backend.
Jogo ou visualização pesada no canvas. Nenhum dos três é engine de jogos — olhe Bevy e o artigo Rust para jogos. Para UI de editor/ferramenta em volta do canvas, Dioxus ou egui (no guia de GUI 2026) costumam encaixar melhor.
Edge / Workers. Combinação frequente: lógica em Rust compilada para WASM em Cloudflare Workers + UI em Leptos/Dioxus hospedada à parte, ou páginas estáticas com islas interativas.
Mercado e Carreira no Brasil
Vagas com o título “frontend Rust” ainda são raras no Brasil. O que aparece com frequência:
- Backend/sistemas em Rust com “diferencial: WASM / full-stack”
- Empresas de produto (fintechs, infra, segurança) listadas em empresas que usam Rust e no panorama de fintechs
- Freelance e side-projects onde a stack unificada reduz custo de equipe
Na prática, o caminho de carreira mais sólido continua sendo domínio sólido de Rust systems/async (carreira Rust 2026, salários, vagas) mais um dos frameworks deste artigo no portfólio. Um CRUD full-stack em Leptos ou um app desktop+web em Dioxus no GitHub pesa mais em entrevista do que só tutoriais de ownership — veja portfolio GitHub e projetos práticos.
Guia Rápido de Migração Mental (React → Rust)
| Conceito React | Leptos | Dioxus | Yew |
|---|---|---|---|
useState | signal / RwSignal | use_signal | use_state |
useEffect | Effect::new / watch | use_effect | use_effect |
| JSX | view! | rsx! | html! |
| React Query / fetch | Resource + server fn | use_resource / server fn | use_effect + gloo-net |
| Next.js SSR | cargo-leptos SSR | Dioxus fullstack | (não é o foco) |
| Context | provide_context | use_context | ContextProvider |
Serialização de dados entre cliente e servidor quase sempre passa por Serde — o mesmo crate do backend. Validação de formulários e payloads entra no guia de validação com validator/garde.
Checklist Antes de Escolher
- Preciso de SEO/SSR de verdade? → Leptos (ou Dioxus fullstack).
- Preciso de desktop/mobile além da web? → Dioxus.
- É só SPA atrás de login, API já existe? → Yew ou Dioxus CSR.
- O time é React-heavy e tem pressa? → Dioxus (RSX) ou Yew.
- O time é Rust-backend-heavy? → Leptos + Axum.
- O binário precisa ser minúsculo em IoT/edge UI? → Avalie também Slint/egui no guia GUI — às vezes o “framework web” não é a resposta.
- Tenho orçamento de CI para builds WASM? → Meça desde o POC; WASM + SSR duplica artefatos.
Conclusão
Em 2026, Leptos vs Dioxus vs Yew deixou de ser disputa de “qual está pronto” e virou disputa de encaixe:
- Leptos — melhor default para aplicação web full-stack em Rust com SSR.
- Dioxus — melhor default quando a UI precisa viver em mais de um target.
- Yew — escolha sólida para SPA CSR e para bases/tutoriais já existentes.
Os três se apoiam no mesmo alicerce: Rust + WASM + Cargo + um runtime async no servidor quando necessário (Tokio). Escolha pelo produto, não pelo hype — e coloque um projeto pequeno no ar em um fim de semana antes de cravar a stack do ano.
Para continuar:
- WebAssembly com Rust (tutorial)
- Rust para web (Axum, Actix, Leptos)
- Axum na prática
- Component Model / WASI no servidor
- Comunidade Rust Brasil e vagas Rust
Perguntas frequentes
Qual o melhor framework frontend em Rust em 2026?
Depende do caso de uso. Para web full-stack com SSR, streaming e hidratação, o Leptos é a escolha mais madura. Para multiplataforma (web, desktop, mobile e TUI) com a mesma base de componentes, o Dioxus vence. O Yew continua ótimo para SPAs no navegador no estilo React, mas cresce menos que os outros dois. Em projetos novos, a maioria dos times oscila entre Leptos e Dioxus.
Leptos, Dioxus e Yew usam WebAssembly?
Sim. Nos três, o código do cliente compila para WebAssembly e roda no navegador. A diferença está no servidor: Leptos e Dioxus também rodam nativos no backend (SSR e server functions), enquanto o Yew é predominantemente client-side. Em todos os casos o toolchain passa por wasm-bindgen e, no fluxo de SPA, por Trunk ou pelos CLIs oficiais (cargo-leptos, dx).
Posso substituir React por Leptos ou Dioxus?
Em projetos novos, sim — especialmente se o time já programa em Rust no backend e quer unificar a stack. Em produtos grandes com milhares de componentes React, a migração total raramente vale o custo. O caminho pragmático é adotar Rust no backend (Axum, Actix) e em módulos WASM de performance, e considerar Leptos/Dioxus em greenfield ou em ferramentas internas. O comparativo Rust vs JavaScript 2026 aprofunda esse trade-off.
Qual tem melhor performance?
Os três entregam SPAs WASM com runtime menor que stacks JS típicas. O Leptos se destaca em SSR com fine-grained reactivity (signals) e hidratação seletiva. O Dioxus moderno também usa signals e tem bom desempenho em desktop. O Yew usa Virtual DOM (como React) e fica um pouco atrás em atualizações granulares, mas ainda é rápido o suficiente para a maioria das UIs de negócio.
Qual framework full-stack Rust escolher no Brasil?
Para produto web com SEO e first paint rápido, prefira Leptos com Axum. Para app que precisa de desktop e web no mesmo código, prefira Dioxus. Yew ainda aparece em tutoriais e bases legadas. Em vagas brasileiras de Rust o frontend WASM ainda é niche — o volume está em backend, sistemas e embarcados — mas full-stack Rust é um diferencial forte em startups de produto e no nicho web/backend.