kaja-web brings non-reactive Rust web apps to WebAssembly

A click counter is where kaja-web makes its case. The new Rust framework from johanmattssonm arrived on June 18 and compiles to WebAssembly, but its real hook is the way it handles the page itself: HTML lives as strings inside plain Rust code, and rerenders do not happen automatically when state changes.

That choice puts kaja-web on a different track from the reactive frontend style many Rust developers now associate with browser work. Instead of letting a framework decide when a component should refresh, kaja-web asks the programmer to call update functions manually and use inner_html to change the DOM. The README says there is no DSL, only plain Rust plus glue code that wires event handlers such as onclick into WebAssembly functions. For developers used to Axum or Actix on the backend, or to component systems that hide update timing behind state transitions, the pitch is simple: keep the rendering path explicit and keep control in Rust.

The project’s examples underline that idea. The repository includes folders for callbacks, clickcounter, and serversiderendering, and the README shows structured data moving from JavaScript callbacks into Rust through serde::Deserialize. That means the framework is not just about drawing text into a browser window; it is trying to cover the whole small-app loop, from a button click to a manual page refresh, without introducing a heavier abstraction layer between the event and the DOM change.

That restraint is also what makes kaja-web interesting inside the Rust web ecosystem. It is not trying to outreactive the frameworks that dominate client-side discussion. It is trying to make the tradeoff visible: a browser-facing Rust stack built around strings, explicit updates, and glue code that you can trace by hand. For some applications, that will feel like less magic and less boilerplate at the same time; for others, it will look like a deliberate refusal to automate the part of the UI lifecycle that reactive frameworks usually own.

The repository still looks early. GitHub showed 35 commits, no published releases, and 0 stars when viewed, with the default branch updated on June 18, 2026. That leaves the framework in the experimental lane for now, but its central question is already clear: when rendering stays explicit, are you getting cleaner control over the app, or just a different kind of ceremony?