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

systemcall

2023-01-22 18:37:33 +08:00

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

zu1k

2023-01-22 18:51:06 +08:00

微软 electron win11 内置 webview2 你品

liukanshan

2023-01-22 20:54:18 +08:00

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

Ayanokouji

2023-01-22 23:55:02 +08:00

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

secondwtq

2023-01-23 00:38:42 +08:00

其实这个是个政治问题不是技术问题
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 驱动是完全独立的。

ffgrinder

2023-01-23 01:47:55 +08:00

@agagega
@a1knla

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

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

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

akira

2023-01-23 02:24:16 +08:00

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