这是我给 Electron 开的减肥药，你觉得行么？

[gowl]

Electron App 的大小一般在 100MB+，压缩后一般在 50MB+。我们假设这个体积比较大，受不了；另外假设我们想用 HTML + CSS 的方式来构建跨平台 UI，而不是使用 Native 的解决方案，并且。那么为了给这种 App 瘦身，可不可以这么做：

一个 Apache 服务器差不多 2MB 左右。打包一个处理动态请求的服务模块假设十几 MB 大小。这样我们可以做一个可以分发到客户端的 web 服务。并且这个东西的大小在 20 MB 左右，这是可以接受的。然后用户通过 http://localhost:1234/app 这样的地址通过本地浏览器来访问。

这样做完其实就跟 Electron 没什么关系了，不过还是拿他来做比较。另外假设我们想要的是能用 HTML 做 UI，而不一定要用 JS 来完成整个 app。

我能想到的缺点是用户浏览器里的 localhost:mnxy 比较难看。大家有什么解决办法么？

[wireshark]

没看懂

[xiqingongzi]

可以，但是你避不开兼容性的问题。electron 之所以大是嵌入了 Chrome 的内核，来解决不同系统下的兼容问题。你如果使用系统自带浏览器的内核，是无法解决这个问题的。

[gowl]

@wireshark 想用 HTML 做 desktop app 的 GUI，但是不想用. Electron，因为它太大了。然后在探讨一种直接把 web 服务搬到客户电脑上的解决方案，然后客户通过本地已经安装的浏览器来访问这个 app。

[noe132]

electron 能用 nodeapi 读写文件，浏览器可以么？

[gowl]

@xiqingongzi 我觉得 Windows 10 和 Mac Safari 以及 Linux 上常预装的 Firefox 都是很现代的浏览器，兼容性工作就像正常开发一个网站一样，不会特别难的。我猜。

[gowl]

@noe132 可以用 native 语言写各种服务。因为已经在客户端相当于安装了一个 web 服务器了，在部署几个服务直接和文件系统对接并不难的。

[gowl]

@xiqingongzi 上一条没说清楚，我想说 Windows 10 自带的 Edge。

[doubleflower]

这特么哪和哪，你说的不就是传统的 bs 程序，之前大家都是这么干的啊，和 electron 有毛线关系

[xiqingongzi]

@gowl 如果你确定你的用户只使用最新版的操作系统，没有问题。此外，楼上说的文件读写也是个问题。

你说的模式我见过，以前有个郑州一个公司开发的会计考试系统就是用的你说的模式，体验一般。

[logOo]

现在的网速磁盘大小不是个大问题吧

[loading]

没有浏览器部分，你比大小？

[binux]

你根本不懂 electron 是干嘛的，解决了什么问题。

[zhujinliang]

做 chrome 的扩展不就行了，像 moonlight-chrome 那样

[murmur]

貌似 nw.js 小一点？

[knktc]

你要不看看 pgadmin4 的实现方法？似乎类似你说的这种方式～

[gowl]

@zhujinliang 是个方法，但是这样会绑在一个浏览器上～

[gowl]

@knktc 对的，就是这个思路：）

[SourceMan]

你不懂 electron 解决了什么问题
想要 size 小，直接调用系统的 webview，内核 0 大小，参照项目 macgap

[kfll]

cef 也够小

[hardman]

刚开源就开始搞了

[x86vk]

你这么搞 不如用 qt 加上 qwebkit 算了

[873681136]

electron 不只是浏览器

[x86vk]

@x86vk s/qwebkit/QWebEngine

[sagaxu]

我做过类似的，没用 apache，采用了 Go 自带的 http 服务，带业务逻辑，strip 之后大概 5MB 左右。Go 是可以帮用户打开浏览器的，不需要手动输入。如果用户能接受安装个 JRE，那就更方便了，用 JavaFX 内置的 webview。

[plqws]

楼主用过 Web 迅雷吗？

[huiyifyj]

但这样用起来还是不好，浏览器毕竟不能像 node 一样调研 js 更多的接口吧（文件读写之类的）。而且兼容性也是问题。还有就是窗口设置问题之类的啊。

[gowl]

@plqws 怎么了，亲？

[gowl]

@SourceMan
@binux 解决了什么问题啊？

[qdwang]

什么年代了 100mb 根本不大，就和以前 1m 差不多

[nicevar]

难看不是问题，是难用，反应总慢半拍，只要同类应用有原生的就不会考虑

[binux]

@gowl Build cross platform desktop apps with JavaScript, HTML, and CSS

[gowl]

@qdwang 虽然在家里下 100mb 大概需要一秒钟，但是体积总是越小越好，有时候，比如在火车上，网速就差多了。还有一个问题不是下载，而是电脑里同时运行几个 webkit 的程序，总觉得浪费资源和电

[gowl]

@nicevar 把网页做轻一点应该就会延时很小了，这个我再探索探索～

[chocotan]

我电脑里装的软件占用空间排名前几的有好几个都是 electron 做的......

[tabris17]

我想你对 electron 有什么误解

[my101du]

如果能有某种技术极大简化原生语言开发的过程和优化开发体验，并在界面库选择上能像前端一样百花齐放，让开发者高效率开发原生应用。大部分人压根不想使用 electron 做的软件，卡 慢 大。

我的疑问是，electron 开发的软件一运行就是 500 600m 内存，真的没有办法从底层优化？还是在开发效率方面没有对手，所以没有动力去优化运行效率。

[feather12315]

@my101du #36 还有很多内存泄漏

[bookit]

对于业界这些潮流、动向，只能默默抵制。

[sobigfish]

变 bs 架构 最大的问题就是你的服务器抗的住么
收不收费都会很难搞

[gowl]

@sobigfish 服务器软件是在用户的电脑上。整个 app 是不用联网的

[gowl]

@tabris17 有什么误解？

[dtysky]

electron 还解决了和一些浏览器做不到的系统调用问题。。。你真的有所误解

[omph]

至少解决了桌面集成问题。
不过安装多个 electron app 时，倒可以考虑共用一个 chrome 内核，这样安装空间可以少些。
至于运行占用，除非搞个精简版 chrome，不要的特性通通去掉，多进程架构也可以改。

[awing]

electron 的核心价值这就被你抹杀了。。。。

[murmur]

@plqws 迅雷不是用的 lua 做的界面么

[applehater]

UWP 支持用 HTML JavaScript 打包后也很小，因为系统统一提供了运行环境。

[fcten]

早就有软件这么做了，不提供 native ui，只有 web 管理界面。事实上内嵌一个 http 服务只需要几十 K 的库就够了。
electron 就是为了解决这种需求才出现的，它帮你解决了很多通用性的问题。
就好比人为了代步发明了汽车，你现在说汽车费油笨重不环保，我们还是骑自行车吧……

[lxml]

100MB 相比解决的问题，真的不算什么，就像静态编译和动态编译，在 2018 年我觉得无需争论

[plqws]

@murmur “ Web 迅雷”，迅雷的早期产品

[murmur]

@my101du 如果一个软件牛逼到一定程度或者垄断到一个程度 再垃圾也有人去用

优化是有的 QQ 当时就花了大力气内嵌了 chrome 你看别的 chrome 都是一个文件几十 m 的运行库 qq 音乐的 dll 都是几 mb 几 mb 一大堆

[murmur]

更正是一下 是网易云音乐
QQ 音乐现在好像内嵌了一个 QQ 浏览器

[ysc3839]

这么做主要是为了解决兼容性问题。
Windows 平台在 Win10 之前都只有 IE，而且 IE 已经不再更新。这样的话就不能使用新的 HTML 特性。Win10 有 Edge，但是调用起来还是有点小坑的。
Linux 平台系统没有提供 Web 内核，估计只有使用 CEF 这类嵌入式内核，不可避免要带上一整个内核。
macOS 可能是最简单的，系统自带了较新的内核。至于有没有什么坑我没用过就不知道了。

[g00001]

这些东西也还是要看软件开发者各自的需求，区分需求具体对待，有一些软件的确是不怕大，越大越好卖钱，但也不是说你写个软件觉得越大越好，所有人都一定也得是相同的想法，对于大多数共享软件，几 MB 还有很多人嫌大了，如果动不动就几百个 MB 起步，估计大多数共享软件下载站都得关门了。有很多用户一看你的软件上百 MB，扭头就走了，毕竟不是每个软件开发者都是腾迅、网易，要用户忍受你的体积，你先得有他那么大的底气呀。

而且软件的体积大，占用的资源一般也会大，例如 chrome，多开几个网页，8G,10G 的内存就没有了，一个网页就得启动一个 chrome 进程，不要以为开发者自己配的内存大，小白用户个个内存都很大。而且别人愿意 chrome 耗很大的内存，不见得对每个共享软件都有这种耐心，要是桌面上开几十个进程，个个都想占个 8G,10G 的耗光用户的内存，那就笑话了。

如果希望开发的桌面软件体积小一点的，可以试试 aardio，aardio 一个主要特色就是体积小，开发工具带全部标准库也就 5.6MB ，虽然体积小功能可并不少，接口丰富，而且还可以嵌入调用 Java,C#,Python...这一大堆的第三方语言，非常方便。

用 aardio 嵌入浏览器也很方便，可以嵌入一个很小的 HTTP 服务端，服务端支持类 PHP 的模板语法（关键还可以直接调用系统 API 这些），支持系统自带的浏览器控件，带精简版的 WebKit 控件 3MB，也支持 chrome 的精简版的 blink 控件，也可以用来嵌入 electron。

发一个 aardio 范例里的 asar （ electron 发布打包格式）文件管理器，类似这种软件用 aardio 要不了几句代码就能写出来。 像这种一些小的软件，几句代码可以搞定的事，几百 KB 可以搞定的事，非要上个几百 MB 的框架，没有必要吧。

开着豪车非要去骑自行车，这的确是不对。
但是要知道，满大街更多的是自行车，你溜个菜市场，还不愿意骑自行车，非要把房车挤到菜市场里去买菜，理由竟然是越大就一定越方便，越高级，这就不合理了。

[ysc3839]

@omph 共用的话问题就更复杂了，不同软件使用的版本不同怎么办？我想使用新版本的，而有的软件用旧版本的不升级。
还有安装卸载的问题，第一个软件装上了这个共用的内核，那卸载时删不删？删掉的话如果别的软件也依赖呢？不删的话不是浪费空间？

[Osk]

emm，以前买 Crucial SSD 的管理软件就是这样搞的，安装包很大(相对其它家)，调用浏览器访问 loclhost:???，体验相当糟糕，IE 有兼容性问题，Chrome 倒能用吧，如果不是性价比还行，就冲这软件就得给差评。似乎 server 端是 java 搞的，最后还告诉我没检测到 SSD。。。不知道现在改进没

[tsl0922]

这里有个现成的轮子： https://github.com/zserge/webview，劣势就是没法利用 nodejs 的各种库了，但是也可以 js 和 c/go 交互。

[omph]

@ysc3839
浏览器内核可以独立安装，如果 app 不兼容当前内核，可以装自己打包的，总之给用户选择权。
删不删属于软件依赖问题，由包管理系统解决。

[gowl]

@g00001 aardio 跨平台么？

[ysc3839]

@omph Windows 没有包管理。

[ysc3839]

@gowl 看了一下，似乎是 Windows only，不开源，感觉是个人维护的项目。我认为用在实际项目中不太现实，只适合个人使用。

[g00001]

你说的“只适合个人使用的编程语言” - 在这个世界上并不存在。这个推理本身就有点矛盾。简洁灵活并不是缺点，个人都用不好的编程语言 - 团队也不可能用好。
别看 aardio 只有 5.6MB 这么小的体积，功能并不简单，可以用来写企业 ERP,参考开源项目 https://github.com/carlaau/aardio-erp 可以用来做网站写个论坛都很轻松，例如 http://www.jianma123.com/

然后你所说的，打开随便看了一下，马上就总结出 aardio 不适合用于“实际项目” - 这个把个人开发的项目理解成了一定是不实际的项目，实际上很多优秀的桌面软件都是个人开发的。aardio 历经 14 年的开发，更新活跃，不可能是用来做不实际的项目，这样的话也不可能论坛有几万帖子，大量开源代码，第三方群都有一千多人。

aardio 也算不上是你所说的完全不开源、个人维护的项目。aardio 本身就是一个开放的框架，主要的特性和功能使用开源的标准库提供，要不了几句代码就可以扩展一个模块，类似在 aardio 中嵌入 Java,C#,Python.....这些编程语言，以及嵌入 Webkit,Electron.....这些浏览器控件，这些功能都是由标准库中无保留的开源模块提供的，对于桌面软件，核心开源的语言都容易被研究破解反编译出源代码的，而这对于多数桌面软件是致命的，aardio 出于保护用户软件的目的不开源核心运行时 - 没有什么问题，不开源的桌面开发工具实际上很多。

说到跨平台，对于桌面软件，除了 Windows 其他操作系统的市场占有率可以忽略（例如 electron 跨平台是有代价的 ），并不是所有桌面软件都有必须跨平台的需求。所谓跨平台，也并不一定就要是 100%的跨平台，并不是所有操作系统提供的接口、特性都是完全一样的，实际上单纯的用 electron，像调用 WINAPI 这些简单的事都做不到，aardio 不一样，虽然是嵌入浏览器壳子，在 javascript 里就可以直接调用 WINAPI，非常的方便。

适不合用于“实际项目”，关键看这个“实际项目”是干什么，aardio 的优势就是小，可以使用原来已经熟悉的语言和技术写桌面软件，相比 VC,VB 这种要投入多年时间去学习的开发工具要方便很多。

[yaolixing]

切可闹，推荐他山混合开发框架，内嵌 gecko v52,支持 xp+,linux,android