我为什么还在维护一个基于 Electron 的图片压缩工具？

在 AI 和 Native 盛行的时代，聊聊 Hummingbird 的技术取舍与长期主义

现在是 2026 年。打开 GitHub Trending，满屏都是 AI Agent、Rust 重写的 CLI 工具，或者是追求极致性能的 Native 应用。

在这个时间点，继续维护一个基于 Electron 的桌面端图片压缩工具——Hummingbird，听起来似乎有点“政治不正确”。毕竟，大家都会问：“为什么不重写？为什么不用 Tauri？为什么不用纯 Swift/C++？”

作为一个同时也是 iOS/macOS 开发者（正在开发 Medrea）的我，其实比谁都更在意性能和包体积。但今天我想聊聊，为什么对于 Hummingbird 来说，Electron 依然是当下最好的选择，以及这款工具背后的“长期主义”。

做开源工具最怕的是什么？是维护疲劳。

我希望 Hummingbird 能同时服务 macOS 和 Windows 用户。如果我追求极致原生，我需要写一套 Swift (AppKit/SwiftUI) 给 Mac，再写一套 C# (WPF) 或 C++ 给 Windows。这对于独立开发者来说，维护成本是指数级上升的。

Electron 虽然常被诟病“吃内存”，但它在 2026 年依然是UI 表现一致性最好的解决方案。对于一个图片压缩工具，用户用完即走，他们更在意的是“拖进去就能用，界面不丑”，而不是它占用了 100MB 还是 30MB 内存。

Hummingbird 的核心价值不在于 UI，而在于压缩算法。

Node.js 社区拥有极度成熟的图片处理库（如 pngquant-bin, mozjpeg, cwebp 等的封装）。通过 Electron，我可以无缝地桥接这些经过工业级验证的底层二进制文件，而不需要自己在 Rust 或 C++ 里重新处理复杂的跨平台编译链问题。

我们在 v4.x 版本中解决的多线程问题，正是得益于这种架构的灵活性。我不造算法，我只是优质算法的“搬运工”和“组装工”。

这几年，AI 生成图片爆发，SaaS 订阅制横行。你随手搜一个“图片压缩”，大概率会搜到：

Hummingbird 在 2026 年存在的意义，恰恰是因为它“不够智能”且“完全离线”。

很多设计师和开发者告诉我，他们依然坚持用 Hummingbird，是因为公司的保密协议（NDA）禁止将设计稿上传到任何云端。基于 Electron 的本地化处理，让它成为了一个绝对安全的“黑盒”。不联网、不上传、不搜集数据，这种“老派”的作风在今天反而成了一种 feature。

软件工程里有一种迷思：只有不断重构的代码才是好代码。但对于工具类软件，稳定性 > 追逐新框架。

Hummingbird 不需要变得更复杂。它不需要集成 AI 聊天，不需要社交功能。它只需要在用户把一张 10MB 的 PNG 拖进去时，吐出一张 2MB 的图片，并且肉眼看不出区别。

只要它还能在最新的 macOS 和 Windows 上稳定运行，只要它还能帮大家省下带宽和流量，我就有理由继续维护它。

Hummingbird 是完全免费且开源的。如果你是一名开发者，欢迎去 GitHub 看看代码，甚至 Fork 一个属于你的版本。如果你觉得它好用，点个 Star 就是对我最大的支持。

最后，夹带一点私货： 如果你对我开发的这类“小而美”的工具感兴趣，或者是 Apple 生态的开发者，欢迎关注我的另一个核心项目 Medrea。那里汇聚了我对原生开发更深层的思考。