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