Electron 和 Flutter 是两种流行的跨平台桌面应用开发框架。两者都支持 macOS、Windows 和 Linux，但它们的起源不同，在桌面开发方面采用的方法也有根本差异。
Electron 专为桌面应用而设计。它由 GitHub 于 2013 年推出，将 Chromium 与 Node.js 相结合，让开发者能够使用 JavaScript、TypeScript、HTML 和 CSS 构建桌面软件。由 Google 开发的 Flutter 最初是面向 Android 和 iOS 的移动 UI 框架，几年后才扩展到桌面平台。
这两个框架都有强大的行业支持，并在大量生产环境中得到应用。Visual Studio Code、Slack、Discord、Notion 和 Figma 等应用，以及 Anthropic 和 OpenAI 的 AI 应用，都采用了 Electron。Flutter 在移动开发领域尤其受欢迎，但也用于 AppFlowy、RustDesk 和 Ubuntu 系统实用工具等桌面软件。
在 WebCatalog，我们选择使用 Electron 来构建跨平台桌面应用。尽管 Flutter 在应用体积、自定义 UI 渲染以及桌面与移动设备之间的代码共享方面具有优势，但 Electron 以桌面为先的架构和成熟的浏览器能力更符合我们的需求。
Electron 运行缓慢或资源消耗大的名声也值得重新审视。多年来，在依赖它的众多贡献者和企业所组成的大型生态系统的支持下，该框架持续得到优化。近期版本在启动时间、JavaScript 执行、内存管理和运行时效率方面都有显著改进。
那么，如今这两个框架相比如何，开发者又该选择哪一个？
Electron 与 Flutter 速览
尽管两个框架都支持桌面开发，但不同的起源塑造了它们各自的架构、API、工具链和生态系统。
| 特性 | Electron | Flutter |
|---|---|---|
| 首次推出时间 | 2013 年 | 2017 年预览版，2018 年稳定版 |
| 最初开发者 | GitHub | |
| 最初侧重点 | 桌面应用 | 移动应用 |
| 当前侧重点 | 桌面应用 | 移动、桌面、Web、嵌入式 |
| 主要语言 | JavaScript、TypeScript | Dart |
| UI 技术 | HTML、CSS、Chromium | Flutter widget |
| 渲染引擎 | Chromium | Flutter 渲染引擎 |
| 桌面平台 | macOS、Windows、Linux | macOS、Windows、Linux |
| 桌面支持成熟度 | 从一开始就专注于桌面 | 自 2022 年起提供稳定的桌面支持 |
| 移动平台支持 | 无官方支持 | Android、iOS |
| 应用体积 | 通常较大 | 通常较小 |
| 基础内存占用 | 通常较高 | 往往较低 |
| 多窗口支持 | 成熟的内置 API | 2026 年推出实验性核心 API；另有插件方案 |
| 复用现有 Web 应用 | 非常出色 | 通常需要重写 UI |
| 最适合 | 基于 Web 的桌面应用 | 自定义跨平台界面 |
最重要的区别并不只是 Electron 使用 Chromium，而 Flutter 使用自己的渲染引擎。Electron 的诞生是为了解决桌面开发问题，而 Flutter 最初解决的是移动开发问题，后来才调整架构以支持桌面环境。
这种区别至今仍影响着开发体验和平台能力。
历史：Electron 为桌面而生，Flutter 为移动而生
Electron 始于 2013 年，最初名为 Atom Shell，是 GitHub 为其 Atom 代码编辑器开发的框架。从一开始，它的目标就是使用 Web 技术构建功能复杂的桌面应用，同时与操作系统功能集成。
因此，应用窗口、菜单、键盘快捷键、系统托盘、通知、文件对话框和原生集成等桌面概念，在 Electron 的整个发展过程中始终处于架构的核心位置。
随后，Electron 逐渐被开发生产力软件、通信平台、开发工具及其他桌面产品的企业采用。如今，它由 OpenJS 基金会管理，并受益于来自大型科技公司相关人员的贡献。
Flutter 则走了一条不同的道路。Google 最初将其开发为一个移动应用框架，用于构建高度定制且性能出色的界面。Flutter 1.0 于 2018 年 12 月发布，支持 Android 和 iOS。
该框架最初的架构反映了智能手机的需求：触屏交互、移动端导航模式、应用生命周期管理，以及占据单个屏幕的界面。
随着时间推移，Google 将 Flutter 扩展到了更多平台，包括 Web 和桌面操作系统。Windows 于 2022 年 2 月获得稳定支持，随后 macOS 和 Linux 于 2022 年 5 月随着 Flutter 3 的发布获得稳定支持。
在 Flutter 3 发布公告中，Google 表示，该版本标志着 Flutter 完成了从以移动端为中心的框架向多平台框架的转型。
这段历史并不意味着 Flutter 不适合桌面应用。它的桌面能力已经大幅提升，如今可以为三大主流桌面操作系统构建和分发应用。
不过，这有助于解释为什么某些桌面专属功能在 Flutter 中的成熟速度比 Electron 慢。
桌面功能：Electron 先发一步
桌面应用与移动应用有很大不同。桌面用户期望获得可调整大小的窗口、多个独立窗口、键盘和鼠标交互、上下文菜单、系统托盘、拖放、文件关联，以及与操作系统的紧密集成。
Electron 正是围绕这些需求构建的。它的 BrowserWindow 和 BaseWindow API 允许开发者创建和管理多个窗口，其他 API 则提供菜单、全局快捷键、桌面通知、系统对话框、协议处理程序等功能。
Flutter 也支持其中许多功能，但有些需要额外的软件包、平台专属实现，或较新的框架 API。
多窗口支持是一个特别能说明问题的例子。在移动设备上，应用通常只占据一个窗口，对话框和弹出内容以覆盖层的形式渲染。桌面应用则经常需要多个独立窗口，用户可以将这些窗口移到不同显示器上，分别调整大小、最小化并进行管理。
多年来，开发多窗口 Flutter 桌面应用的开发者一直依赖第三方软件包或自定义原生集成。
2026 年 8 月，Flutter 团队推出了新的桌面窗口 API，由 Google 与 Canonical 合作开发。该 API 支持独立窗口、对话框、弹出窗口、工具提示及其他桌面窗口类型。
需要注意的是，它是作为 Flutter 主开发通道上的实验性功能推出的，而不是已经成熟的稳定功能。
| 桌面能力 | Electron | Flutter |
|---|---|---|
| 多个独立窗口 | 成熟的内置支持 | 实验性核心 API；第三方替代方案 |
| 窗口生命周期管理 | 成熟的内置 API | 核心支持仍在发展 |
| 系统托盘 | 内置 API | 插件和原生集成 |
| 应用菜单 | 内置 API | 插件和平台集成 |
| 全局键盘快捷键 | 内置 API | 插件或原生集成 |
| 自定义标题栏 | 成熟的 API | 平台专属方案 |
| 文件关联和深层链接 | 成熟的桌面集成 | 平台集成和插件 |
| 浏览器会话和 Cookie | 丰富的内置 API | 取决于 WebView 实现 |
这并不是说 Flutter 无法构建功能复杂的桌面应用。AppFlowy 和 RustDesk 等产品已经证明它可以。但对于构建桌面优先软件的团队而言，Electron 更成熟的 API 可以减少所需的自定义平台集成工作。
性能：Flutter 更轻量，但 Electron 已有显著进步
性能经常被视为 Flutter 相比 Electron 的最大优势之一。Flutter 将 Dart 编译为原生机器码，并使用自己的渲染引擎，不必仅仅为了显示界面就捆绑 Chromium。
相比之下，Electron 包含 Chromium 和 Node.js，这会增加应用体积和基础内存消耗。过去，这也是 Electron 被认为会生成笨重桌面应用的原因之一。
然而，这种印象并不能完全反映现代 Electron 的状况。
十多年来，Electron 持续受益于 Chromium、V8、Node.js 及其自身应用运行时的改进。如今，许多大型软件公司都在使用该框架，这些公司的产品需要响应灵敏的界面、高效的后台处理，以及在数百万次安装中保持可靠的性能。
重要的是，性能优化发生在多个层面。Electron 升级所集成的 Chromium 和 V8 版本时，会自动受益于它们的改进；同时，Electron 的维护者也会优化其自身的进程初始化、IPC、原生集成和资源管理。
Electron 近期的性能改进
Electron 的 2026 年版本说明提供了具体实例，展示了该框架如何持续提高效率。
| 版本 | 优化 | 收益 |
|---|---|---|
| Electron 43，2026 年 7 月 | 内嵌 Node.js 启动快照 | 降低应用初始化开销 |
| Electron 43 | 缓存已编译的 V8 字节码 | 避免反复编译框架打包文件和预加载脚本 |
| Electron 43 | 改进沙箱化渲染进程的初始化 | 减少 Web 内容渲染前的阻塞工作 |
| Electron 43 | 对 V8 内置函数进行性能分析引导优化 | 提升数组、字符串和正则表达式等 JavaScript 操作的性能 |
| Electron 43 | 在 Windows 和 Linux 上使用 ThinLTO | 改进经过优化的原生发布构建 |
| Electron 44，2026 年 8 月 | 减少空闲时 Node.js 定时器唤醒次数 | 减少不必要的 CPU 活动 |
| Electron 44 | 加快 Linux 工具包初始化 | 改善应用启动速度 |
| Electron 44 | 更早启动沙箱化渲染进程 | 降低打开首个窗口时的延迟 |
| Electron 44 | 缩小 Linux 分发包 | 分发的运行时体积减少约 37 MB |
来源：Electron 43 版本说明和 Electron 44 版本说明。Electron 44 中记录的部分改进也已回移植到较早的版本分支。
其中一项特别值得关注的改进涉及 Electron 的预加载脚本。此前，沙箱化渲染进程可能需要在渲染页面前执行阻塞式 IPC 操作，以获取启动数据。
2026 年，Electron 维护者以更高效的方法替代了这一机制：在页面导航之前提前发送启动数据，并缓存已编译的预加载代码。
在一项已公布的工程基准测试中，在模拟冷启动工作负载下，这一改动将首次内容绘制时间从约 244 毫秒降至 140 毫秒。这意味着该特定测试中的时间缩短了约 43%，并不是说现在每个 Electron 应用的启动速度都提高了 43%。
随着时间推移，该框架也受益于内存方面的改进。Electron 在 Electron 14 中采用了 V8 指针压缩技术，维护者指出，这项底层技术有望将 V8 堆大小最多减少 40%，并将 CPU 和垃圾回收性能提升约 5%–10%。
这些数字特指 V8 的内存和执行特性，而不是应用的总内存占用。尽管如此，它们仍然说明，JavaScript 引擎层面的改进能够惠及 Electron 应用，而不需要每位应用开发者独立实现相同的优化。
更多背景信息，请参阅 Electron 与 V8 内存笼。
为什么企业投入很重要
Electron 的性能改进与其生态系统的规模和成熟度密切相关。
大型软件公司有充分的动力确保 Electron 保持高效。Microsoft 的 Visual Studio Code 使用 Electron，Salesforce 的 Slack 使用 Electron，Anthropic 的 Claude Desktop 使用 Electron，OpenAI 的 ChatGPT Desktop 也使用 Electron。其他采用者还包括 Discord、Notion、Figma 和 GitHub。
这些产品拥有庞大的用户群，性能问题可能直接影响客户满意度、电池续航和生产力。
Electron 由来自多个组织的贡献者共同维护，包括 Microsoft、Slack/Salesforce、Notion 等。这使项目能够获得在生产环境中依赖该框架的企业所积累的工程经验。
Electron 官方文档明确将性能、稳定性和安全性列为持续关注的重点，并介绍了使用 Electron 的组织如何参与其维护工作。
也有单个企业出资推动改进的例子。2025 年 12 月，Electron 团队发布了一篇工程案例研究，介绍他们如何修复 Chromium 中的一个 Windows 窗口大小调整问题，并将相关改动回移植到 Electron。这项工作由基于 Electron 构建的 3D 建模应用 Plasticity 资助。
这展示了成熟开源生态系统的一项重要优势：为某个应用出资或实现的改进，最终可能惠及许多其他应用。
当然，使用 Electron 并不意味着每家公司都会直接参与其开发，大型企业采用它也不能保证性能更优。不过，广泛的行业参与确实为持续优化提供了坚实基础。
这是否意味着 Electron 比 Flutter 更快？
不一定。
对于许多应用而言，Flutter 在基础运行时开销上仍然具有架构优势，因为它不需要附带 Chromium 来渲染自己的界面。轻量级 Flutter 应用可能占用更少内存、启动更快，并且需要更少的磁盘空间。
然而，运行时开销只是性能的一个方面。Chromium 是一个经过高度优化的浏览器引擎，在渲染、JavaScript 执行、GPU 加速、网络和媒体处理方面都获得了大量投入。
当应用本身就依赖这些能力时，Electron 的优势尤为突出。在 Flutter 中重新实现同等功能，或嵌入独立的浏览器组件，可能会抵消 Flutter 原本的一部分资源优势。
| 性能因素 | Electron | Flutter |
|---|---|---|
| 应用体积 | 因包含 Chromium 而较大 | 通常较小 |
| 基础内存占用 | 通常较高 | 往往较低 |
| 启动时间 | 已经过大量优化，但 Chromium 会增加开销 | 轻量应用往往启动更快 |
| UI 渲染 | 优化的 Chromium 流水线 | Flutter 渲染引擎 |
| JavaScript 执行 | 成熟且经过优化的 V8 运行时 | Flutter 的 Dart UI 不需要 JavaScript |
| 自定义图形 | Chromium 渲染 API | 专用的 Flutter 渲染流水线 |
| 现有网站渲染 | Chromium 直接支持 | 需要集成 WebView |
| 运行时优化 | Chromium、V8、Node.js、Electron 贡献者 | Flutter 引擎和 Dart 贡献者 |
| 长期性能投入 | 广泛的行业和开源生态系统 | Google 和 Flutter 开源生态系统 |
因此，两者的区别远比“Flutter 快、Electron 慢”更加复杂。
对于采用自定义界面、对浏览器需求有限的应用，Flutter 可能更高效。Electron 则提供高度优化的 Web 运行时，并通过 Chromium、V8、Node.js 和 Electron 自身的工作持续改进。
开发者应针对具有代表性的生产工作负载进行基准测试，而不是仅仅根据框架过去的口碑进行比较。
开发体验：JavaScript 和 TypeScript 与 Dart
Electron 对已经熟悉 JavaScript 和 TypeScript 的团队尤其有吸引力。开发者可以使用 React、Vue、Svelte 及其他 Web 框架，复用现有前端组件，并依赖 Node.js 软件包实现后端功能。
Flutter 则要求开发者学习 Dart 及其基于 widget 的界面体系。开发者不是编写 HTML 和 CSS，而是通过 Dart widget 构建界面，并用代码表达布局、样式、导航和交互。
Flutter 提供出色的工具，包括热重载、widget 检查、调试工具和性能分析。Electron 开发者则受益于 Chromium DevTools、Node.js 生态系统，以及 Electron Forge 和 electron-builder 等成熟的桌面应用打包工具。
过去，选择熟悉的编程语言可能会对开发成本产生重大影响。以 JavaScript 为主的团队可能更倾向于 Electron，因为采用 Dart 意味着要学习新语言并重写现有组件。
这一考虑仍然重要，尤其对于已有代码库而言。不过，AI 辅助开发正在改变这种权衡。
AI 编程工具如何改变框架选择
Claude Code、Codex 和 Google Antigravity 等工具，让开发者更容易使用自己现有专业知识范围之外的编程语言和框架。
现代 AI 编程助手可以探索陌生代码库、解释框架特定惯例、实现功能、重构代码、编写测试，并协助排查错误。开发者不再需要手动编写每一行代码，也不必先记住框架的每个 API 才能高效工作。
在 Electron 和 Flutter 之间做选择时，这一点尤其重要。
一位使用 TypeScript 多年的开发者，最初可能对 Dart 和 Flutter 感到陌生。但借助 AI，在学习语法、创建 widget、实现状态管理或集成原生 API 时，许多重复性工作都可以加速完成。
Flutter 还提供了面向 AI 编程助手的官方 Dart 和 Flutter 集成。这些集成可以为智能体提供框架专属指导、分析器诊断信息，以及开发工具访问能力。
同样的趋势也不限于 Dart。Rust 和 C++ 等语言历来需要更专业的知识，特别是在内存管理、所有权和原生集成方面。AI 工具可以降低理解和维护这些语言代码所需的投入。
Rust 并不是 Flutter 的主要编程语言，Dart 才是，但背后的普遍道理相同：开发者越来越能够根据架构优势，而不只是语言熟悉程度来选择技术。
当然，AI 仍有局限。AI 生成的代码可能包含隐蔽错误、误解平台 API，或引入性能和安全问题。开发者仍需负责架构、代码审查、性能分析、测试，以及应用的长期维护。
AI 辅助也无法消除框架的根本局限。它或许能帮助开发者实现缺失的桌面集成，但开发者仍需在各个操作系统上构建、测试和维护这些功能。
尽管如此，采用陌生编程语言的成本正在变得不再那么令人望而却步。
对于性能、启动时间、内存消耗或原生集成尤为重要的新应用，开发者不应仅仅因为更熟悉 TypeScript 就自动选择 Electron。
即使 Dart 最初用起来不够顺手，Flutter 也可能值得投入。同样，如果开发者的需求更适合用 Rust、C++ 或原生平台框架来满足，AI 辅助开发也可能让这些方案变得越来越可行。
选择应主要由应用的架构和需求驱动，而不只是取决于开发团队已经掌握的语言。
Flutter 的桌面生态系统仍在追赶
Electron 和 Flutter 都有庞大的开发者社区，但它们的生态系统构成不同。
Electron 的生态系统围绕桌面应用发展了十多年。对于常见的桌面需求，开发者能够找到成熟的库、示例和工具，包括代码签名、自动更新、窗口管理、系统集成、通知和应用分发。
Flutter 通过 pub.dev 拥有丰富的软件包生态系统，但许多软件包最初是为移动应用开发的。并非每个 Flutter 插件都支持 Windows、macOS 和 Linux，而且对这三个桌面平台的支持程度可能各不相同。
当开发者需要嵌入式浏览器视图、操作系统自动化、全局快捷键、媒体设备访问或原生窗口管理等专门功能时，这一点就尤为重要。
例如，Flutter 官方的 webview_flutter 软件包支持 Android、iOS 和 macOS，但不提供官方的 Windows 或 Linux 实现。面向这些平台的开发者需要额外的软件包或自定义集成。
相比之下，Electron 的应用运行时自带 Chromium，并通过自己的 API 直接提供浏览器相关功能。
对于采用常规自定义界面、具有标准平台需求的应用，这种差异影响较小。当应用需要在多个操作系统上提供高级桌面功能或类似浏览器的行为时，这种差异就会更加显著。
Flutter 2026 年开发者调查揭示了什么
Flutter 自身的调查结果，为移动开发与桌面开发之间的成熟度差异提供了有用的证据。
2026 年 8 月，Flutter 团队公布了一项收到超过 3,500 份回复的调查结果。开发者对 Android 开发的满意度明显高于 Windows 或 Linux。
| Flutter 开发领域 | 正面满意度 |
|---|---|
| Dart 语言 | 92% |
| Android 应用开发 | 91% |
| Flutter 核心框架 | 90% |
| Windows 开发 | 74% |
| Linux 开发 | 73% |
| Web 开发 | 72% |
来源：Flutter 2026 年第二季度开发者调查。这些数据代表受访者的满意度，而不是框架使用率或市场份额。
这些数字表明，Flutter 开发者总体上仍然非常满意，尤其是对核心框架和 Android 开发。不过，Windows 和 Linux 开发的得分明显较低。
Flutter 团队明确将桌面多窗口支持列为持续投入的领域之一。
这些结果支持一个更细致的结论：Flutter 是一个成熟的跨平台框架，但其桌面开发体验仍在演进，而这种演进反映了它移动优先的起源。
这些结果中没有可与之直接比较的 Electron 调查，因此不应将这些数字解读为 Electron 开发者普遍更加满意的证据。
应用情况：Electron 立足桌面，Flutter 立足移动
两个框架都得到大型科技组织的支持，并被用于生产应用。不过，它们的采用情况反映了各自不同的起源。
Electron 在主流桌面生产力软件、通信平台、开发工具中尤其常见，也越来越多地出现在 AI 应用中。Flutter 在移动应用中的采用范围广泛得多，其知名桌面产品数量正在增长，但规模仍然较小。
| 应用 | 框架 | 类别 |
|---|---|---|
| Visual Studio Code | Electron | 代码编辑器 |
| Slack | Electron | 通信 |
| Discord | Electron | 通信 |
| Notion | Electron | 生产力 |
| Figma Desktop | Electron | 设计 |
| GitHub Desktop | Electron | 开发工具 |
| Claude Desktop | Electron | AI 助手 |
| ChatGPT Desktop | Electron | AI 助手 |
| AppFlowy | Flutter | 生产力 |
| RustDesk | Flutter | 远程桌面 |
| Ubuntu Desktop Installer | Flutter | 系统实用工具 |
| Ubuntu App Center | Flutter | 应用管理 |
| Google Gemini for Mac | 原生 Swift | AI 助手 |
Microsoft、Salesforce、Anthropic 和 OpenAI 等大公司都选择使用 Electron 开发桌面应用。这些例子展示了该框架在开发、通信、生产力和 AI 软件领域的多样适用性。
Electron 还受益于 OpenJS 基金会所提供的成熟开源治理结构，以及与大型科技公司相关的工程师所作出的贡献。
Google 是 Flutter 的最初开发者和主要支持者，而 Canonical 则在 Flutter 的 Linux 和桌面能力方面投入了大量资源。
不过，即使是 Google，也没有在所有桌面应用中使用 Flutter。
Google 为 Mac 版 Gemini 选择了原生 Swift
一个值得关注的例子是 Google 于 2026 年 4 月推出的官方 macOS 版 Gemini 应用。
Google 团队没有采用 Flutter，而是使用原生 Swift 构建了该应用。Google 的 Gemini 负责人 Josh Woodward 公开表示，这是一款原生 Swift 应用，并称一个小团队在不到 100 天内实现了 100 多项功能。
Google 还表示，AI 辅助开发帮助团队快速完成了从初始构想到原生 Swift 实现的过程。
这说明，即使是一家开发主流跨平台框架的公司，也可能在其他技术更符合产品需求时选择它们。
Gemini macOS 应用强调与 Apple 操作系统的紧密集成，包括全局键盘快捷键、菜单栏功能及其他桌面交互。
选择原生 Swift 并不能证明 Flutter 或 Electron 不适合。Google 尚未公布其考虑过的备选方案的全面比较。
尽管如此，这表明，当平台集成很重要时，原生开发仍然有吸引力，而 AI 辅助工程可以降低使用平台专属语言的部分成本。
与此同时，Flutter 已经证明自己能够支持专业级桌面软件。AppFlowy 使用 Flutter 和 Rust 提供跨平台生产力应用，RustDesk 则将 Flutter 与基于 Rust 的远程桌面功能相结合。Canonical 也已将 Flutter 用于重要的 Ubuntu 组件。
过去，Flutter 最知名的商业成功案例主要集中在移动开发领域，包括 BMW、Nubank 和字节跳动等公司的应用。
对于专门面向桌面平台的开发者，Electron 历史更长，并拥有更成熟的主流桌面应用阵容。Flutter 是一个切实可行的替代选择，但桌面开发是其原有生态系统的扩展，而不是它一直以来的核心。
为什么 WebCatalog 选择 Electron
在 WebCatalog，我们选择 Electron，是因为我们的产品从根本上围绕 Web 应用和浏览器功能构建。
WebCatalog 允许用户将网站转化为桌面应用，独立管理多个账户，并在 macOS、Windows 和 Linux 上整理自己的应用。
与构建常规应用、能够完全控制前端的开发者不同，我们需要支持由数千位不同开发者创建的网站。这些网站可能依赖复杂的身份验证系统、浏览器 API、存储机制、媒体功能和 JavaScript 框架。
对于这一需求，Electron 自带的 Chromium 运行时尤为宝贵。它让我们能够在所有支持的桌面平台上提供一致的浏览器环境。
Flutter 的 UI 架构不包含通用 Chromium 运行时。为了显示网站，Flutter 应用必须集成 WebView 或其他浏览器组件。在不同操作系统上，这些组件可能使用不同的渲染引擎，其能力也可能不同。
对于 WebCatalog 这样的产品，这会带来额外的兼容性和维护挑战。
Electron 还提供成熟的 API，用于管理浏览器会话、Cookie、存储、权限、导航和应用窗口。其持久化会话分区尤为重要，因为它们允许用户为同一个网站维持多个独立的登录会话。
Flutter 或许可以通过插件和原生浏览器集成实现类似功能，但要在 macOS、Windows 和 Linux 上一致地实现并维护相同行为，需要大量额外工程投入。
我们的技术栈也是一个考量因素。WebCatalog 主要使用 JavaScript 和 TypeScript 开发，因此 Electron 自然适合我们团队的专业知识和现有代码库。
不过，熟悉 TypeScript 并不是我们选择 Electron 的主要原因。借助现代 AI 编程工具，采用 Dart 或其他语言，会比几年前容易得多。
如果 Flutter 能为我们的需求提供明显更好的架构，那么无论语言是否不同，我们都有充分理由考虑它。
性能对我们同样重要，但切换框架不一定是提升性能的最佳方式。
Electron 持续进行的性能改进很有价值，因为它们让我们能够受益于更广泛的 Chromium 和 Electron 生态系统中的优化工作。我们不必维护一套完全独立的浏览器集成，而是可以继续基于一个获得大量工程投入的运行时进行开发。
我们也在努力减少自身应用特有的开销。例如，我们引入了 APFS 克隆，以减少生成的 Mac 应用的磁盘占用。
这种方法使我们能够解决实际的资源消耗问题，同时不牺牲对产品至关重要的 Chromium 兼容性和浏览器管理能力。
归根结底，对于 WebCatalog 而言，Electron 面向浏览器的架构、跨平台一致性、成熟的桌面 API 和持续的性能改进，比 Flutter 可能带来的基础资源节省更有价值。
Flutter 的优势所在
尽管 WebCatalog 更偏好 Electron，但对于许多类型的应用来说，Flutter 都可以是绝佳选择。
它最突出的优势，是能够在桌面和移动平台之间共享应用逻辑与界面代码。已经使用 Flutter 开发 Android 和 iOS 应用的公司，通常可以将现有代码库扩展到桌面端，而不必引入一个完全独立的前端框架。
Flutter 也非常适合需要高度自定义界面、复杂动画，以及相对较低运行时开销的应用。
在以下情况下，Flutter 可能是更好的选择：
- 同时构建桌面和移动应用。 Flutter 使用同一个框架支持 Android、iOS、macOS、Windows 和 Linux。
- 扩展现有的 Flutter 移动应用。 开发者可以复用大量代码和专业知识。
- 创建高度自定义的界面。 Flutter 对渲染、布局和动画提供广泛的控制能力。
- 尽量减小应用体积和基础内存占用。 Flutter 不需要捆绑 Chromium 运行时来显示自身界面。
- 开发不严重依赖浏览器功能的产品。 Flutter 提供专门的 UI 框架，不需要 HTML、CSS 或 JavaScript。
- 将运行时效率置于语言熟悉程度之上。 AI 编程助手可以降低采用 Dart 的阻力，让 Flutter 对目前主要使用 JavaScript 的团队更具吸引力。
开发者不应将 Flutter 视为仅适用于移动端的框架。它是一个成熟可靠的多平台工具包，已有用于生产环境的桌面应用，尽管其移动开发生态系统仍然更加成熟。
Electron 与 Flutter：你应该选择哪一个？
两个框架都可以用来构建功能复杂的桌面应用，但它们的架构和生态系统适合不同的需求。
| 你的优先事项 | 更适合的起点 | 原因 |
|---|---|---|
| 桌面优先的应用 | Electron | 成熟的桌面专用 API |
| 现有 Web 应用 | Electron | 复用 HTML、CSS 和 JavaScript |
| 现有 Flutter 移动应用 | Flutter | 共享代码和工具链 |
| 桌面与移动开发 | Flutter | 官方同时支持两者 |
| 较小的应用安装包 | Flutter | UI 无需捆绑 Chromium |
| 较低的基础内存占用 | Flutter | 在可比较的轻量应用中，运行时开销更低 |
| 自定义动画和界面 | Flutter | 专用渲染引擎 |
| 多个应用窗口 | Electron | 成熟的内置 API |
| 显示第三方网站 | Electron | 内置 Chromium |
| 复杂的浏览器会话管理 | Electron | 成熟的会话 API |
| 广泛的 Node.js 集成 | Electron | 内置 Node.js 运行时 |
| 专注于桌面的生态系统 | Electron | 更长的桌面开发历史 |
| 持续受益于基于 Chromium 的性能改进 | Electron | 受益于 Chromium、V8 和 Electron 的优化 |
| 自定义 UI 的运行时效率 | Flutter | 原生编译和专用渲染器 |
| Linux 桌面开发 | 两者皆可 | 两者都正式支持 Linux |
| 已有 Dart 和 Flutter 专业经验 | Flutter | 复用现有工程投入 |
对于围绕现有 Web 技术构建桌面应用的开发者，Electron 通常是更实用的选择。它提供对 Chromium 的直接访问、丰富的桌面集成 API，以及成熟的 JavaScript 生态系统。
对于在桌面和移动平台上构建自定义界面的团队，Flutter 可以提供更统一的架构和更低的基础运行时开销。
AI 编程助手越来越普及，也意味着当不熟悉的技术具有实质性优势时，开发者应将其纳入考虑。如果 Flutter、Dart、Rust 或原生平台语言的技术收益超过维护另一套技术栈的成本，那么选择它们可能是合理的。
希望保留 HTML、CSS 和 JavaScript，同时缩小应用体积的开发者，也可以考虑 Tauri。它使用系统 WebView，而不是 Flutter 的自定义渲染引擎。
最后的思考
Electron 和 Flutter 都是功能强大的跨平台框架，但它们不同的发展历史，有助于解释各自的优势。
Electron 从一开始就是为桌面应用设计的。经过十多年的发展，它已形成成熟的生态系统，涵盖桌面 API、打包工具、原生集成和浏览器管理能力。
Microsoft、Salesforce、Anthropic、OpenAI 和 GitHub 等公司采用 Electron 也具有重要意义。这些公司对 Electron 的使用，体现了它支撑高要求生产应用的能力，而更广泛的工程生态系统则推动着该框架的持续开发和优化。
Electron 的性能随着时间推移已有显著改善，近期版本也表明，降低启动延迟、内存开销、CPU 活动和应用体积，仍然是持续推进的重点。
Flutter 最初是移动框架，后来扩展到桌面开发。它在自定义界面、原生编译和跨平台代码共享方面的优势，使其对那些构建移动优先产品、同时也需要桌面版本的开发者尤其有吸引力。
Flutter 的桌面支持已可用于生产环境，但某些桌面专属能力和插件生态系统的部分领域仍在走向成熟。它持续推进多窗口支持，说明该框架正在不断适应那些原本并非其移动架构核心的需求。
与此同时，AI 辅助开发正在降低编程语言熟悉程度的决定性。开发者越来越能够高效使用 Dart、Rust、Swift 和其他技术，而不必具备过去可能需要的同等程度的专业经验。
在 WebCatalog，我们选择 Electron，是因为我们的产品高度依赖浏览器功能、Web 兼容性和成熟的桌面 API。它持续的性能改进和完善的生态系统进一步强化了这一选择。
对于构建移动优先应用或高度自定义界面的开发者，Flutter 可能是更好的选择。对于围绕 Web 技术构建桌面优先软件的开发者，Electron 仍然是最成熟、最实用的选项之一。
归根结底，开发者应优先选择最能满足产品性能、功能和长期维护需求的架构，而不是依据对资源使用或编程语言熟悉程度的过时假设来选择框架。
