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