Capy UI vs Zapy UI — 深度对比先澄清最关键的一点Zapy 不是 Capy 的竞品而是 Capy 的 Fork从 Zapy UI 自己的 README 就能直接确认Zapy UI is an actively maintained fork of the original Capy UI project.As the original developer has reduced activity, I’ve taken over development to push the project forward…所以它们的对比本质上是原版 Capy上游vs社区接手的活跃复刻Zapy的选择问题。1. 项目身世与现状维度Capy UI原版Zapy UI作者/维护者zen1thZen1th Remplerzapy-ui 维护者接手Codeberg 托管仓库GitHubzen1th/Capy→ 官网capy-ui.orgCodebergzapy-ui/zapy-ui定位原始项目仍在推进但节奏慢活跃维护的 fork明确标注breaking changes as we improve目标 Zig 版本随 Zig master 波动常跟 nightly明确标靶Zig 0.15.1生产就绪作者自己说NOT ready for production仍有 breaking changes同样标注evolving with breaking changes但更主动修 bug社区渠道#capy-uiMatrix / Zig Discord#gui-dev沿用同一套社区渠道本身就是同一条线2. 架构与核心技术两者共享的 DNA两者底层完全一致因为 Zapy 就是 Capy 的代码 fork声明式 UI 范式— 用capy.column(.{ .spacing 10 }, .{ ... })这样的 comptime 风格构建 widget tree原生控件后端非自绘Windows→ Win32 API原生 HWND 按钮/文本框等Linux→GTK 3选择原因兼容性最广KDE 的 Qt 主题集成不够统一macOS→ AppKitWIPWeb→ WASM JS bridgecanvas 渲染层可执行体积极小— 示例程序 2MB远小于 Electron150MB/ Flutter10MB/ Qt8MB导出 C ABI—capy-ui.org强调可导出 C API供 C/C/Node/Bun 等调用DataWrapper驱动数据绑定 动画comptime-heavy 设计一句话Zapy 和 Capy 用的是同一套引擎。差异不在谁的架构更好而在谁在修 bug、谁在跟进 Zig 版本、谁在合并 PR。3. 关键差异点这才是你选哪个的依据 维护活跃度Capy原版Zapy提交频率间歇式作者承认“slow pace”更持续明确在做 bug fix WASM 完善Issue/PR 处理堆积风险Fork 动机之一就是原仓库响应慢Zig 版本适配跟 zig master但容易 broken锁定瞄准0.15.1更稳定可复现 WASM / Web 支持Capy 原版的 WASM 后端是experimental级别Zapy 明确把improved WASM support列为 fork 的核心卖点之一 API 稳定性Capy 0.3 的 changelog 里作者直言仍在做 breaking changessetProperty风格 API 在犹豫中Zapy 坦诚地说“API may change in the future”但它是在主动整形而非被动停滞 生态与 DocsCapy 有capy-ui.org正式文档站 模板capy-templateZapy 目前主要指向 Capy 的同一套文档/模板/社区自身还没建独立品牌体系4. 代码层面——几乎一模一样Zapy 的示例用的 import 名还是capy不是zapyconst capy import(capy); const std import(std); pub usingnamespace capy.cross_platform; pub fn main() !void { try capy.init(); defer capy.deinit(); var window try capy.Window.init(); try window.set(capy.column(.{ .spacing 10 }, .{ capy.button(.{ .label Save, .onclick ptrCast(buttonClicked) }), capy.expanded(capy.textArea(.{ .text Hello World! })), })); window.setPreferredSize(800, 600); window.show(); capy.runEventLoop(); }你在 Zapy 里写的代码和 Capy 里的写法是同一个 namespace。迁移成本 ≈ 改build.zig.zon里的 URL。5. 实用选型建议场景推荐你想今天就开始做一个 Zig GUI 原型并且 zig 0.15.x 环境✅Zapy— 更可能编译过、WASM 更可用、bug 修复更快你想要跟着上游官方走愿意等/自己 patch盯Capy原版capy-ui.org关注 zen1th 是否回归活跃生产用途⚠️ 两者都明确说not production ready都要做好 breaking change 的心理准备你需要 macOS 原生两者都标 macOS 为 WIP实际可用性以你亲手编译测试为准一句话总结Capy 是亲爹Zapy 是养父接过来继续养。如果你只是想写 Zig 原生 GUI 且希望它能编译、有人修东西——Zapy 在目前这个时间窗口更务实。但长远看如果原版 Capy 重新活跃、或 Zapy 反并回去这条线大概率会 reconverge重新汇合。两者不是 Flutter vs Electron 那种架构对立而是同一个项目在不同维护者手里的两种命运。需要我帮你搭一个最小可运行的build.zig.zonbuild.zig模板针对 Capy 或 Zapy指定 Zig 0.15.x吗