电脑里的 Chromium/CEF/Electron 越来越多了

[nyanyh]

Chromium
Steam
VSCode
Docker 里面带的 Docker Desktop
Postman
Unity Hub
Notion
微信开发者工具（ nw.js ）
英雄联盟客户端

一个个功能没多复杂，程序大小 300M 起步
为什么不做一个 Electron Runtime，所有程序共享

[reself]

@runze 哈哈这两个贴子成镜像问题了

[nyanyh]

@charlie21 #61 以前联盟客户端还是 Air 做的时候就卡的不行，现在换成 CEF 了，还是卡……

[runze]

@reself #81 这就是个围城

[crella]

其实感觉 gtk 挺好的，用过 geany，scite 在 linux 上也是 gtk 画界面。

geany 对标 kate，kate on windows 不是一般地卡……

[nyanyh]

@reself #81 我也发现了那个贴子
要是几个几 M 大小的就算了，很多个 app 都带几百 M 的 runtime，这几个 runtime 之间也许没有很大区别，却占用大量空间，这是一种很差的设计

[liyuhang]

@g00001 虽然喷点奇特，但不可否认这是大部分中文网站的通病了

[mgrddsj]

@rwalle #40 看到这帖马上就想到那一堆 Microsoft Visual C++ 20xx Redistributable - x86/x64, 作为用户是真的头大。每个软件都用不同版本的 Redist, 那就跟软件自己带一个运行库没有区别了。卸载软件时，Redist 还不会自动卸载，而且 Windows 还没有原生的包管理器，用户也不知道哪个软件依赖哪个版本的 redist, 导致又不敢乱卸载，反而还更占空间。

[LokiSharp]

@g00001 #78 ”aardio 可不仅仅只是个封装，例如他的界面库，没有像其他编程语言一样用到第三方的界面库，而是用纯 aardio 源码实现的，不像 Python 这些要用到 C++，所以你的理解有很大的误差。
“？？？你确定？你的意思是他的界面库不用调用 Windows 的 C++ API，还是说用 Python 标准库 tkinter 需要写 C++ 代码？

请你解释一下他加载的这么多 dll 是什么？？？或者是你想说调用系统的 API 不是用第三方软件库而是第一方软件库是吧？（滑稽

[reself]

@runze 目前体验感觉比较好的是：入了仓库 /源的软件用系统包管理器处理依赖。独立发布的软件最好将依赖一起打包或者编译成静态。

[augustheart]

看你们争论这么热烈，我突然想义务推广 miniblink 了。
顺便：这个不是我写的，作者我也不熟，就是碰巧在一个群里，而且在群里也几乎没直接交流过……
electron 这套东西的形式就是有问题，没得辩，只是大家都太懒，抱着一大坨够凑合就行。

[augustheart]

@LokiSharp 虽然 aardio 我也没接触过（听说过，但是没放心上，也没兴趣了解），但我不得不说，你对编程一无所知……

[LokiSharp]

@augustheart #91 我反驳的是他说的 aardio 不仅仅只是个封装，而是用纯 aardio 源码实现的，谢谢。

我想表达的是他和其他变成语言一样，都是对系统 API 的封装。

[DOLLOR]

vc2005sp1_redist_x86
vc2008_redist_x64
vc2008_redist_x86
vc2010_redist_x64
vc2010_redist_x86
vc2013_redist_x64
vc2013_redist_x86
vc2015_redist_x64
vc2015_redist_x86
vc2017_redist_x64
vc2017_redist_x86
dotnetfx35
net framework47
jre-7u17-windows-x64
jre-7u17-windows-i586
……
以前部署客户端经常要另外一大堆恶心的依赖，有些还挑小版本，太麻烦了。现在再看 Electron 自带 runtime 感觉反而才是最轻松方便的，反正硬盘不值钱。

[sc3263]

@nyanyh 虽然说都是基于 Chromium 内核，但 CEF 和 Electron 的上层封装完全不一样，无法复用。
即使使用同样的库，为了实现特殊需求，各家公司也会基于官方版本做一些小改动。比如说 Steam 用的 CEF，其实是自己定制的版本。不同的定制化版本之间也无法复用。
就算大家用的都是官方版本，但各家使用的 runtime 版本也不会一致。对于这种每一两周就会出更新一个稳定版的框架，要求开发商去适配自家的软件在各个版本的 runtime 下都能稳定运行是不现实的。甚至保证能在 runtime 最新版本下稳定运行这件事，都是很奢侈的。
最有可能实现的复用方案，就是楼上提到的 Microsoft Visual C++ Redistributable 那种，各个版本的 runtime 都来一份。然后期待某两个开发商的软件，用的 runtime 是同一个版本，能省下小几百兆的硬盘空间。

[songer]

@g00001 上面那个老哥明显是为了喷而喷，不用理他。个人挺喜欢 aauto 的，都是工具好用就行，

[augustheart]

@LokiSharp 在任何操作系统下面编写应用的，你找得出不使用系统接口的存在么？写个 bios 都还得调硬件接口……
他说话的意思还是很好懂的，基本上就是说我的界面是我自己拿自己的代码堆出来的，控件都是自己的语言画出来的，不像 python 下面界面编程用 tcl，qt 什么的。至于他指的东西是自绘还是直接 win 控件我也不知道，但是反正他自己凑出一套自己的界面库了。
不过你们两个一开始就不对付，然后……

[jiejiss]

Electron 官方曾经参与讨论过类似 Java Runtime 的解决方案，并选择不采纳该方案。

https://github.com/electron/electron/issues/2003#issuecomment-371774017

[jiejiss]

@jiejiss #96 更正：选择暂时不采纳该方案。

在 https://github.com/electron/electron/issues/673 这个 issue 里，能看到完整的讨论。

[augustheart]

@g00001 nullsoft 那套东西也超级小。没错，就是做安装包的那个 nsis

[hst001]

听游戏界的大佬们说，九几年那会开发游戏，为了优化可谓绞尽脑汁，使上浑身解数，用尽各种奇淫巧计来优化 CPU/内存 /存储各个方面，因为硬件性能太太太太差了。转眼看看现在，很多电脑性能过剩，游戏开发也开始大胆起来了，除非真的影响到体验，一般优化也就那样了，看看动作上百 G 的文件，这里有多少其实是实际用不到的？不过我们其实也不必在乎，因为这某种程度降低了开发成本，使得我们可以构建更复杂的应用 /游戏来应对更复杂的需求和任务，这就是进步，所以不要在意这点资源的浪费！