后续: 因为这次更新社区争议太大，1Password 的技术 VP 在次日就发布了一篇长文解释团队的技术选型过程。我们也邀请了 @子骅 luin 做客枫言枫语播客，一起聊聊 1Password 8 选择 Electron 这件事。
昨天（20201-08-11）1Password 官方发布新闻《1Password 8 for Mac is now in Early Access! 🎉》引起了大家的讨论。1Password 是目前最受欢迎的密码管理器之一，我自己也是 1Password 多年的老用户，大家关注的主要是 1Password 8 使用 Electron 重写了。这点十分令人惊讶。
像 Curtis Herbert 的这串推文所说，大家担心换成 Electron 之后用户体验变差了。
Electron 是基于 Node.js 和 Chromium 项目整合的一个跨平台 GUI 开发框架，应用层使用的是 Web 技术栈，HTML + CSS + JS。最早是 GitHub 官方开发 Atom 编辑器时开发的 Atom Shell，2015 年改名为 Electron。
跨平台开发从来就不是一件容易的事情，无论是桌面端的 macOS/Windows/Linux，还是移动端的 iOS/Android，从底层逻辑代码到 UI 渲染，每个平台都有各自的编程语言和设计规范。但喜欢折腾的程序员们似乎乐此不疲。近些年除了 Electron，还有 React Native，Flutter 等各种各样的跨平台开发技术，更古老的还有 Java 的跨平台 App，曾经的微软 Silverlight，Adobe Air 等等数不胜数。
这么多年下来大家基本上有一个共识：想要获得最佳用户体验，最好的做法是使用该平台的原生开发技术栈。这也是为什么大家反对 1Password 8 采用 Electron 技术，除了让 1Password 这家公司节省开发人力之外（这点亦存疑），用户感受不到 Electron 带来的好处，甚至会导致这个 App 的体验变差。
Electron 的逻辑层采用 Node.js 运行，效率很高，NPM 的生态也让程序员们有丰富多样的库可供使用，开发起来很方便。渲染层采用 Web 技术，Chromium 的渲染效率也很高，HTML+CSS也非常成熟，可以做出自由度很高的 UI。大部分跨平台的逻辑 Electron 在底层已经解决了，理想情况下只需要一套业务代码就可以运行在 macOS/Windows/Linux 上。
但是，需要连接平台特定接口的部分就不行了。比如 macOS 版本的 1Password 有一个 mini window，这个东西出现 macOS 的全局菜单上，是 macOS 的专属 feature。所以 1Password 的程序员势必要为 macOS 专门写一些平台专属代码。如果这个项目足够复杂，平台之间的差异足够大，那“一套代码通吃”就没有那么大的优势了。而且因为 Electron 的特殊性，公司招人的时候就要求程序员既要熟悉 Electron，JS 技术栈，又要熟悉平台相关技术栈，反而更难招人。2018年 Airbnb 宣布使用放弃 React Native 技术时写的这篇文章就提到招人的难处。
当然 Electron 并不是一无是处，它有它适用的场景。我们常用的网络调试工具 Postman就是一个非常适合 Electron 的 App。这样的调试工具并不需要非常高的用户体验，“能用就行”是他的及格线甚至 80 分。而且早期的 Postman 还是基于 Chrome Extension 编写的 Web App，它转型使用 Electron 打包要容易得多。
另一个极端的例子是 VS Code，这个可能是世界上最好的开发者编辑器之一的 App，由微软顶级的 IDE 开发团队维护。这个项目本身就基于 Electron 来做，而且团队成员在开发过程中也反向给 Electron 项目输出了很多性能优化和特性开发。说 VS Code 是目前世界上最好的 Electron App 应该没有什么异议，而且这个项目也确实成为了跨平台应用的典范。凭借它的架构优势，VS Code拥有极高的可扩展性，所以插件市场也非常丰富，是当之无愧的神之编辑器。
当然如果你用 VS Code 来编写大型项目的时候，它启动也会卡。不过，说到启动卡的话，无论苹果的 Xcode，还是微软的 Visual Studio，还是 Google 的 Android Studio，只要是个大工程好像没有不卡的。所以这点大家算扯平了吧。
Electron App还有一个缺点是，即使你只写一个 Hello World 它也十分臃肿，因为打包进了一个 Chromium 渲染内核，加上一个完整的 Node.js，想不臃肿都难。
无论如何，这次 1Password 8 的重写，大家其实最担心的是用户体验问题。我觉得 Electron 有他适用的场景，如果产品的核心体验不受影响，用户可能并不介意 App 采用何种技术，何种表现形式。比如 Notion 的桌面端应用。Notion的使用体验谈不上最佳，因为每次点开一个 Page 都需要经历像打开网页一样的 Loading 过程，即便这个过程只是“一闪而过”，也依然不如拥有本地数据，原生渲染的 App 来得流畅。但这并不影响 Notion 的核心体验，它的扩展性，它的跨平台，它的 Block based editor，才是 Notion 最大的优势。
我平时在使用 1Password 7 时，主要是网页端自动填入密码，这个功能使用 Chrome/Safari Extension 已经可以很好地完成。至于快捷键呼出主 App 进行数据查询，理论上 Electron 应该也可以胜任。我下载了 1Password 8 Beta 版本简单尝试了搜索、新增密码等功能，和原生体验比是差一点，但是本身这些功能即使体验打折也不影响它的核心功能：保存密码。所以我短期的试用觉得 1Password 这样的 App 使用 Electron 是可用的，希望长期不要给我带来困扰。
我不知道 1Password 改用 Electron 的动机是什么，官方 Blog 上面各种“Next Gen”标题但我体验下来除了 UI 改了而且也没有变得多好看之外，似乎并未带来用户可感知的提升。文章也没有提及 Electron 的事情。但是在密码管理器 App 如雨后春笋，各大操作系统和浏览器也争相改进自己的密码管理的情况下，1Password 这一招可能不是明智之举。他没有把精力放在用户能感受到提升的功能上，而是做了一个这样的“大版本”，这对他在未来的密码管理器竞争中恐怕不是什么好事。
P.S. Figma App 可能是另一个用户体验做到极致的 Electron App，但是它的性能更多来自于 Webassembly 加成。换句话说，无论 VS Code 还是 Figma，想要利用 Electron 做出用户体验极佳的 App 需要付出的努力并不小。