🖥️ Electron 与桌面端

一句话定性

Electron 是前端最”暴力”的一次扩张:它不抹平桌面平台的差异,而是直接把整个浏览器内核 + Node 运行时一起打包进每个 App。代价是”每个 App 都背着一个浏览器”,收益是”会写网页就能写桌面应用”。VS Code、Slack、Discord 用它建起了一个时代,而 Tauri 正用”系统自带 WebView + Rust”对这套臃肿发起轻量化挑战。

一、它是什么 & 出现的时代

2013 年,GitHub 为开发 Atom 编辑器而造了 Electron(初名 Atom Shell)。它的配方简单到近乎粗暴:

Electron = Chromium + Node.js + 原生 API 胶水

  ┌─────────────────────────────────────┐
  │            一个 Electron App          │
  │  ┌────────────────┐  ┌─────────────┐ │
  │  │  Chromium 渲染   │  │  Node.js     │ │
  │  │  (你的 HTML/CSS │  │  主进程       │ │
  │  │   /JS 界面)     │←→│ (文件系统/    │ │
  │  │  渲染进程        │  │  系统调用)    │ │
  │  └────────────────┘  └─────────────┘ │
  └─────────────────────────────────────┘

渲染进程用 Chromium 跑你的前端代码(界面就是一个网页),主进程用 Node.js 提供文件系统、菜单、窗口、系统托盘等桌面能力,两者通过 IPC 通信。于是写桌面应用 = 写网页 + 调几个 Node API。

它生于 2013-2018 SPA时代,和 React 同年——这并非巧合:正是 SPA 让”用 Web 技术构建复杂应用 UI”成为现实,才让”那为什么不能用它做桌面应用”变得顺理成章。

二、为什么会出现(解决上一代什么痛点)

传统桌面开发的"三遍地狱"

三套技术栈、三个团队:Windows(C#/WPF)、macOS(Objective-C/Cocoa)、Linux(GTK/Qt)——做一个跨平台桌面软件,要么学三套 GUI 框架,要么用 Qt 这类重型 C++ 框架,门槛极高。

前端技能再次被锁在门外:公司有成熟的前端团队和 Web 版产品,却无法直接拿来做桌面客户端。

Web 应用想要”更近一步”:Slack、邮件客户端这类产品,既想保留 Web 的快速迭代,又想要桌面应用的常驻、通知、文件访问能力。

Electron 的回答和它的跨端兄弟们一脉相承(见跨端与全栈演进史):用一套 Web 技能栈征服一个新平台。 区别在于手段最直接——不抹平差异,而是把浏览器本身搬过去。 既然每个平台都能跑 Chromium,那我就让每个 App 自带一个 Chromium,平台差异问题被”内置一个统一运行时”一笔勾销。

三、核心机制 & 为什么流行

机制:打包一个完整运行时

与 React Native 的”映射到原生组件”、小程序的”受限 WebView”不同,Electron 走的是最省事也最重的路:每个 App 内置完整的 Chromium + Node。好处是行为完全可控、和开发时的浏览器完全一致、能力无限制(直接拿 Node 全部能力)。

为什么流行:它建起了一个时代

Electron 撑起的"现代桌面应用半壁江山"

VS Code(微软):证明了 Electron 能做出高性能、被开发者每天重度使用的专业工具——这是对”Electron 只能做玩具”质疑的最有力反驳。

Slack / Discord / Notion / Figma(部分):这些定义了现代协作工具的产品,几乎全是 Electron。

核心吸引力:一份代码库,同时产出 Web 版和 Windows/macOS/Linux 桌面版;前端团队无缝接管桌面开发;Web 的迭代速度带进桌面。

这就是跨端母题的胜利:复用 Web 技能,把交付边界从浏览器推到了操作系统。

四、带来的新问题 / 副作用

"每个 App 都带一个浏览器"的原罪

内存与体积爆炸:每个 Electron App 自带一个 Chromium,装一个简单聊天工具几百兆、吃几百兆内存成了常态。开十个 Electron App 等于开了十个浏览器内核。这是 Electron 被嘲讽最多的一点。

资源重复:十个 Electron 应用 = 十份几乎相同的 Chromium 二进制,磁盘和内存被极度浪费。

性能天花板:再优化也隔着一层 Web 渲染,做不到原生级别的极致性能与系统贴合度。

安全面扩大:把功能强大的 Node 能力和加载远程内容的 Web 渲染放在一起,若 IPC/隔离配置不当,容易引入远程代码执行风险(Electron 为此不断加强 contextIsolation 等安全默认值)。

“不够原生”的观感:菜单、滚动、快捷键等细节默认偏离平台原生习惯,需要额外打磨。

第一性原理拷问:为了”复用 Web 技能”,让每个用户的机器上躺着十几个重复的浏览器内核,这笔账在资源稀缺的设备上还划算吗? 这个质疑,直接催生了挑战者。

五、为什么会衰落 / 现状

Electron 没有衰落,仍是桌面跨端的事实标准,但它第一次遇到了认真的挑战者——Tauri。

Tauri:对 Electron 原罪的正面回应
Tauri 的核心选择,精准针对 Electron 的两大原罪:

不打包 Chromium,改用系统自带的 WebView(Windows 的 WebView2、macOS 的 WKWebView)——App 体积从几百兆降到几兆,内存占用大幅下降。

后端用 Rust 而非 Node 写原生层——更安全、更省内存、性能更好。
           Electron                  Tauri
  ──────────────────────    ──────────────────────
  内置 Chromium(几百MB)      用系统 WebView(几MB)
  主进程用 Node.js           原生层用 Rust
  行为完全一致、最稳         体积小、省内存、更安全
         ▲                          ▲
    "稳但臃肿"               "轻但要面对各系统WebView差异"
Tauri 的代价(抽象泄漏的回归):用系统 WebView 意味着又要面对各平台 WebView 的渲染差异——这恰恰是 Electron 当初通过”内置统一 Chromium”想消灭的问题。历史在此打了个回旋:Electron 用”重”换”一致”,Tauri 用”轻”换回了”碎片化”。 这正是跨端母题里”复用/统一 vs. 轻量/原生”光谱的又一次摆动。

现状格局:

Electron:成熟、稳定、生态最全,大型专业应用(VS Code 等)的首选,胜在确定性。
Tauri:新项目、对体积/资源敏感、团队能接受 Rust 的场景里快速增长。
两者并存,体现的正是跨端永恒的权衡:用确定性和复用换体积,还是用体积和碎片化换轻量。

六、对后续技术的影响(因果链)

传统桌面开发"三套GUI、三个团队"的痛点 + SPA 让 Web 能做复杂 UI
        │
        ↓
Electron(2013):Chromium + Node 打包进每个 App
        │  "不抹平差异, 直接把浏览器搬过去"
        │
        ├─► VS Code/Slack/Discord ──► 撑起现代桌面应用半壁江山
        │       └─► 证明 Web 技术能做重度专业工具
        │
        ├─► 原罪:每个App带一个浏览器 ──► 内存/体积爆炸
        │       │
        │       ↓
        │   Tauri:系统WebView + Rust ──► 体积几MB, 省内存
        │       └─► 代价:又要面对各系统WebView差异(碎片化回归)
        │
        └─► 印证跨端永恒光谱:统一/复用 ←──────► 轻量/原生
                                  (Electron)   (Tauri)

历史地位

Electron 是前端横向扩张的第三块殖民地(继移动端、小程序之后,征服桌面端)。它用最直接的手段——“把浏览器搬过去”——证明了 Web 技术栈足以构建被全世界开发者每天重度依赖的专业软件。而它的”原罪”催生的 Tauri,则让”复用 vs. 轻量”的古老张力在桌面端再演一遍。整部跨端史,就是这个张力在不同平台上反复摆动的历史。

前端技术演化史

探索

Electron与桌面端

🖥️ Electron 与桌面端

一、它是什么 & 出现的时代

二、为什么会出现(解决上一代什么痛点)

三、核心机制 & 为什么流行

机制:打包一个完整运行时

为什么流行:它建起了一个时代

四、带来的新问题 / 副作用

五、为什么会衰落 / 现状

六、对后续技术的影响(因果链)

关系图谱

目录

反向链接