请问现在使用 electron 开发桌面应用怎么样呢，有什么明显的缺点吗

[baozijun]

谢谢

[loading]

包大
界面要做好，很繁琐
Xp 不支持

[giuem]

体积大

[nicevar]

优缺点参考 Atom 了，明显的缺点就是太吃 CPU 多消耗点地球能源，冬天使用能保暖，夏天热死狗

[oa414]

包大

有个脑洞：多个应用共用一个大版本的 release ，安装包检测系统有没有 libElectron 1.X ，如果有就复用，没有就下载。这样应用可以做到几百 K 。

感觉 Electron 更像一个解释运行的环境，没必要每个应用自己打包集成。

现在做 Electron 的开发，在网上学习一些代码，每个项目 npm install 以下，系统里面就有几十个 100M+ 的 Electron.app ....

[SourceMan]

体积大，就这一个缺点了

[loading]

建议先做 web app 然后再考虑打包

[dphdjy]

@oa414 好方法，不过基本不可能，因为 atom 的应用太少，主流的几个还有魔改的。

不过可以试试写个 atom 的应用打包工具，然后把下载放在这部分。

在顺手开个商店。。。

生态也有了。。。

然后发现商店只有屈指可数的几个应用。。。

[dibage]

@dphdjy 不是不可能，个人已经在半年之前已经实现（现在已经不怎么用 electron 了）
原理很简单，把你的 app 打包成 asar ，然后用 electron 的 api （或者自己封装）去加载即可。

这样可以扩展到其他方面，比如做个 electron 的 app 应用市场，提供一些基础的 nodejs 模块，这样的话自己写的应用，排除 node_modules 以及 electron 资源，打包后的大小就非常满意了。

（本来之前是有打算做这个市场的，但是精力不足，如果 v 友有兴趣的可以交流交流

[regent]

体积大，流畅度一般

[oa414]

@dibage 有过类似的想法，不过还没有动手...

我的想法是做一个原生的 GUI 启动器 /shell 脚本，检测 ~/.electron 有没有 Electron.app, 然后下载 asar 包和图标这些，然后通过链接文件生成应用的 XXX.app 。

关于公共模块，类似动态更新，加密源码这样子的，个人觉得还是适合做成开源的库，一方面打包也没多大，一方面 Electron 生态目前还算很小...

或许可以 brew 或者类似的工具集成以下，做成 brew electron install user/repo 这样子的 brew 的插件

另外，想为 Electron 加入更多原生的模块，发现想为 Electron 本身添加一个模块或者贡献代码的要求挺高的。 node 这一块内容不多，但是魔改的 libchromium 和相关的 cpp 库... 编译一下要从 s3 下载几个 G 的文件，还有各种依赖和环境要求，至今没有编译成功...

[hst001]

都什么年代了，体积大根本不是问题
真要说缺点，就是耗资源（其实这年代耗点内存可以忽略了），但还算比较流畅

[dibage]

@oa414 其实如果要求不是很大，技术以及成本不是那么到位的话，没必要去研究修改源码＋如何编译这类问题，因为我们关心的是 app 层。

参考 chrome 的 app （包括安装＋执行＋ api 等方面），其实如果弄的话优势还是挺好的。虽然传闻 chrome 已经抛弃 app 功能。

所以跟你的想法类似，做个 gui 启动器（ shell 脚本＋终端安装的方式就没必要了，毕竟已经有 node+npm ），然后做个在线的 app 市场，用户只需要点击安装即可把 app 下载回来并安装到本地使用。

不过这中间有个难点问题（在开发的时候会遇到），就是启动 app 的时候，是寄生于主进程还是重新启动一个新进程（如果是使用 api 直接加载 asar 执行，那么问题就出来了：菜单栏无法做到独立（在 mac 中测试），以及一些变量污染等等细节，都是挺麻烦的。。

[DoraJDJ]

最明显的就是体积大，若要写一个小程序，最好还是用 cli 或者是其他的 GUI 库。

[oa414]

@dibage

因为曾经了解一点 macOS 开发的皮毛，发现有的想法或者需求，比如控制窗口的一些行为， Cocoa 只需要一两行，而 Electron 下完全做不了因为没封装。。

关于多个应用，我的想法应该还是模拟成多个 App 。这样，无论是在命令行下用 open -a ， Finder 检索，进程独立这些都很方便。

感觉这样下去。。。就变成了一个 ChromeOS 的虚拟机。。

[dibage]

@oa414 哈哈 是的。可能这么做最后下场就是 chrome app

不过按照你所说的，用原生代码比较容易实现，那么可以考虑考虑 react-native for osx ，只不过跟 electron 比起来还是有很多劣势。

说到 chrome os ，还真是可以拿 electron 来封装，做个 web os 。 虽然性能以及实用性 安全性等都不是很理想…

[1990andy]

VScode 就是这么开发的

[dphdjy]

@dibage 我说的不可能是指 达到 VC ， net 什么的装机覆盖。而且本身被使用量极低，并不会有人愿意接入这种库，自己维护更加安全可靠

[zsx]

Electron 每个版本都有 API 改动……就算 API 没改动，用 node-gyp 编译出来的 C++模块也只能对应相应版本 [版本号要严格对应] 的 Electron ，等于你还要下载一大堆。

[exoticknight]

不支持 xp
感觉没了
好吧还是要视开发什么应用的前提下

[oa414]

@dibage 学过 react-native 的 hello world 和学过一点点 react 以及 其他 MVVM 框架，觉得也是一种思路。不过，我觉得现在在 PC 上性能问题倒不是很大，先用浏览器引擎渲染也可以接受。

但 React-native 同样重点在 view ，涉及到之外的一些东西还是要写很多 RCTXXXX ，而且移动端基本应用生命周期靠系统调度，而 PC 上权限大，可以干很多东西，比如做个 CleanMyMac 之类的 App ，可能需要一点原生 API 的内容才能写好。

PC 端上原生 GUI App 开发的资料和大厂的支持、以及社区活跃度都少很多。。。也没有大厂愿意去推动。如果资料充足，社区活跃，写一个不跨平台 app 也并不是很难， OSX 和 iOS 开发还是很像的，但是 NSXXX 比 UIXXX 的资料少太多。此外估计像 Qt ， GTK 的坑也不少，虽然只写过 VB ，但是觉得写 GUI 应用最舒服的或许是在 windows 下吧 ...