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

天下苦 XX 久矣

微软有个 WebView 2，基于 Chromium 内核的 Edge，不知道什么时候出。

VSCode 这个辣鸡。。。现在单开个 md 都要吃掉接近 600M 内存

"为什么不做一个 Electron Runtime，所有程序共享" 你是说浏览器？ chrome os ？
毕竟分赃不均啊

这是历史的轮回。

为了减小程序体积，所以发明了动态链接库，在系统中预装。

结果随着软件系统的复杂，为了解决不同软件之间的依赖关系，引出了各种包管理器。

然而随着系统越来越复杂，动态库和软件包之间的版本冲突开始出现。于是人们干脆把库一起和程序打包，变成了一个整体分发，这样就能避免冲突。

然后大家开始抱怨软件包太大。。。

@Torpedo #4 Flash 有 ActiveX，有 NPAPI，其他程序都可以用； C++ Runtime 也是一次安装，各种程序共享；更不用说各种 Linux 发行版里的包管理器，多数依赖都是系统内共享的，那么为什么不搞一个 libelectron，装上这个依赖后，多数使用 Electron 开发的应用就不必再内置一份 300M 的 Electron Framework 了

好吧具体一点，你怎么保证一年前的程序能够用一年后的 runtime 正常启动？还不是要装一堆不同版本的 runtime 。这样管理 runtime 的版本实在是太麻烦了。像 mac 和 windows 又没有统一的依赖包管理，你这是想让软件开发者死啊。

所以打包在一起，分发起来最方便了。

因为现在的 移动端 APP 动不动就 200m 起步了。

带宽越来越高，存储越来越便宜，安装包越来越大，虽然令人不爽，但也不是不能接受。

别说桌面端的应用了，就算移动端的 app 吧，复杂点的混合式应用，还得打包个 webkit 进去，平白无故 apk 体积要大个好几十兆。。

@ipwx #7 Electron 的 Runtime 这么屑的么？不能保证一年后能够正常启动

@ipwx #7 那这 breaking changes 也太多了

glibc 也没见每个程序自带一个啊 (

@ipwx #7 Electron 的核心功能都是 Node.js 和 CEF 提供的，它自己并没有这么多 bug，绝大多数都是上游导致的

每个都有自己的需求，加不同的功能，然后魔改之后就不兼容了。

https://github.com/revery-ui/revery 有前途吗

electron 是 github 的
github 是 微软的
是不是以后做到系统里也是可能的

因为电脑的内核版本不同。大家都想用最新的或者自己在用的内核版本，因为这样可以保证不同电脑上都能保证效果一致性，就导致每个软件都要加载自己下发的内核，就这样了撒。

放心,即便是系统提供了 webview,还是有 app 会自己包一个的. 造轮子也是人类的本质.

英雄联盟客户端不是 Adobe Air 的吗

Electron: 我寻思妹人在乎软件体积呢

Linux 不就是这样的吗? 共享一个 electron 包.

@undef404 这个包，和题主关注的换一个 webview 内核不是一回事。这里的情况是很多个版本的内核在电脑里面，而没有统一的公用动态库去减少包体积。

@cxh116 接上 https://www.archlinux.org/packages/community/x86_64/code/
https://www.archlinux.org/packages/community/x86_64/electron/

假设 vscode 某处引起“electron runtime”崩个 JB 了，搞得连 steam 都打不开了咋搞

@cxh116 但是没人用 OMG

@xiaomimei #15 看起来不错，但是我觉得它这个开发语言是个大问题
electron 能火起来也肯定是有 Javascript 的因素在里面，要是当初选了 Ruby 、Python，可能就凉了

等微软的 edge 走上正轨，给你内置一个 cef 到 windows SDK 里

@nyanyh #20 感觉 Adobe Air 都要比 Electron 要好点

@anguiao 使用 Electron 很大一部分原因是跨平台，Webview 2 还不太行。

CEF 是什么？

现在网络带宽和磁盘空间都不在稀缺的年代，这点消耗已经不算事了。showdoc 的 win 客户端也是 Electron 的
www.showdoc.cc/clients，并不见得太大啊。其他客户端大可能是因为各种 UI 资源（如图片）

接上

好像就是可以共享 nodejs 和 webview 的，

electron 最大的问题不是体积，而是内存占用，一个很小的功能都要占用很大的内存，相同容量，内存比硬盘贵的多

@ipwx
包的大小现在真无所谓,即使 1G 也没影响.
关键是太卡了.

我记得.net Framework 要装好几个版本

这些软件，我一个没有。

上面是开源软件 wubiLex 软件体积只有 820KB，不需要任何 DLL 或运行时。
像这种，在 aardio 里拖一拖就写好了，浏览器毕竟是为网页而生的，并不是所有软件都适合用网页来搞，

微软在写 react windows 了

我来秒杀一下这个问题

装 Windows 的电脑里面应该都有很多"Microsoft Visual C++ Redistributable"卸载项吧？而且可能有 2010，2013，2015 等多个版本，还有 x86 和 x64 两个版本。这还算好的了，如果 Electron 也那么搞你能想象是什么样吗？除非 Electron 能做到完全的向后兼容（据我了解并不是），否则将会有"Electron 8.0 Runtime", "Electron 8.1 Runtime”, "Electron 7.0 Runtime"等一堆东西出现。多个卸载项不是什么问题，主要是在安装上又多一步。这样一来兼容性还是个大问题，不然干脆全放安装包里了，自带依赖。反正这年头有大硬盘和高带宽，安装包大一些也无所谓

现在程序内存有个特点：内存便宜了，单个程序都可劲儿用内存，或者上层应用开发者自己无法控制用多少内存。

以前写程序，都尽量少用内存。当年网上不少这种讨论的事情，写个东东、或者一段代码、或者一道代码题目，一起讨论怎么能少几次操作，少用点内存。

Postman 的启动真的是龟速,然而各种 Electron 应用依旧层出不穷

大小无所谓，只是想快一点，而不是卡卡的感觉

大小不是问题，但是很多 app 都跟做网页一样性能捉急，体验极差

@g00001 看了一下这个玩意，官网没 HTTPS，全中文没国际化，不开源，山寨风格浓烈。不过我倒是赞同拖控件+DSL 才是编写 GUI 的正路。

@Jirajine 你的喷点很奇特，下次像你这种全帖没营养，没有有意义的观点，没有技术上务实的分析，单纯为了黑而黑的请不要 @我，知道个 HTTPS 也能让你看什么都带优越感？！ 一个免费软件有什么值得你喷的？！谁告诉你写一个软件一定要开源？！不开源就叫山寨？！ 你山寨一个给我看看？！你开源了什么呢？！谁又告诉你写点东西一定要准备一份英文的？！你发帖子都来中英双语的？！ V2EX 好歹是个技术站，真是莫名其妙

aardio 里还有一个非常有意思的 chrome.app 扩展库。
可以调用系统自带的 chrome 浏览器做软件界面，兼容 chrome 内核的浏览器也能支持，也支持微软 edge 内核，生成的软件非常小。

例如开源软件 HOSTS 切换助手 只有 700KB
https://github.com/aardio/hostsSwitchHelper

aardio 还可以嵌入 electron 内核，可以与 electron 互调函数，而且所有用 electron 写的软件可以共享一个相同的运行时，所以用 aardio + electron 生成的软件也非常小。

aardio 本身也非常小，开发环境加全部的文档、范例、标准库只有 6.5MB

@LostPrayers #28 这样就和以前内置 IE 核心一样了，也不错

天下苦套壳久矣

@g00001 #47 他想说的是你这官网和 UI 太丑了，然后一个不开源不跨平台的开发环境在现在真的没啥竞争力了，毕竟 .NET 都开源跨平台了

@ipwx 但现在空间变得廉价很多，所以其实也没啥毛病（绝大多数情况）

确实应该有个这样的东西，这样开发 windows 软件才会简单快捷。windows 小程序平台。。。

@LokiSharp 首先这不是我做的，
其次我对你所说的开发环境之争并没有兴趣，我提都没提这个话题。

另外我发个帖子就喷没开源 - 我很是莫名其妙。
我发的是一个完全开源的软件 https://github.com/aardio/wubi-lex
另外我也非常诡异，一个中文输入法的开源软件 - 为什么会喷没有英文版 ？！

我对你 “不开源不跨平台的开发环境在现在真的没啥竞争力” 的高论 - 不想发表意见，
我都不是做开发环境的人，我也没这个水平我不想去对别人的开发环境指手划脚。

如果你以后写的软件都能做到开源和跨平台。
也希望你真心的做到 “不开源不跨平台的东西都没用“ - 这当然也包括 Windows 。

至于你说太丑，这就很有意思了，
820KB 的 wubiLex 界面能做到这样，我在群里看到很多人说界面做的不错，
当然我觉得这是因为你的眼光比较高，请发个你做的界面来看看，我最喜欢向高手学习了。

@g00001 我就问你这个语言或者环境跨平台吗？不跨平台 Windows 下面为啥不用 C# + .NET ，至于这 UI 是近 20 年前的 WinForm 风格了。

Electron 的内存占用真是。。。code 虽好，内存不够用

因为现在大家觉得 bundle 所有依赖已经是成本最低的方案了，那点存储空间不值钱，DLL hell 损失更大
微软老早就建议使用 VC++的程序使用 Redist 安装程序而不是直接在程序里带上所有 DLL，然而一众厂商还觉得安装程序太大？（迷惑行为）不同版本怕兼容问题（哪怕是 patch 更新）
VC++已经是 ABI 很稳定的库了，chromium,electron 这种一年一个样的库还想着共享？我觉得是没戏

@g00001
上来就一通诉诸人身偷换概念逻辑滑坡扣帽子，这几点哪个不是事实，不会就事论事好好说话么。

@g00001 aardio 跨平台吗？

Electron 类软件 主要是卡 其次体积大 ~~ 哎！

Adobe Air : 谁叫我

@LokiSharp 我对这种争论不太想参与，也不关心这些。
不过你的话自相矛盾倒是有趣，不开源不跨平台就不用，那你为啥用 Windows ？！
不用 Windows 那你为啥会用 C#，另外微软的 VC#开发环境并不开源，不开源就不用，那你为啥会用 C#?!
不过话说回来，aardio 里有很多用户 C#都是用的很好的，如果你对这个话题感兴趣，可以去问问他们，我回答不出来呢。

我比较在乎体积的问题，
你用 820KB 能写出 wubiLex 吗？！
你发布的软件能不带.net framework 吗？！
C#写的软件，可以用 ILSpy 这些工具，可以一键还原出源代码，工程都能给你导出来，这都是因为 C#开源带来的问题，你都不介意是吧？！哦我忘了，你们写的软件都是开源的。可以发一下 github 地址吗？！

20 年前的 winform 能做到 aardio 这么好看啊，那我非常非常的佩服。


对你的无限景仰，可以发一下你现代化、跨平台、开源、比 aardio 牛逼万倍的 github 地址学习一下吗？！

对于 PC 来说体积大还好，毕竟存储相对较便宜，但是 RAM 占用大就很蛋疼了。。。
对于移动端来说，即使不用 electron 也存储照样好几百 M （参考支付宝之类，随便 700MB ）

苦于现在没有更好的跨平台 GUI 库了，QT 的 C++门槛太高，.net core 成熟还需时日，所以也只能是 electron 一家独大了。

@g00001 #35 这个挺有意思的，最近正好在学五笔，有些字死活不会拆，这个能帮上大忙。

@cmdOptionKana aardio 不跨平台，如果有跨平台的项目就不合适了，不过桌面操作系统是 Windows 一家独大，记得去年我用 electron 做的一个软件被用户骂惨了，他说你连 XP 都不支持，你支持那百分之零点几市场的操作系统有毛用，呵呵所以我后来被逼的用 aardio 重写了那个软件 - 好处是发行体积小了十倍。aardio 写的软件可以支持所有 Win 平台，没 electron 要求那么高。

@g00001 时代变了，自己看 MSDocs 去吧

让我想到了.net framework，版本多没问题啊，只要向下兼容就好了

主要矛盾是太卡

@g00001 #62 aardio 会被 360 杀啊， 自己用用还行

为什么 Linux 打包软件时不将依赖一起打包进去？
t/651613

主要是非常卡

吐个槽，今天刚整了一下服务器上的 c++ redist，10 12 13 15-19，每个版本的 x86 和 x64 都装了一遍，也不知道是哪个软件依赖的，反正全装一遍就是了。这些依赖也就 1~7M，打包到一起也没啥问题。

web 在浏览器端的实现也没完全对齐，虽然 edge 现在也用了 chromium，但苹果家的还没支持上吧。如果当时移动互联网没有兴起，所有人都老老实实用电脑软件，说不定真的能演化出一个桌面开发技术的标准，各家系统原生支持，用户只需要按照 web 的方式开发，打包到各个平台都能运行，岂不美哉。

@rockcat Qt 不需要 C++，Python 也能写

@g00001 我没记错的话 aardio 是用 Lua 的源码修改的，然后再加了点对 Windows 系统函数的封装作为他所谓的标准库。

@secondwtq QT 有挺多包装的，除了 Python 还有 Java，但总感觉还是原生的好，只是苦于不会 C++。

VS code 确实是垃圾，内存占用比 IDE 还要多

@LokiSharp 你是个有趣的人 - 我很喜欢，
想不到对 aardio 这么不爽，却又这么细心的去研究 aardio，我想你一定是生活的很成功和滋润，才会这么闲吧？！

当然，你还可以说安卓不过是改了改 linux 加了点封装。
不过你即然这么推崇开源，却又对别人正常的使用开源代码不爽，这种心态倒是奇怪的很矛盾。

其实 aardio 是一个开发环境，并不只是一个语言，所以 lua 源码是改不出 aardio 的，不信你可以去试试。

另外看来你是个软件开发新手，说了一些外行的话，WIN 平台上所有的开发语言，都会调用 Windows 系统函数, 所以这不是一个好的喷点，你要换一换。

aardio 可不仅仅只是个封装，例如他的界面库，没有像其他编程语言一样用到第三方的界面库，而是用纯 aardio 源码实现的，不像 Python 这些要用到 C++，所以你的理解有很大的误差。

我就不多说了，本来我压根就没想在这个帖子里讨论 aardio，毕竟国产语言你懂的 - 说多了会被骂是广，但是你一直纠结这个话题，我们还是打住吧。

迅雷都不用自己的 bolt 了，改用 electron 了。
我觉得用 electron 倒没问题，问题是 electron 需要精简一些和 GUI 无关的东西。

@TangMonk
aardio 是 360 平台收录的编程软件，不会被封杀的。

你说的是用 aardio 编写的软件吧，360 或者现在很多安全杀毒软件都是白名单机制，改一个字节都要去过白，有条件就买证书做签名，用各种编程语言结果都是一样的，aardio 并没有额外的不同，我之前用 C++写的软件被封的更快，老老实实去买证书，提交过白这些。

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

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

@reself #81 这就是个围城

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

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

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

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

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

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

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

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

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

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

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

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

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 感觉反而才是最轻松方便的，反正硬盘不值钱。

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

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

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

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

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

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

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

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

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