基准

服务器端呈现

我创建了一个基准测试，将Leptos在服务器上的HTML渲染与Tera，Yew和Sycamore进行了比较。你可以在此处找到基准测试，并使用 .Leptos 渲染 HTML 的速度大致与 Tera 一样快，并且随着模板变大而扩展良好。它比类似框架完成的服务器端HTML渲染要快得多。

cargo bench

客户端呈现

测试前端 Web 框架原始渲染性能的黄金标准是 js-framework-benchmark。官方结果将Leptos列为最快的Rust / Wasm框架，比SolidJS略慢，比流行的JS框架（如Svelte，Preact和React）快得多。

点击显示结果

常见问题

我可以将其用于本机 GUI 吗？

确定！显然，宏用于生成 DOM 节点，但你可以使用响应式系统来驱动任何使用与 DOM 相同类型的面向对象、基于事件回调的框架的 GUI 工具包。原理是相同的：

view

• 使用信号、派生信号和备忘录来创建 React 式系统
• 创建图形用户界面小部件
• 使用事件侦听器更新信号
• 创建效果以更新 UI

我整理了一个非常简单的 GTK 示例，以便你了解我的意思。

这与红豆杉/红豆杉有何不同？

从表面上看，这些库可能看起来很相似。当然，Yew 是用于 Web UI 开发的最成熟的 Rust 库，并且拥有庞大的生态系统。Dioxus 在很多方面都很相似，都深受 React 的启发。以下是乐浦和这些框架之间的一些概念差异：

• VDOM 与细粒度：Yew 建立在虚拟 DOM （VDOM） 模型之上：状态更改会导致组件重新渲染，从而生成新的虚拟 DOM 树。Yew 将其与以前的 VDOM 进行了区分，并将这些补丁应用于实际的 DOM。 每当状态更改时，组件函数都会重新运行。乐浦采取了完全不同的方法。组件运行一次，创建（并返回）实际的 DOM 节点，并设置一个 React 式系统来更新这些 DOM 节点。
• 性能：这具有巨大的性能影响：Leptos 在创建和更新 UI 方面都比 Yew 快得多。
• 心智模型：采用细粒度的 React 性也倾向于简化心智模型。没有令人惊讶的组件重新渲染，因为没有重新渲染。你的应用可以根据对你的应用有意义的内容划分为多个组件，因为它们对性能没有影响。

这与梧桐树有何不同？

从概念上讲，这两个框架非常相似：因为两者都建立在细粒度的 React 性之上，所以大多数应用程序最终在两者之间看起来非常相似，Sycamore或Leptos应用程序看起来都很像SolidJS应用程序，就像Yew或Dioxus看起来很像React一样。

有一些实际差异会产生显着差异：

• 成熟：Sycamore显然是一个更成熟，更稳定的库，具有更大的生态系统。
• 模板：Leptos 使用类似 JSX 的模板格式（基于 syn-rsx 构建）作为其宏。Sycamore提供了自己的模板DSL或构建器语法的选择。

  view

• 模板节点克隆：Leptos 的宏编译为一个静态的 HTML 字符串和一组如何分配其 React 式值的指令。这意味着在运行时，Leptos 可以克隆节点，而不是调用来创建 DOM 节点。这是一种明显更快的渲染组件的方法。

  view

  <template>

  document.createElement()

• 读写隔离：Leptos 和 Solid 一样，鼓励信号获取器和设置器之间的读写隔离，因此你最终可以使用元组访问信号，例如（如果你愿意，或者如果你的 API 更方便，你可以使用 create_rw_signal 来提供统一的读/写信号。

  let (count, set_count) = create_signal(cx, 0);

• 信号是函数：在 Leptos 中，你可以调用一个信号来访问它，而不是调用一个特定的方法（所以，而不是 ） 这创造了一个更一致的心智模型：访问一个 React 值总是调用一个函数的问题。例如：

  count()

  count.get()

let (count, set_count) = create_signal(cx, 0); // a signal
let double_count = move || count() * 2; // a derived signal
let memoized_count = create_memo(cx, move |_| count() * 3); // a memo
// all are accessed by calling them
assert_eq!(count(), 0);
assert_eq!(double_count(), 0);
assert_eq!(memoized_count(), 0);

// this function can accept any of those signals
fn do_work_on_signal(my_signal: impl Fn() -> i32) { ... }