你使用的部分桌面应用很可能是用 Electron 开发的,它是一种框架,结合了 Node.js,部分 Chromium,以及一层原生代码。Visual Studio Code,Slack,Atom,WhatsApp,甚至微软的 Visual Studio 安装程序都使用它来构建面向 Windows,macOS,Linux 的桌面应用。我已经基于 Electron 做了几年开发,曾经写过一个简短的指南,并且深深沉入在它的社区中。
每当一种技术获得某种青睐,总会有相当多的人站出来谴责说这种技术是糟糕的,它生来就带缺陷,并且所解决的问题并没有提倡者说的那么复杂。Electron 也不例外。但通常用来谴责它的理由(比如内存消耗,总体性能,应用打包体积)显然说不动开发者或者终端用户。
在 HackerNews 上评论 “呸,Electron” 似乎无济于事,所以一起来看下你还能做什么。我们先讨论开发者为什么选择它,它现在又为何能痛击(摩擦)其他桌面软件开发环境。然后再看看你该如何战胜 Electron。
“跨平台”这个术语并没有很好的定义——在微软,它通常意味着跨 Windows 10, Xbox, and Windows Phone 10 开发(排除了 Windows 7)。在苹果的世界,我们讨论的是 iOS, tvOS, watchOS, 和 macOS 不同平台代码的可移植性。对于一些前端库,甚至仅仅意味着支持多种屏幕尺寸。
如果你在开发桌面应用,你需要触达桌面用户。Ground truth 统计显示大部分用户在使用 Windows 7 和 10,也有不少人在使用最新的 macOS,相对少的人在使用 Linux 的各种发行版本。对于大部分 Electron 开发者来说,并不用去关心移动平台,游戏终端,或者 IoT 设备。Electron 赋予开发者高效开发目标桌面系统应用的能力,并且在四个角斗场痛击它的竞争者。
不管你喜不喜欢,在经历了多年的迭代以及涌现出数量惊人的框架、库,甚至语言后,web 开发者可以使用非常非常多极棒的开发工具。这甚至使得应用开发中的热更新都显得无足轻重。这种程度的生产力是无与伦比的。
其他跨平台技术就不用说了,即便针对单一平台的开发环境如今也大大落后于 web 开发。Xcode 有些年头没有改善开发者的工作流,虽然你或许已经习以为常。 在 Windows 世界,微软似乎把它的精力专注于整体的 Windows 平台,但却排除了 Windows 7。而 Linux 呢,甚至还缺少任何一致的意见。我曾看见两个成年人就 gtk2 vs gtk3 问题相互咆哮。
因为包含了 libchromiumcontent (Chrome 的渲染引擎),Electron 允许开发者构建出跨平台但体验一致的用户界面。也因此,开发者不用受限于比如 Windows 7 上 IE11 的兼容问题——你如果愿意甚至可以用 Rust/WebAssembly 来写整个应用。
Electron 提供了 web 开发极高的生产力,同时避免了需要支持陈旧浏览器的痛苦。如果你的解决方案想要击败 Electron,它需要提供相同程度的友好的开发环境,方便、高效以及容易招聘工程师。
因为包含了 Node.js,所以 Electron 允许开发者使用 npm,这个至今为止最大的开源代码仓库。更重要的是,它允许开发者在需要的时候跳出 Javascript 的限制——许多 Electron 应用使用 C++ 或者 Objective-C 来写高性能的逻辑,调用相对晦涩难懂的操作系统 API,或者和其他环境进行交互。Atom 最近使用了原生 C++ 文本缓冲区, 但 Visual Studio Code 发现优化后的 Javascript 也许更快。
微软经常问我需要什么样的 API 设计方案才能和 Electron 竞争。问题本身是错误的:有了 Electron,人们不需要知道这个问题的答案(译者注:意思是怎么设计都没法干过 Electron)。在 Electron 中没有什么是受限的,就算那些最不知名的 WinAPI 和 COM 调用也能被使用。虽然不是所有的 Electron 应用都需要调用原生方法(像 Visual Studio Code 的原生调试器),但没有任何一个应用被限制使用(原生 API)。
如果所有用户都使用最新版本的操作系统,最新版本的现代浏览器,以及你的最新版本的应用,Electron 可能就没那么有吸引力了。不过我们并不生活在这种理想世界里。
Electron 不但提供了一个平台用于构建应用,使这些应用能够运行在可能超过10年都没有更新的系统环境中。更重要的,它还提供了开发者打包、发布、更新应用等全套服务。
像 PWA 这种基于浏览器的解决方案需要开发者持续提醒他们的用户保持系统更新。原生的跨平台方案比如 Qt 趋向于把自己定位成一个库,而非平台,所以极少提供像自动更新软件,安装程序,应用商店包等功能。
你可能认为相对于跨平台方案自身,发布和更新可能是小菜一碟。如果你从来没有开发过自动更新功能,相信我软件的自动更新是不好对付的。如果你想战胜 Electron,你需要让开发者写完代码就能发布应用让用户使用。
瞧不起 Javascript 开发者似乎是一种快速地团结“真正开发者”的方式。许多人认为 Electron 开发者选择 Electron 是因为他们不知道除此之外其他构建应用的方法。是的,Electron 使得开发桌面应用更容易了。对于跨平台开发来说,它是目前最容易的解决方案。就我自己而言,Electron 对 web 开发者打开了桌面应用的世界本身是让我对它如此激动的原因之一。
这的确是事实,因为容易上手,所以很多 Electron 应用是那些不完全懂 WinAPI,AppKit,甚至不懂如何写高性能 Javascript 的开发者写出来的。期望这些应用通过原生的方式在所有平台实现是不现实的。在 Electron 出现之前,这些应用根本不会存在。
因为 Electron 既适合初级工程师,也适合高级工程师,容易上手这一点可能没有想象中那么重要。如果有一个解决方案除了易于上手外在其他方面都比 Electron 出色,那么很多公司可能会为此转身。如果你想战胜 Electron,理解和明白有经验的桌面软件开发者选择它的原因是非常重要的。Visual Studio Code 背后的开发者持续发布让人惊叹的软件的同时,保持了让人惊叹的性能。 说 Visual Studio 背后的团队没有人懂原生的 Windows 开发因而被迫使用 Electron 开发他们的安装程序是非常可笑的。
如果你知道有很多深入 Electron 开发的工程师希望它从来不曾存在这个事实你可能会很惊讶。淘汰 Electron 需要一个有竞争力的技术,能够同时提供初级和高级开发者更高的价值。
如果你梦想的未来中没有跨平台的应用,那么去呼吁苹果认真对待 macOS 和它的开发环境,呼吁微软认清楚 win32 没有死,不管他们如何努力想消灭它。
Electron 不是为了和谁竞争。它只是开源社区填补这个鸿沟的努力。如果你想战胜 Electron,你也需要去填补;并且你需要比 Electron 做得更好。许多 Electron 维护者投入精力就是为了开发出用户喜欢的桌面应用。你如果能够帮助他们解决困难,提供更好的开发平台,他们会微笑,并且握着你的手,和你说声谢谢。