为什么 Electron 不推出公共运行时？

1

不要指望用户会去主动安装一个什么东西，Windows 下载.NET 运行时这么方便都还有人搞不清

@agagega 记得以前 win 不自带.NET 的时候，如果有软件需要，win 是会给弹窗然后直接一键下载的，用户只需要点一下鼠标，非常的方便，虽然由于各种原因，还是不少用户求助如何装.NET...

版本太碎片化了，万一带了个什么锁版本的原生模块，或者用了什么特性就炸了

我不想让我的用我的软件的时候，再去下载个运行时，纯属给用户添堵

每个应用所需的版本不一定一样，你应该不想安装一个新应用，另一个旧应用挂了。
如果你又想本地保留多个版本，那又会带来新问题，即你的应用删了，你的公共运行库不想删，久而久之它们又会变成垃圾。

@a1knla 大部分应用并不会弹窗遇到各种 dll 报错，或者让你去安装，不用 Google 微软官网都找不到，每次都要在下载站找

DLL Hell 了解下

Go 为什么一开始把静态编译当卖点

比起出各种奇奇怪怪的问题折腾来， 百来 MB 空间简直不要钱一样

@oott123 @kaneg 感谢，我知道 node_modules 肯定是不能共享，我主要是不理解，js 解释器这种极其底层的东西也需要人手一个吗

以前 aur 有些应用就是共用系统的全局 electron 的，但是自然也会经常遇到不兼容的问题，现在不知道还有没有了。

现在的游戏动不动都几十上百 G ，没必要为了这几百 MB 的容量经常花时间处理兼容问题，有这时间打游戏不香嘛

@westoy @Bingchunmoli 感谢，每个 app 的依赖确实应当跟着打包进去，但是举例来说，win 中也存在 user32.dll 这样的 非常底层的库，很少见有自带的吧，对 electron app 来说，我猜 js 解释器应该就是这种底层的东西，如果把它抽离出来，或许也是能缩小包体的

没有公共运行时是个 feature ，为什么要把 feature 去掉？

@a1knla 没这么底层，一定要说，它可能还不如 JVM 结实，起码人家的二进制接口非常稳定。和 user32 对标的，大概是 glibc 了，即使如此 Linux 上也常常出问题

以前 jQuery 流行时也有讨论说为什么浏览器不内置，完全想不到几年后 jQuery 就淘汰了。

不要用现在的经验去看当时的问题。

1：当时的几个需要用户安装运行时的前辈要么已经死了、要么正在死去，比如 flash 、adobe air ？（忘了具体名字）、silverlight 。

2：当你电脑上有十个 electron 软件时，你觉得应该有一个公共运行时。但回到 electron 刚诞生时，ab 两个新软件，a 是绿色的下载就能运行，b 却需要先安装一个没听过的运行时污染你的系统，你会选哪个？

兼容问题是结果而非原因：如果当初 electron 是全局运行时的模式（而且奇迹般的流行开来），开发者在开发时自然会对齐版本、考虑兼容性（不过我觉得这样肯定不会让开发者喜欢）。

.net 有个好爹，不是 electron 这种野生动物可比的，而且就算好爹也救不了 Silverlight 。

@ochatokori @binux @iseki @sun1991 @runze 明白了，感谢解答！

不要高估了普通人的知识水平和理性程度。.NET 运行时很方便，然而非程序员团体能弄明白这玩意的很少，而且软件下载完普通人打开发现还需要再下载个什么东西，这些人会不耐烦，比起稍费一点力“折腾”这一下，他们可能更喜欢贡献一点硬盘。
这也说明了为什么有些大得像操作系统的软件一样有人用。

@sun1991 #14 其实也已经内置了，dom 上的那些 api 多少有 jquery 的影子

我觉得很多人没回答到点上。electron 笼统地说可以分为 3 部分：界面渲染内嵌 chromium 、后台运行环境内嵌 nodejs 、用 c++写的跨平台 api(例如 dialog)。

单说渲染用的 webview 吧，完全能独立出来，现在 win10 上的 edge 也剥离了一个叫 webview2 runtime 的东西，貌似 linux 上有个包 lib-webview 。

这相当于 denpendency ，存在版本问题。对于普通用户，可能还需要额外的步骤（门槛）。就用户体验而言，安装即用是最佳的，和市面上大部分公司的应用一样

要公共的运行时，你可以用 tauri ，甚至对于许多软件来说，你可以直接给 Web 端
electron 很多时候性能比一般的浏览器更低，因为许多开发者会关闭 GPU 加速等功能，来减少他们遇到的 bug

微软 electron win11 内置 webview2 你品

当时也有那么一群人不理解，所以创建了 tauri 。

服务端都不想用公共运行时，一个 docker image 一个 jdk ，还想客户端用公共运行时

其实这个是个政治问题不是技术问题
Electron 的好处之一，就是它提供了一个较为确定的虚拟机，并且它是 Electron 应用开发者完全可控的，应用开发者只需要绑定一份 Electron ，就可以确定应用在最终用户系统上的行为是基本一致的。开发者还可能对 Electron 进行一些定制来满足一些特殊的需求。说白了就是：我既要跨平台，我又要稳定，还要低成本，最后要可控，Electron 提供这么一个方案。但是你知道这是计算机，那么古尔丹，代价是什么？就是你每个应用都得带一份，把成本转嫁到用户上。
采用公共运行时的形式，就意味着应用开发者失去了对虚拟机这一层的控制。这自然会削弱 Electron 的优势。

楼主说的“公共运行时”的形态并不是完全不行，比如我现在用的 Arch Linux ，就把 Electron 单独打了一个包，然后 VSCode 依赖这个包。虽然因为我只装了 VSCode 一个 Electron 应用所以这个形式在我这聊胜于无，但是应该很接近楼主想要的状态了。这个包还分为 17-22 等不同版本，颇有 .NET 风范。可以说 Arch Linux 已经“一国建成社会主义”了。
当然上一个“一国建成社会主义”的现在已经凉了，Arch Linux 的实际状况也并非上面说的这么好。比如 VTune 也用了 Electron ，作为一个闭源软件，很难确定是不是能用包里提供的 Electron 替换上去（而且最丧心病狂的是这货似乎把 Electron 的文件打包进了 executable 里面），网易云音乐和 Steam 用的是 CEF ，这东西“本质上”跟 Electron 差不多，但是你也没办法把它搞出来做成公共运行时，同时装这俩最后还是两份 CEF 。
类似地你会发现，比如 Qt 也是个很适合做成公共运行时的东西，但是很多 Qt 软件就喜欢在发布时带上一份 Qt ，这里 Qt 扮演了和 Electron 十分类似的角色。而出现这种现象的绝大多数都是闭源软件，闭源软件追求绝对的稳定和收入，是绝对不会放过任何一个“增强稳定性”的机会的，如果不是在 Windows 上微软强制 .NET 必须通过系统级的方式安装，他们绝对会自己把 .NET 的所有文件带上来分发的。对于开源软件而言，社区本来就是它的一部分，所以如何更好地融入用户系统也是开源软件开发的重要考量。

然后考虑楼主的比如“把 JS 解释器抠出来”之类的提案，这里要考虑的历史背景是 Electron/CEF 等都是基于 Chromium 项目的，Google 开发 Chromium 项目的初衷是做 Chrome 浏览器，Chromium 项目本身和 V8 引擎是深度绑定的，对于 Google 来说，不存在把 Chromium 和 V8 解绑的动机——人家一开始做这个就是为了不受 WebKit 制约，能自己乱搞，而不是要做得多模块化，这个和 Electron 开发者用 Electron 的原因倒是很像。就算有人做好了给 Google 端上来可能人家都懒得 merge 。

最后，开源软件就真的完美了么？还是作为一个 Arch Linux 用户，我现在机器里有 OpenSSL ，GnuTLS ，Mbed TLS ，wolfSSL 至少四个 TLS 库，Expat ，libXML2 ，TinyXML ，pugixml 至少四个 XML 库，json-c ，jsoncpp ，Jansson ，RapidJSON 至少四个 JSON 库，至于浏览器引擎，除了上面提到的 Electron 和 CEF ，还有 Firefox 自己的一份，Chromium 自己的一份，WebKitGTK ，QtWebKit ，QtWebEngine ... 上面这所有的软件，除了两个浏览器之外我没有主动安装它们，它们都是不同的包依赖的。
我觉得楼主问题的根本逻辑可以简要地概括成：不同软件中的“重复”能否完全消除？答案我觉得上面已经很明显了 ... 这远远不是 Electron 自己的问题。

最后一个有趣的现象：对桌面 Linux 有点了解的应该知道目前 NVIDIA 官方的用户驱动是闭源的，这背后不仅仅是 NVIDIA 的开源战略问题——目前 Linux/FreeBSD 上几乎所有的开源 GPU 驱动，都是基于 Mesa 3D 这一套框架做的，这个意思是，不同 GPU 的驱动只需要写和硬件直接相关的部分，而处理 API 和 Shader 编译前端之类的硬件无关部分由 Mesa 框架负责，这个架构可以做到在 *不同公司、不同硬件、同一系统* 上驱动代码的复用。类似的东西在 Windows 上也有，叫 WDDM 。
这个是开源社区的角度，而 GPU 厂商，比如 NVIDIA 的角度可能是不一样的，先不考虑是否开源的问题，它们需要解决的，是需要实现一个跨平台的驱动，也就是 *同一公司、不同硬件、不同系统* 上驱动代码的复用。这样可以推断 NVIDIA 内部可能有另一个框架，它将操作系统和一部分 API 的差异抽象出来，后面主要处理不同代硬件之间的差异。
也就是说 Windows 上 N 卡的 OpenGL/Vulkan 驱动可能和 Linux 上的专有驱动，甚至可能还有之前 Mac 上的驱动共享了很大部分代码——但是不会是 Mesa 的。NVIDIA 不会使用 Mesa 这套东西，一方面是它主要面向部分平台（ Mesa 并不是不能在 Windows 上跑，不过主要还是做 Linux 和 BSD 的），另一个是它是社区的东西不可控，可能也不是完全适合它的硬件。
当然作为一个闭源的东西，我做的只是推断。不过一个旁证是目前 NVIDIA 放出的所有与硬件相关的开源信息，其表述的动机都是“供开源开发者参考来开发另一套开源驱动”，包括前段时间的开源内核驱动在内，NVIDIA 从来没有表达过把它自己的这一套东西和开源社区原有的项目在代码层面直接融合的想法。类似地 AMD 可能也有这么一套东西（虽然大家都说 AMD 在 Linux 下的开源驱动做得好，不过人家自己也有一个 Linux 闭源驱动的），Mali ，Adreno 之类的可能也有。Intel 在 Linux 下只有官方开发的基于 Mesa 的开源驱动，所以可能 Windows 驱动是完全独立的。

@agagega
@a1knla

你们记错了，Windows 只会报错，只有用了标准的打包程序（这个词我不知道是否专业，比如.msi ）。才会在安装的时候提示你下载.NET Framework 。VC 运行库就更别提了，至今还有一些傻缺程序只报告缺少 dll 。

例如.NET Framework 会报错 0xc0000135 ，然后你需要百度或者 google （当年还没有被墙），知道自己缺一个.net framework 。还要下载正确的版本，这你就要知道你的系统安装了什么版本而你需要哪个更高的版本，当年出.NET Framework 2.7/3/3.5 的时候这个问题恶心了我好多次。

想想当年的网络环境，你觉得大部分人能完成这项工作吗？现在很多电脑使用者也未必可以完成。

一个是兼容性问题，另一个是 最好把用户视为不会电脑的小白