Bring browser-compatible Rust capabilities into traditional Web applications without replacing the host renderer.
An existing traditional Web application may have one capability that belongs in Rust, but no team wants to rewrite its page tree, router, business state, or design system—or hand-write another WASM wrapper for every project. Vooya standardizes the boundary between that host application and one Rust/WASM capability island.
Vooya is not a replacement for the host renderer or a full Rust application framework. It is a framework-agnostic integration layer for the build and runtime work around that island. Vue and React are the supported first-party adapters. Solid and Svelte are experimental first-party adapters with current evidence on the Vite 7 Rust-file path; other hosts require their own adapter and evidence.
The short version is: keep JavaScript, move only the expensive part. The application remains the familiar surface, while one focused workload travels to a Rust/WASM island. That “voyage to island” idea also guides Vooya FS, the continuation of Rush-FS: it keeps a Node-style API while moving measured batch filesystem work to native Rust through Node-API. Browser Vooya uses WASM; Vooya FS stays native because their host capabilities and performance boundaries differ.
Read why Vooya for the design context, then the component boundary and getting started guide.
After the first run, check the toolchain reference and compatibility matrix before choosing a bundler.
For adjacent projects, see Vooya FS for native Node.js batch filesystem operations and Vooya Lab for runnable boundary evidence.
Choose Vooya when a traditional Web application needs a Rust/WASM capability and the team wants a maintained integration contract instead of another one-off wrapper. Vooya standardizes the recurring work around WASM loading, typed ABI, framework adapters, lifecycle, events, disposal, diagnostics, declarations, and bundler assets. It makes custom WASM wrappers a repeatable toolchain surface that can be tested and evolved across projects.
Canvas, WebGL, editors, parsers, data-heavy widgets, local stores, and other bounded capabilities are reasonable starting points. Keep ordinary page layout, routing, forms, and application state in the host renderer while the beta focuses on the island boundary.
SSR, hydration, and a standalone Rust renderer are not implemented in the current beta path. They remain possible future layers, not permanent exclusions. Vooya also does not imply that moving code to WASM makes it faster; measure a real workload against a real host baseline.
Vooya first published all ten packages at 0.1.0-beta.0. The npm beta channel now has @vooya/vite, @vooya/react, @vooya/solid, and @vooya/svelte at 0.1.0-beta.2, and @vooya/vue at 0.1.0-beta.1; the other five remain at beta.0. Use each package's beta tag, not a forced shared version. The Vite Rust-file path is the primary source authoring route; published Rspack and Webpack evidence uses transitional fixtures. Their Rust-file integration and other 0.2 additions are available through the opt-in 0.2.0-alpha.0 package set. Beta remains the default quickstart. Source authors use system Rust/WASM tools or the optional alpha preset; host SDK/linker prerequisites still apply. A supported precompiled component product is not published yet. Read Project status for the evidence behind these statements.
