Electron 真的是软件体验的原罪吗？

讨论分享
, ,
1

最近在准备发布自己的桌面版软件 DaoBox，一个本地 Markdown 文件知识库，改进版 Markdown 笔记/发布工具

但看到不少讨论“讨厌套壳软件”的帖子，我自己是做开发的，反而有点想不明白：为什么很多人会如此排斥基于 Electron 开发的软件？

我能理解大家对资源占用的在意。Electron 确实有比较明显的成本，比如一个简单应用可能启动就要占掉 100MB 左右的内存，安装包也可能从几十 MB 起步。

但我一直有个疑问：

现在的电脑，50MB 和 200MB 的磁盘空间，真的会成为决定一个软件“用不用”的重要因素吗？

内存可能更值得关注一些。但如果一个软件本身就有一定复杂度，需要编辑器、搜索、同步、数据库、插件等功能，那么即使不用 Electron，内存占用也未必会小到哪里去。

而且从我个人实际使用和开发的经验来看，软件最终影响体验的，似乎还是：

  • 有没有真正解决我的需求
  • 稳定不稳定
  • 流畅不流畅
  • 功能是否好用
  • 长时间运行是否可靠

至于它到底占 100MB、300MB，还是 500MB，我反而没有那么敏感。

当然，如果两个软件功能、体验、稳定性完全一样，一个只占 50MB，另一个占 500MB，我肯定选前者。

但如果一个软件很好用、稳定、流畅，只因为它是 Electron 做的，安装包大了一些、内存多占了一些，就因此拒绝使用，我就有点理解不了。

所以我比较好奇：

大家真正讨厌的是 Electron，还是“做得很差却拿 Electron 当借口的套壳软件”？

或者说，在今天的硬件条件下，大家对软件资源占用的容忍度到底在哪里？

2 个赞
都来交代一下你最喜爱的 Electron 软件
2

抵制的其实是杀鸡用牛刀

再就是你说的，有更小的平替那肯定不会用electron写的

9 个赞
3

不讨厌，但是当你装了20+套壳软件时，会不会觉得有些奇怪。

2 个赞
4

只要写过程序，就肯定知道，程序代码或者说逻辑编译后只占极小的二进制体积，相比gui框架的占用不值一提；对内存占用来说逻辑部分和gui框架部分区别虽然没那么大（对其他轻量gui来说），但是electron绝对算是占用内存庞大的那类。不管在内存占用还是打包体积上来说，electron都是浪费最严重的那类（你还能举出个更差的例子吗？）。

当然electron也不是一无是处，它有它自己的优点（虽然在我这里没有）。很多人没搞明白它的使用场景，用这么庞大低效的框架去做一个目标是常驻后台的，随呼随用的快速工具，是不是有点幽默了？

10 个赞
5

不知道，我用 electron 和 tauri 的原因就是，跨平台，有更新软件的api。
如果我专注于去做windows的软件，我还是会选 C#。

6

这就是重点。
不同的UI框架提供的接口和组件丰富程度不同，开发者有必要根据自己的软件架构选择恰到好处的UI框架而不是去追求大而全。
Electron就是这么一个大而全的框架，因为其脱胎于浏览器，所以其强处在于多样化的交互能力、多线程安全隔离、高自由度（依赖网页渲染）的界面设计，相应的代价就是偏大的安装包和运行时空间占用、套娃式进程调度和高能耗的界面渲染。
因此，有必要使用这样的能力的，应该是界面复杂度高、显示内容需大量动态调整、交互元素类型众多的软件，主流集成聊天功能的办公软件都选择Electron（魔改）都是出于这样的需要；
要是内容编辑上需要网页渲染而工具界面上不需要（无大量动态调整），则用简单一点的框架写界面，编辑框调用经精简的浏览器内核就可以了；
要是基本没动态变化，顶多就是有些列表，大可以组合基本控件来达成；
总之，没必要给一个道岔穿黄金战衣。

4 个赞
7

其实磁盘占用是其次， 使用上， 最直观的感觉，其实是内存占用太大了， 而且electron软件（也包括tauri等其他的web技术栈的软件）轻微内存泄露特别常见。
我感觉我用过的，基于 web 技术栈的 GUI软件工具里， 至少有70%（或者说一半多），存在，或者曾经存在过内存占用相关的问题， 尤其典型的是，内存泄露问题。具体来说，只要软件开着，内存占用就会不断膨胀。只是很多软件膨胀的其实很慢，即使你一直不退出，也可能要好几天才会膨胀到让你注意到的程度。
但我电脑使用习惯是7x24不关机的，所以，时长就会发现某个不知名软件忘了退出，而现在这个软件吃掉了巨大的内存。（甚至知名软件也会出现有内存泄露问题的版本，比如经典的 网易云音乐，很多个版本都有过内存泄漏，然后某几个版本修复了，但过几个版本又会出现）

于是， 虽然我只是业余的半桶水，但我觉得，这其实不算是开发者做的很差， 这是web前端技术栈的屎山造成的。
除非自己手搓一个精简的前端，不使用强大的框架和生态中的包，不然只要你用web前端那一坨抽象底层架构， 那么就你很难保证你最终的产物不会遇到同样的问题。

毕竟，前端技术栈发展的方式就是如此， 前端对于代码的要求天生就没有这么严谨，再叠加浏览器版本兼容/利用版本特性的小巧思等的各种“黑魔法”之后， 潜在的问题实在是太多了，你并不知道你引入依赖地狱里，都有什么牛鬼蛇神（更不要说供应链投毒了）。

当然， 我不是牛逼的前端工程师，只是业务折腾学习过（还是比较早的时候，在有各种AI大模型agent之前，真的手工学习过）只能说，作为业余观众水平的用户，我觉得， 这就是某种前端技术栈的“原罪”。

毕竟你如果真的放弃这一大坨所谓脚手架，真的手搓原教旨主义的 html/css/js, 那其实和基于xml的比如qt，dotnet的一些技术相比，也没啥优势了。

3 个赞
8

大胆点，原生js也是一坨屎山，整个前端完全陷入了路径依赖里

9

electron就是恶心， 只适合快速开发， 根本不能当做成熟的软件。

所有的界面，响应都基于web， 摆脱不了web的粘连感

更有甚者右键还能点出来浏览器的右键菜单

3 个赞
10

对啊，都是web界面，为什么就不能做成浏览器打开？非得让大家电脑里多装点浏览器

3 个赞
11

虽然现在内存条价格上天,但是真的只是多用100M内存也就罢了,问题是不止是100M的差别.
另外你都用web技术了,那做个网页版也不过分吧?还能少套浏览器壳.
不不不 问题就是往往并没有网页版.

4 个赞
12

我就是讨厌Electron，以及CEF等所有类似技术。某些群体吹爆的Steam客户端，在我看来烂透了。

如果是Unity，那可能还有分辨是Unity差还是开发者差的必要，因为虽然都是经常和跨平台的屎一起出现，但用途不同，Unity开发的产物通常是游戏，在运行期间用户对于其他软件的需求会大大缩减，所以对Unity的容忍程度，通常主要取决于对风扇噪音和劣质美术资源的容忍度，开发者水平高一些确实会好很多。

但是Electron不一样，Electron 的适用范围非常窄，它的优势与缺陷之间关联过于紧密。

它确实解决了一些精美界面的开发成本问题，但天生的粘滞感也是它的重要缺陷之一。有GPU加速的Electron也比不上纯软件渲染的WinForm快，那凭什么会有人想用它给需要频繁操作的软件写UI？所以从这个角度来说，它更适合给那些调整完设置之后，就保持后台运行的服务用。

但是既然操作频率很低了，那很多用户也就不会为了爽那几十秒，而去把硬盘和内存凭空消耗掉200MB*114514，所以有人宁可界面简洁一些，有人倾向于选择web。而且使用GPU加速的软件越多（不只是electron，但每一份electron都应该视作不同的软件），遇到GPU相关bug的风险也会增加，办公没感觉（至少放在2026年的反应不会像十年前那么强烈），但是网游玩家就炸了，特别是现在的游戏讲究利用碎片化时间，不再面向长时间在线而设计游戏机制，游戏重启再快也是不可接受的慢。

建议所有偏好Electron的开发者都只为MacOS开发软件，因为Mac自己就有一些响应慢的问题，所以Mac用户长期接受各种遮羞布教育，且没有游戏的需求，天然更适合Electron软件。Windows这一堆人连Windows10的响应速度都不满意，期待Windows11完成用户教育几乎是不可能的事情。用Electron开发只能覆盖那些从移动互联网时代成长起来的小朋友，奔三奔四奔五的老登们不喜欢。如果坚持Electron做全平台开发，就去找虽然用Electron开发会很卡但需求复杂到竞争对手很少，又或者界面复杂到可以把其他框架拖到一样迟缓的大型项目，那很容易就超出独立开发者能处理的工作量。

一个能将就用的排版效果，以及降低图片解码的内存消耗不太容易，可能比数据库开销更能让人接受你选择Electron。个人知识库应该不会让数据库吃掉太明显的CPU和内存。

6 个赞
13

即便为了跨平台, electron也不是唯一选项, 更不是对于用户最优选项
比如RSS阅读器, 显然需要浏览器功能吧, QuiteRSS, 两万记录, 只用单进程, 400M内存.
甚至, 仅编译win版, 都能跨平台, Linux有wine, mac有parallels
多开几个electron软件,开销赶得上虚拟机了, 离谱
Markdown本来就一个富文本工具, 对标的应该是写字板/Wordpad, 不渲染的话, 对标的是记事本/notepad
本身就是HTML的下位替代, 为了方便直接阅读才用的, 结果查看/编辑起来还得用浏览器, 那为何不直接用所见即所得的HTML编辑器得了, 比如seamonkey的话单进程200M内存就搞定了.
即便套壳浏览器, Markdown这种程度的活, 只有electron一种选项? IE/firefox/旧opera都比electron轻啊
你相信一个套壳electron的记事本,能比notepad好用\稳定\流畅?
同样功能的软件一个原生的,一个electron的, 你自己对比一下啊, 迅雷和utorrent/fdm的启动速度说差三四倍都是少的, 流畅还是卡顿一看便知

主要是看功能, 如果相对功能, 这点性能开销值得的话, 是合理的
但目前, 我开机启动的, 任务栏常驻的, 没有一个electron应用, 不得不用的, 比如各家网盘/steam, 也没有后台服务, 用完就关

用PC的, 不会只开一个软件的, 少量的electron,可以, 什么软件都electron, 不可以

3 个赞
14

你没问题，一般用户只在意软件是否好用，不在意你用什么技术（或者说不懂这方面）。

用软件有点像去饭店吃饭，有多少人会纠结厨师用的是燃气灶还是电磁炉呢？出菜不要太慢，饭菜合胃口就好啦。

不用 Electron 只是少部分极客用户的需求。

做软件无法满足所有人的需求。如果花大精力满足少部分人的需求，可能收益不大。

15

肯定不是原罪，但是又大又占内存，又没啥独一档的功能，别人为啥要用？

16

不喜欢它的分发方式，为什么不能像java一样呢，我电脑上安装了运行环境，双击jar文件就能启动。现在的分发方式相当于一个软件嵌入了一个浏览器，我又不是只使用这一个软件。

17

感觉用electron相当于你去饭店点的每道菜都附赠了一份餐具、一份主食，强制收费还不能不要

18

这正是 Electron 解决的问题。

Chromium 每两周一个版本，谁知道你本地电脑用的是什么版本？有的用户的 webview 千年不更新一次。

怎么保证没有环境问题？自带一个呗。

1 个赞
19

非常赞同

20

有很多原因，其中最重要的两个：

  1. 浏览器是沙盒。浏览器做了很多安全限制。比如在 File API 出现之前，浏览器都不能读取/修改本地文件。
  2. 复杂度不会消失，只会转移。用户的浏览器引擎的版本必定是参差不齐的，那么你的业务代码要么做大量 polyfill，要么用极其低版本的 API，这样复杂度就转移到业务代码上了。而且这也是不能解决问题，一定有用户用着千年以前的浏览器引擎，在他的环境必定无法运行。

总之，桌面软件不是 Web，软件就是软件，就算桌面软件使用了 Web 技术栈，其底层的设计哲学不同，必定导致产品形态大相径庭。

1 个赞