A library for building reactive web apps.
- No VDOM. Fine grained reactivity using signals to minimize DOM API calls.
- Uses plain Rust syntax rather than a macro DSL.
- CSS scoping via CSS Modules. See the CSS modules example.
- Routing that works on the client or server.
- Tauri support
- Server side rendering with hydration, and compile time pre-rendering.
- Full stack apps using Arpy. See the client-server example.
- htmx integration. See the htmx-axum example.
use futures_signals::signal::{Mutable, SignalExt};
use silkenweb::{elements::html::*, prelude::*, value::Sig};
fn main() {
let count = Mutable::new(0);
let count_text = count.signal().map(|i| format!("{i}"));
let inc = move |_, _| {
count.replace_with(|i| *i + 1);
};
let app = div()
.child(button().on_click(inc).text("+"))
.child(p().text(Sig(count_text)));
mount("app", app);
}rustup target add wasm32-unknown-unknown
cargo install --locked trunk
cd examples/counter
trunk serve --openSycamore and Leptos are 2 other signals based Rust frameworks. They are evolving quickly at the time of writing this comparison, as is Silkenweb. Also bear in mind I'm not that familiar with Sycamore or Leptos.
- Silkenweb uses plain, non-macro Rust as much as possible, and a lot of effort has been put into making this ergonomic. Sycamore and Leptos primarily use a macro DSL to define components. I believe Sycamore also has a builder API.
- Ecosystem: Leptos and Sycamore have
cargo-leptosand Perseus respectively, whereas Silkenweb doesn't have an ecosystem at this point. - CSS Scoping: Silkenweb supports CSS Modules. See the CSS modules example. CSS Modules support is integrated with SSR and Hydration so that only the CSS required to render the initial page is sent from the server, then progressively enhanced as required on the client. I'm not aware of any CSS scoping support in Leptos or Sycamore.
- Server Functions: Leptos supports server functions to seamlessly divide your app between client and server. Silkenweb doesn't directly support anything like this, but similar functionality is provided with Arpy.
- Sycamore and Leptos both go to some effort to make cloning signals into closures more ergonomic. Silkenweb provides a
clone!macro to make things a little easier, but otherwise doesn't address the problem. I'm not sure what the tradeoffs are for the Sycamore/Leptos approaches. Do they make cleaning up after derived signals harder? Do they mean more complex lifetime annotations? Do contexts need to be passed around everywhere? - Silkenweb has support for using third party web components. I'm not sure about Sycamore or Leptos.
- Silkenweb has support for shadow roots, including Hydration and SSR support with the experimental Declarative Shadow DOM. It also has a simple Component wrapper to manage slots. Again, I'm not sure about Leptos and Sycamore here.
- Silkenweb doesn't use any unsafe Rust directly. Some of the underlying Crates do use unsafe, but at least you don't have to put as much trust in my coding skills!
- All of these frameworks support:
- Static site generation.
- Progressive enhancement using SSR and hydration.
The use of a signals-based approach can provide better performance because it allows the compiler to know the data dependencies within your application at compile time. This allows changes to be efficiently calculated at runtime. On the other hand, with a basic VDOM based approach, the changes need to be identified at runtime.
The drawback of a signals-based approach is that the code tends to be more complicated. However, in actual implementation, VDOM-based approaches often implement mechanisms to prevent complete re-rendering of the VDOM every time a change occurs, which adds some level of complexity to code using the VDOM approach.
Using plain Rust syntax has numerous benefits, such as:
- No need to learn a macro Domain Specific Language (DSL).
- Improved code completion through
rust-analyser. - Familiar documentation structure, thanks to
rustdoc. - Code formatting with
rustfmt. While macro DSLs can be formatted withrustfmtif designed with care, the syntax is limited byrustfmt's capabilities. - Exceptional compiler errors from
rustc: Although macro DSLs can produce informative errors, a lot of work has been put into makingrustcerror messsages great. - The ability to utilize Rust's composable, well-designed abstractions.
While a macro DSL could be developed to work with Silkenweb, the syntax in Rust is already well suited for defining document structure.
cargo doc --open- Check out the examples folder
- futures-signals tutorial
- Feel free to ask any questions on our Discord channel.