 |
1
HuHui Mar 26, 2020
天下苦 XX 久矣
|
 |
2
anguiao Mar 26, 2020 via Android
微软有个 WebView 2，基于 Chromium 内核的 Edge，不知道什么时候出。
|
 |
3
LokiSharp Mar 26, 2020
VSCode 这个辣鸡。。。现在单开个 md 都要吃掉接近 600M 内存
|
 |
4
Torpedo Mar 26, 2020
"为什么不做一个 Electron Runtime，所有程序共享" 你是说浏览器？ chrome os ？
毕竟分赃不均啊 |
 |
5
ipwx Mar 26, 2020  49
这是历史的轮回。
为了减小程序体积，所以发明了动态链接库，在系统中预装。 结果随着软件系统的复杂，为了解决不同软件之间的依赖关系，引出了各种包管理器。 然而随着系统越来越复杂，动态库和软件包之间的版本冲突开始出现。于是人们干脆把库一起和程序打包，变成了一个整体分发，这样就能避免冲突。 然后大家开始抱怨软件包太大。。。 |
 |
6
nyanyh OP @Torpedo #4 Flash 有 ActiveX，有 NPAPI，其他程序都可以用； C++ Runtime 也是一次安装，各种程序共享；更不用说各种 Linux 发行版里的包管理器，多数依赖都是系统内共享的，那么为什么不搞一个 libelectron，装上这个依赖后，多数使用 Electron 开发的应用就不必再内置一份 300M 的 Electron Framework 了
|
|
7
ipwx Mar 26, 2020 1
好吧具体一点，你怎么保证一年前的程序能够用一年后的 runtime 正常启动？还不是要装一堆不同版本的 runtime 。这样管理 runtime 的版本实在是太麻烦了。像 mac 和 windows 又没有统一的依赖包管理，你这是想让软件开发者死啊。
所以打包在一起，分发起来最方便了。 |
 |
8
icanfork Mar 26, 2020 1
因为现在的 移动端 APP 动不动就 200m 起步了。
|
 |
9
imdong Mar 26, 2020
带宽越来越高，存储越来越便宜，安装包越来越大，虽然令人不爽，但也不是不能接受。
|
 |
10
heyjei Mar 26, 2020
别说桌面端的应用了，就算移动端的 app 吧，复杂点的混合式应用，还得打包个 webkit 进去，平白无故 apk 体积要大个好几十兆。。
|
 |
14
si Mar 26, 2020
每个都有自己的需求，加不同的功能，然后魔改之后就不兼容了。
|
 |
15
xiaomimei Mar 26, 2020
|
 |
16
sunzongzheng Mar 26, 2020
electron 是 github 的
github 是 微软的 是不是以后做到系统里也是可能的  |
 |
17
xylxsss Mar 26, 2020
因为电脑的内核版本不同。大家都想用最新的或者自己在用的内核版本，因为这样可以保证不同电脑上都能保证效果一致性，就导致每个软件都要加载自己下发的内核，就这样了撒。
|
 |
18
undef404 Mar 26, 2020 1
放心,即便是系统提供了 webview,还是有 app 会自己包一个的. 造轮子也是人类的本质.
|
 |
19
TangMonk Mar 26, 2020
英雄联盟客户端不是 Adobe Air 的吗
|
|
20
nyanyh OP 1
@TangMonk #19 以前是 Air，后来 S5 还是什么时候大改版，现在已经是 Electron 那一套了
任务管理器里可以看到一大堆 renderer 进程 |
 |
21
paoqi2048 Mar 26, 2020
Electron: 我寻思妹人在乎软件体积呢
|
 |
22
cxh116 Mar 26, 2020
Linux 不就是这样的吗? 共享一个 electron 包.
|
|
23
xylxsss Mar 26, 2020
@undef404 这个包，和题主关注的换一个 webview 内核不是一回事。这里的情况是很多个版本的内核在电脑里面，而没有统一的公用动态库去减少包体积。
|
|
24
cxh116 Mar 26, 2020
|
 |
25
guolaopi Mar 26, 2020
假设 vscode 某处引起“electron runtime”崩个 JB 了，搞得连 steam 都打不开了咋搞
|
|
27
nyanyh OP @xiaomimei #15 看起来不错，但是我觉得它这个开发语言是个大问题
electron 能火起来也肯定是有 Javascript 的因素在里面，要是当初选了 Ruby 、Python，可能就凉了 |
 |
28
LostPrayers Mar 26, 2020
等微软的 edge 走上正轨，给你内置一个 cef 到 windows SDK 里
|
 |
31
darkcode Mar 26, 2020
CEF 是什么？
|
 |
32
star7th Mar 26, 2020
现在网络带宽和磁盘空间都不在稀缺的年代，这点消耗已经不算事了。showdoc 的 win 客户端也是 Electron 的
www.showdoc.cc/clients，并不见得太大啊。其他客户端大可能是因为各种 UI 资源（如图片） |
 |
33
fengbjhqs Mar 26, 2020
|
|
34
fengbjhqs Mar 26, 2020
接上
好像就是可以共享 nodejs 和 webview 的， electron 最大的问题不是体积，而是内存占用，一个很小的功能都要占用很大的内存，相同容量，内存比硬盘贵的多 |
 |
37
wangkun025 Mar 26, 2020
这些软件，我一个没有。
|
 |
38
g00001 Mar 26, 2020 1
   上面是开源软件 wubiLex 软件体积只有 820KB，不需要任何 DLL 或运行时。 像这种，在 aardio 里拖一拖就写好了，浏览器毕竟是为网页而生的，并不是所有软件都适合用网页来搞， |
 |
39
agdhole Mar 26, 2020 via iPhone
微软在写 react windows 了
|
 |
40
rwalle Mar 26, 2020 via Android
我来秒杀一下这个问题
装 Windows 的电脑里面应该都有很多"Microsoft Visual C++ Redistributable"卸载项吧？而且可能有 2010，2013，2015 等多个版本，还有 x86 和 x64 两个版本。这还算好的了，如果 Electron 也那么搞你能想象是什么样吗？除非 Electron 能做到完全的向后兼容（据我了解并不是），否则将会有"Electron 8.0 Runtime", "Electron 8.1 Runtime”, "Electron 7.0 Runtime"等一堆东西出现。多个卸载项不是什么问题，主要是在安装上又多一步。这样一来兼容性还是个大问题，不然干脆全放安装包里了，自带依赖。反正这年头有大硬盘和高带宽，安装包大一些也无所谓 |
 |
41
secondwtq Mar 26, 2020
我记得小时候还没 Electron 的时候，Windows 底下分发软件把 MFC 之类的带上不是啥新鲜事
现在带个 Qt，Swift 运行时甚至 Python Runtime 也没啥 另外居然有人知道 revery 这东西 ... |
 |
42
hoyixi Mar 26, 2020
现在程序内存有个特点：内存便宜了，单个程序都可劲儿用内存，或者上层应用开发者自己无法控制用多少内存。
以前写程序，都尽量少用内存。当年网上不少这种讨论的事情，写个东东、或者一段代码、或者一道代码题目，一起讨论怎么能少几次操作，少用点内存。 |
 |
43
KeyboardManAnAn Mar 26, 2020
Postman 的启动真的是龟速,然而各种 Electron 应用依旧层出不穷
|
 |
44
pC0oc4EbCSsJUy4W Mar 26, 2020
大小无所谓，只是想快一点，而不是卡卡的感觉
|
 |
45
Resource Mar 26, 2020
大小不是问题，但是很多 app 都跟做网页一样性能捉急，体验极差
|
 |
46
Jirajine Mar 26, 2020 via Android
@g00001 看了一下这个玩意，官网没 HTTPS，全中文没国际化，不开源，山寨风格浓烈。不过我倒是赞同拖控件+DSL 才是编写 GUI 的正路。
|
|
47
g00001 Mar 26, 2020 1
@Jirajine 你的喷点很奇特，下次像你这种全帖没营养，没有有意义的观点，没有技术上务实的分析，单纯为了黑而黑的请不要 @我，知道个 HTTPS 也能让你看什么都带优越感？！ 一个免费软件有什么值得你喷的？！谁告诉你写一个软件一定要开源？！不开源就叫山寨？！ 你山寨一个给我看看？！你开源了什么呢？！谁又告诉你写点东西一定要准备一份英文的？！你发帖子都来中英双语的？！ V2EX 好歹是个技术站，真是莫名其妙
|
|
48
g00001 Mar 26, 2020 2
aardio 里还有一个非常有意思的 chrome.app 扩展库。
可以调用系统自带的 chrome 浏览器做软件界面，兼容 chrome 内核的浏览器也能支持，也支持微软 edge 内核，生成的软件非常小。 例如开源软件 HOSTS 切换助手 只有 700KB https://github.com/aardio/hostsSwitchHelper aardio 还可以嵌入 electron 内核，可以与 electron 互调函数，而且所有用 electron 写的软件可以共享一个相同的运行时，所以用 aardio + electron 生成的软件也非常小。 aardio 本身也非常小，开发环境加全部的文档、范例、标准库只有 6.5MB |
|
49
nyanyh OP @LostPrayers #28 这样就和以前内置 IE 核心一样了，也不错
|
 |
50
janxin Mar 26, 2020
天下苦套壳久矣
|
|
51
LokiSharp Mar 26, 2020 1
@g00001 #47 他想说的是你这官网和 UI 太丑了，然后一个不开源不跨平台的开发环境在现在真的没啥竞争力了，毕竟 .NET 都开源跨平台了
|
 |
53
ddeef Mar 26, 2020
确实应该有个这样的东西，这样开发 windows 软件才会简单快捷。windows 小程序平台。。。
|
|
54
g00001 Mar 26, 2020 1
@LokiSharp 首先这不是我做的，
其次我对你所说的开发环境之争并没有兴趣，我提都没提这个话题。 另外我发个帖子就喷没开源 - 我很是莫名其妙。 我发的是一个完全开源的软件 https://github.com/aardio/wubi-lex 另外我也非常诡异，一个中文输入法的开源软件 - 为什么会喷没有英文版 ？！ 我对你 “不开源不跨平台的开发环境在现在真的没啥竞争力” 的高论 - 不想发表意见， 我都不是做开发环境的人，我也没这个水平我不想去对别人的开发环境指手划脚。 如果你以后写的软件都能做到开源和跨平台。 也希望你真心的做到 “不开源不跨平台的东西都没用“ - 这当然也包括 Windows 。 至于你说太丑，这就很有意思了， 820KB 的 wubiLex 界面能做到这样，我在群里看到很多人说界面做的不错， 当然我觉得这是因为你的眼光比较高，请发个你做的界面来看看，我最喜欢向高手学习了。 |
|
55
LokiSharp Mar 26, 2020 via iPhone
@g00001 我就问你这个语言或者环境跨平台吗？不跨平台 Windows 下面为啥不用 C# + .NET ，至于这 UI 是近 20 年前的 WinForm 风格了。
|
 |
56
freefcw Mar 26, 2020
Electron 的内存占用真是。。。code 虽好，内存不够用
|
 |
57
jim9606 Mar 26, 2020
因为现在大家觉得 bundle 所有依赖已经是成本最低的方案了，那点存储空间不值钱，DLL hell 损失更大
微软老早就建议使用 VC++的程序使用 Redist 安装程序而不是直接在程序里带上所有 DLL，然而一众厂商还觉得安装程序太大？（迷惑行为）不同版本怕兼容问题（哪怕是 patch 更新） VC++已经是 ABI 很稳定的库了，chromium,electron 这种一年一个样的库还想着共享？我觉得是没戏 |
 |
59
QingXuJiaZhi Mar 26, 2020
@g00001 aardio 跨平台吗？
|
 |
60
justin2018 Mar 26, 2020
Electron 类软件 主要是卡 其次体积大 ~~ 哎！
|
 |
61
charlie21 Mar 26, 2020
Adobe Air : 谁叫我
|
|
62
g00001 Mar 26, 2020
@LokiSharp 我对这种争论不太想参与，也不关心这些。
不过你的话自相矛盾倒是有趣，不开源不跨平台就不用，那你为啥用 Windows ？！ 不用 Windows 那你为啥会用 C#，另外微软的 VC#开发环境并不开源，不开源就不用，那你为啥会用 C#?! 不过话说回来，aardio 里有很多用户 C#都是用的很好的，如果你对这个话题感兴趣，可以去问问他们，我回答不出来呢。 我比较在乎体积的问题， 你用 820KB 能写出 wubiLex 吗？！ 你发布的软件能不带.net framework 吗？！ C#写的软件，可以用 ILSpy 这些工具，可以一键还原出源代码，工程都能给你导出来，这都是因为 C#开源带来的问题，你都不介意是吧？！哦我忘了，你们写的软件都是开源的。可以发一下 github 地址吗？！ 20 年前的 winform 能做到 aardio 这么好看啊，那我非常非常的佩服。  对你的无限景仰，可以发一下你现代化、跨平台、开源、比 aardio 牛逼万倍的 github 地址学习一下吗？！ |
 |
63
daozhihun Mar 26, 2020
对于 PC 来说体积大还好，毕竟存储相对较便宜，但是 RAM 占用大就很蛋疼了。。。
对于移动端来说，即使不用 electron 也存储照样好几百 M （参考支付宝之类，随便 700MB ） |
 |
64
rockcat Mar 26, 2020
苦于现在没有更好的跨平台 GUI 库了，QT 的 C++门槛太高，.net core 成熟还需时日，所以也只能是 electron 一家独大了。
|
 |
65
superrichman Mar 26, 2020
@g00001 #35 这个挺有意思的，最近正好在学五笔，有些字死活不会拆，这个能帮上大忙。
|
|
66
g00001 Mar 26, 2020
@cmdOptionKana aardio 不跨平台，如果有跨平台的项目就不合适了，不过桌面操作系统是 Windows 一家独大，记得去年我用 electron 做的一个软件被用户骂惨了，他说你连 XP 都不支持，你支持那百分之零点几市场的操作系统有毛用，呵呵所以我后来被逼的用 aardio 重写了那个软件 - 好处是发行体积小了十倍。aardio 写的软件可以支持所有 Win 平台，没 electron 要求那么高。
|
 |
69
leafleave Mar 26, 2020
主要矛盾是太卡
|
 |
71
runze Mar 26, 2020
为什么 Linux 打包软件时不将依赖一起打包进去？
https://www.v2ex.com/t/651613 |
 |
72
StephenHe Mar 26, 2020
主要是非常卡
|
 |
73
imycc Mar 26, 2020
吐个槽，今天刚整了一下服务器上的 c++ redist，10 12 13 15-19，每个版本的 x86 和 x64 都装了一遍，也不知道是哪个软件依赖的，反正全装一遍就是了。这些依赖也就 1~7M，打包到一起也没啥问题。
web 在浏览器端的实现也没完全对齐，虽然 edge 现在也用了 chromium，但苹果家的还没支持上吧。如果当时移动互联网没有兴起，所有人都老老实实用电脑软件，说不定真的能演化出一个桌面开发技术的标准，各家系统原生支持，用户只需要按照 web 的方式开发，打包到各个平台都能运行，岂不美哉。 |
|
75
LokiSharp Mar 26, 2020 via iPhone
@g00001 我没记错的话 aardio 是用 Lua 的源码修改的，然后再加了点对 Windows 系统函数的封装作为他所谓的标准库。
|
 |
77
CuVee Mar 26, 2020
VS code 确实是垃圾，内存占用比 IDE 还要多
|
|
78
g00001 Mar 26, 2020
@LokiSharp 你是个有趣的人 - 我很喜欢，
想不到对 aardio 这么不爽，却又这么细心的去研究 aardio，我想你一定是生活的很成功和滋润，才会这么闲吧？！ 当然，你还可以说安卓不过是改了改 linux 加了点封装。 不过你即然这么推崇开源，却又对别人正常的使用开源代码不爽，这种心态倒是奇怪的很矛盾。 其实 aardio 是一个开发环境，并不只是一个语言，所以 lua 源码是改不出 aardio 的，不信你可以去试试。 另外看来你是个软件开发新手，说了一些外行的话，WIN 平台上所有的开发语言，都会调用 Windows 系统函数, 所以这不是一个好的喷点，你要换一换。 aardio 可不仅仅只是个封装，例如他的界面库，没有像其他编程语言一样用到第三方的界面库，而是用纯 aardio 源码实现的，不像 Python 这些要用到 C++，所以你的理解有很大的误差。 我就不多说了，本来我压根就没想在这个帖子里讨论 aardio，毕竟国产语言你懂的 - 说多了会被骂是广吿，但是你一直纠结这个话题，我们还是打住吧。 |
 |
79
ivechan Mar 26, 2020
迅雷都不用自己的 bolt 了，改用 electron 了。
我觉得用 electron 倒没问题，问题是 electron 需要精简一些和 GUI 无关的东西。 |
|
80
g00001 Mar 26, 2020
@TangMonk
aardio 是 360 平台收录的编程软件，不会被封杀的。 你说的是用 aardio 编写的软件吧，360 或者现在很多安全杀毒软件都是白名单机制，改一个字节都要去过白，有条件就买证书做签名，用各种编程语言结果都是一样的，aardio 并没有额外的不同，我之前用 C++写的软件被封的更快，老老实实去买证书，提交过白这些。 |
 |
84
crella Mar 26, 2020 via Android
其实感觉 gtk 挺好的，用过 geany，scite 在 linux 上也是 gtk 画界面。
geany 对标 kate，kate on windows 不是一般地卡…… |
|
85
nyanyh OP @reself #81 我也发现了那个贴子
要是几个几 M 大小的就算了，很多个 app 都带几百 M 的 runtime，这几个 runtime 之间也许没有很大区别，却占用大量空间，这是一种很差的设计 |
 |
87
mgrddsj Mar 26, 2020
@rwalle #40 看到这帖马上就想到那一堆 Microsoft Visual C++ 20xx Redistributable - x86/x64, 作为用户是真的头大。每个软件都用不同版本的 Redist, 那就跟软件自己带一个运行库没有区别了。卸载软件时，Redist 还不会自动卸载，而且 Windows 还没有原生的包管理器，用户也不知道哪个软件依赖哪个版本的 redist, 导致又不敢乱卸载，反而还更占空间。
|
|
88
LokiSharp Mar 26, 2020
@g00001 #78 ”aardio 可不仅仅只是个封装，例如他的界面库，没有像其他编程语言一样用到第三方的界面库，而是用纯 aardio 源码实现的，不像 Python 这些要用到 C++，所以你的理解有很大的误差。
“？？？你确定？你的意思是他的界面库不用调用 Windows 的 C++ API，还是说用 Python 标准库 tkinter 需要写 C++ 代码？ 请你解释一下他加载的这么多 dll 是什么？？？或者是你想说调用系统的 API 不是用第三方软件库而是第一方软件库是吧？（滑稽  |
 |
90
augustheart Mar 26, 2020
看你们争论这么热烈，我突然想义务推广 miniblink 了。
顺便：这个不是我写的，作者我也不熟，就是碰巧在一个群里，而且在群里也几乎没直接交流过…… electron 这套东西的形式就是有问题，没得辩，只是大家都太懒，抱着一大坨够凑合就行。 |
|
91
augustheart Mar 26, 2020
@LokiSharp 虽然 aardio 我也没接触过（听说过，但是没放心上，也没兴趣了解），但我不得不说，你对编程一无所知……
|
|
92
LokiSharp Mar 26, 2020
|
 |
93
AV1 Mar 26, 2020
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 感觉反而才是最轻松方便的，反正硬盘不值钱。 |
 |
94
sc3263 Mar 26, 2020
@nyanyh 虽然说都是基于 Chromium 内核，但 CEF 和 Electron 的上层封装完全不一样，无法复用。
即使使用同样的库，为了实现特殊需求，各家公司也会基于官方版本做一些小改动。比如说 Steam 用的 CEF，其实是自己定制的版本。不同的定制化版本之间也无法复用。 就算大家用的都是官方版本，但各家使用的 runtime 版本也不会一致。对于这种每一两周就会出更新一个稳定版的框架，要求开发商去适配自家的软件在各个版本的 runtime 下都能稳定运行是不现实的。甚至保证能在 runtime 最新版本下稳定运行这件事，都是很奢侈的。 最有可能实现的复用方案，就是楼上提到的 Microsoft Visual C++ Redistributable 那种，各个版本的 runtime 都来一份。然后期待某两个开发商的软件，用的 runtime 是同一个版本，能省下小几百兆的硬盘空间。 |
|
96
augustheart Mar 26, 2020
@LokiSharp 在任何操作系统下面编写应用的，你找得出不使用系统接口的存在么？写个 bios 都还得调硬件接口……
他说话的意思还是很好懂的，基本上就是说我的界面是我自己拿自己的代码堆出来的，控件都是自己的语言画出来的，不像 python 下面界面编程用 tcl，qt 什么的。至于他指的东西是自绘还是直接 win 控件我也不知道，但是反正他自己凑出一套自己的界面库了。 不过你们两个一开始就不对付，然后…… |
 |
97
jiejiss Mar 26, 2020
Electron 官方曾经参与讨论过类似 Java Runtime 的解决方案，并选择不采纳该方案。
https://github.com/electron/electron/issues/2003#issuecomment-371774017 |
|
98
jiejiss Mar 26, 2020
|
|
99
augustheart Mar 26, 2020 1
@g00001 nullsoft 那套东西也超级小。没错，就是做安装包的那个 nsis
|
 |
100
hst001 Mar 26, 2020
听游戏界的大佬们说，九几年那会开发游戏，为了优化可谓绞尽脑汁，使上浑身解数，用尽各种奇淫巧计来优化 CPU/内存 /存储各个方面，因为硬件性能太太太太差了。转眼看看现在，很多电脑性能过剩，游戏开发也开始大胆起来了，除非真的影响到体验，一般优化也就那样了，看看动作上百 G 的文件，这里有多少其实是实际用不到的？不过我们其实也不必在乎，因为这某种程度降低了开发成本，使得我们可以构建更复杂的应用 /游戏来应对更复杂的需求和任务，这就是进步，所以不要在意这点资源的浪费！
|
Select Language