#Makepad 1.0 发布

作者：张汉东

我们很高兴终于宣布 Makepad 的首次公开发布！

Makepad (https://makepad.nl ) 是一个用 Rust 编写的 UI 框架。它旨在提高性能——几乎完全依赖 GPU 进行渲染。它具有一种新颖的样式系统，基于使用着色器调整应用程序外观和感觉的想法。为此，它还具有一个自定义 DSL，包括一个编译到多个图形后端的着色器语言。

Makepad 的 DSL 的一个主要特性是实时 UI 编辑：Makepad 应用程序监听其 DSL 源代码的更改，并在运行时更新自身以反映新代码。这使得开发人员可以在不进行每次更改都需要昂贵的重新编译步骤的情况下调整应用程序的布局和样式。

Makepad 目前在所有主要的本地平台上工作（OS X、Windows、Linux、iOS、Android），以及通过 WASM 构建的网页上。

Makepad 技术栈拥有像游戏引擎所具备的自由度和性能。因此，您可以构建非常复杂和大型的应用程序，而在使用 HTML 时，您会很快遇到性能问题。此外，Makepad 允许您编写自己的着色器。

Makepad 应用程序也可以作为原生应用程序运行，而不需要像 Electron 那样的沉重包装。适合任何真正打算构建复杂应用程序并以单一代码库轻松跨平台部署的人。Makepad 非常适合构建像 Photoshop 这样复杂的应用。

Makepad 1.0 有一个新的教程可以帮助你快速上手：https://publish.obsidian.md/makepad-docs/Tutorials/Image+Viewer/0+-+Introduction

目前 Makepad 有两个真实世界的旗舰应用：

• Robrix：一个 Rust Matrix 客户端 https://github.com/project-robius/robrix
• Moly： 一个 Rust AI LLM 客户端 https://github.com/moxin-org/moly

展望未来，我们的目标是从现在开始定期发布，因此 Makepad 将随着时间的推移变得更好。

在线 UI Zoo 演示：https://makepad.nl/makepad-example-ui-zoo/index.html

#来自社区的一些 反响

• Hacker News
• Reddit

1. 虽然 Makepad 1.0 代表了一个重要的里程碑，但进一步的发展对于充分实现其潜力至关重要。未来关注的领域可能包括：

   • 无障碍功能: 实施强大的无障碍支持对于包容性和广泛采用至关重要。
   • 代理 AI 集成: 探索与代理 AI 框架的集成将使 Makepad 处于新兴技术的前沿。
   • IDE 自定义: 扩展 IDE 自定义选项，特别是对各种键盘映射（例如 Vim）的支持，将迎合更广泛的开发者偏好。
   • 真实世界的应用与社区增长: 鼓励开发更多现实世界应用并促进不断增长的社区将是长期成功的关键。

2. 关于字体字形，评论主要集中在Makepad在不同平台下的字体渲染、字体支持和相关问题。

   • 有用户指出，Makepad在小字体下的文本渲染效果不佳，因为没有字体hinting（微调），导致低分辨率时显示不清晰。
   • Web版本目前只支持拉丁字体，日韩文、表情符号等无法正常显示；桌面版则支持更多字体（如Noto Emoji），但Web端未集成，可能是bug。
   • Web端没有IME（输入法）支持，桌面端支持IME，但IME光标区域没有正确传递给操作系统，导致系统自己渲染输入框，位置也不准确。
   • 官方回应：Makepad采用SDF（Signed Distance Fields）方式渲染字形，这样可以在不同分辨率下复用字形，减少内存和提升速度，但牺牲了渲染质量，尤其在低分辨率下。
   • 表情符号和中文字体其实是支持的，但因为Rust crate有 10 MB大小限制，无法全部打包发布，后续会想办法改进。团队最初认为可以将字体作为 crate 的一部分发布。然后我们意识到这是个坏主意，但没有足够的时间来设置可以从其他地方加载的内容。我们不想推迟发布，因此决定在 crate 中包含一小部分字体发布 1.0，并将适当的解决方案推迟到 1.1。
   • Makepad 团队也承认IME和字体支持有不足，计划在下个版本修复这些问题。

3. Makepad 团队选择自定义 DSL 和着色器语言，而不是直接用 wgpu，主要是因为项目启动时 wgpu 还不成熟，以及切换成本高。

   • Makepad 联合创始人回复说，最初开发 Makepad 时，wgpu 还没有准备好，无法满足需求。
   • 目前虽然讨论过切换到 wgpu，但由于现有方案已经能正常工作，而且团队还有很多其他优先事项，所以暂时没有切换。
   • 如果采用 wgpu，需要重写所有现有的着色器代码，并且会显著增加编译时间，这对开发效率不利。但很可能会在不久的将来重新考虑是否采用 Wgpu 的决定
   • 有用户补充，即使像 Bevy 这样的大型 Rust UI/游戏引擎，也觉得 wgpu 还不够完善，所以有团队选择自研方案。
   • 还有人讨论到，wgpu 支持的 WGSL 着色器可以通过工具（如 naga/naga-cli）转译为 GLSL，但这并不能完全解决兼容性和开发体验问题。

4. 评论者认为Makepad目前在Web端“并不能真正可用”，主要因为其纯canvas渲染方式带来了严重的局限性，尤其不适合通用Web应用。

   • 该评论者指出，Makepad在Web端采用纯canvas渲染，这种方式本质上与游戏引擎类似，虽然适合技术演示和部分游戏，但对大多数Web应用来说有很大局限。

   • 主要问题包括：

     • 链接、滚动和文本处理等基本Web功能无法像DOM那样自然实现，体验大打折扣。
     • 多语言文本支持不足，尤其是Web端目前不支持多语言和输入法（IME）/文本合成。
     • 对无障碍技术（accessibility）完全不可见，无法被屏幕阅读器等辅助工具识别。

   • 评论者强调，这些问题虽然理论上可以通过维护独立的无障碍树等方式部分修复，但会带来性能损失和实现复杂度。

   • 还提到Makepad的键盘行为也不完善，且这些问题不仅限于Web端。

   • 总结观点：Makepad的Web支持目前更像是“附带功能”，适合不在意Web体验的场景，但如果真正想做Web应用，纯canvas方案有“根本性缺陷”，不推荐用于通用Web内容。

   • 不过，评论者也肯定了Makepad在桌面端的技术创新和视觉表现，认为其在桌面应用领域前景不错。