有个疑问，如果都觉得 Electron 是电子垃圾，那为啥不直接用用户的浏览器做 UI 而不是自己封一个 Chromium

用户浏览器兼容性不一样啊，我们这边很多客户还在用 IE11 ，让他们升级是不可能的事。

有啊 tauri 啊。

node 是吧，没审好题，忽略

@beijinglowb 这种确实是个问题，，，不过如果只是开源搞个工具的话，好像也没必要在乎这种兼容性，但也没见到哪个开源项目这么玩过，反倒全都是 electron 吃我内存。。。

从普通用户的角度看，Electron 不是电子垃圾，而且，普通用户也不知道什么是 Electron ，也不想知道。

其次，如果 Electron 是电子垃圾，那么对于普通用户来说，启动一个后端，然后再去浏览器里使用，这样的软件比垃圾更垃圾。

普通用户就是喜欢一个软件一个独立界面，普通用户不喜欢浏览器。

@klmd99 tauri 还是用的系统默认 webview 来做渲染嘛，我举例是把渲染这块完全交给用户自己设定的默认浏览器，毕竟 tauri 在 linux 上默认用的是 WebKitGTK ，我没用过，但这个听说是一堆问题？

但如果是直接用用户浏览器打开就没这个问题了嘛，要是展示有问题可以直接让用户使用 chrome ，哈哈

有些软件的 UI 就是这么做的

缺点的话就是浏览器中功能受限的，比如文件处理

@cmdOptionKana 啊？你没明白我的意思啊，如果我用 macos 打包出来一个 app ，用户安装以后顶部托盘出现一个 icon ，有个选项叫打开，用户一点直接打开浏览器拉起 app 界面，至于启动后端 httpserver 这个应该是在启动应用的时候默认就装好的

@snylonue 好吧，，，那是我孤陋寡闻了

@luyinge 那还是浏览器，而不是一个独立的窗口，就会被讨厌。

@luyinge 系统浏览器怎么和你的 APP 通信呢？跨进程的，这个问题你想过没？

之前见过挺多软件都是这么做的。

问题也如楼上所说，浏览器兼容性，你不能假定用户装了啥浏览器。。

而且还得额外占端口，得判断端口是否可用。

@luyinge #8 有这样的软件啊, Mac 端的 Syncthing 不就是这样的软件么, 菜单栏常驻, 打开浏览器操作界面, 但是这根本就不属于标准客户端软件, 而且使用场景很受限, 和系统本地交互受限, 网页是运行在沙盒里面的, 很多需求都实现不了. 如果网页可以满足需求, 那也不需要本地跑一个 http server, 直接连接服务器不就行了么, 所以你说的这个需求就是伪需求, 本末倒置了, 最终又饶了一圈回来了.

是没什么毛病， 我的软件就是这么架构的。


1. pc 是 electron 套 nodejs
2. docker 版是容器里启动 nodejs
3. iOS ，安卓，iPad 版是 react native 里套 nodejs



这样一份代码实现了几乎所有平台。 在网页版里，前后端通过 websocket 通信。 在 electron 里通过 electron ipc 通信。

有个叫 pwa 的可以了解下

如果前端写的代码能够同时兼容 IE11 和 chrome11 ，那确实可以不用 Electron 。

你没见过，不代表没有，当年好多程序功能都是用套 IE 。

golang 的 wails 不错

就程序员觉得 Electron 是电子垃圾，用户不在乎的，页面精美就行

对程序员来说 Electron 是垃圾，CLI 命令行真香；对用户来说 CLI 命令行是垃圾，Electron 真香。

Electron 的下限很高，没有平台限制

Mac 能装 ios 应用，我发现 ios 原生应用比 mac electron 应用要大的多

pgAdmin 好像就是这样的架构 https://www.enterprisedb.com/blog/understanding-pgadmin-4-architecture

https://syncthing.net/ 的电脑端就是这么做的，直接调用了用户的浏览器

浏览器一堆限制，基本的 IO 都是在限制条件下使用，nodejs 让 js 摆脱了浏览器的种种限制，建议了解一下他的用处就知道了

做 WebGUI 是 server 和 client 在同一个实例中，调起浏览器是 server 和 client 在同一个设备，但不在同一个实例

前者可以控制 client 的 request 和外观，后者不能完全控制，还会受到浏览器本身的扩展和脚本影响，如果某些扩展有安全性问题，还会引发数据安全（中间多了一个或多个风险环节），另外就是接管 request 的高级玩法，用 browser 做不到

有，而且这种轮子还挺多，最大的问题就是你面临未知的浏览器版本

以及，赞同 #19

用你说的这种做法，二进制+浏览器+Socket ，最终会随着项目越来越复杂需要的功能越来越多开始遇到通信上的瓶颈，重构变成下一个 Electron

要不然 Electron/NW.js 等等之流为啥要费吃巴力的用各种办法把 Nodejs 和浏览器的 js 上下文粘合在一起呢…

electron 的好处是，

可以拿到操作系统的权限，比如可以读写一些本地文件。比如本地笔记管理 Typora 、Eagle 。
此外可以使用最新版本的浏览器内核，使用一些新特性，也不用考虑兼容问题。
离线也能用，一些编辑器可以做成离线的。
可以开很多窗口

缺点就是安装包太大了，然后本质其实是套壳浏览器，占用内存高，写代码还得用 js ，比不上原生的性能

我赞同你的观点，浏览器负责 ui ，node.js 负责与操作系统交互，保存持久化数据。两者数据交换通过 websocket 进行 rpc 调用，很完美，
唯一不足的是没法看起来像一个有单独界面的程序（托盘、任务栏、窗口等等）

我之前做过一个任务栏工具就这样的，起一个 http 服务器

纯前端部分没什么差异，好比一个前端项目可以直接用 Electron 打包起来。

但是一般用 Electron 不仅是前端项目呀， 还有 node 服务端甚至集成定制化化扩展，这些"本地能力"是纯前端项目受限制或没有的。

一个简单的需求 启动本地程序，这中 web 项目是做不到的

@thinkm 反了吧，程序员才不在乎，只在乎能快速出程序或获利，甚至自己都不用，只有用户受伤害，拿浏览器开发程序的就是一坨坨大便，包括 STEAM 网易音乐那些大厂。

我感觉你可能需要的是 Neutralinojs ，后端是 C++写的一个本地服务器，前端可以让你选择用 webview 、chrome ，甚至可以远程访问 UI 界面。
https://neutralino.js.org/docs/configuration/modes

重新发明 flash ，再不行重新发明 java applet 也算

2010 年前后，国内有一段时间很流行这种做法。
各种 web 版 xx 。实际上就是本机启 web server ，然后给你打开网页，我印象比较深刻的就是 web 迅雷了。

微软的 asp.net blazor 就是这么整的
https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blazor

@miaomiao888 你说的程序员是程序员开发者，他说的程序员是程序员用户

我最近在找 rss 客户端，感觉 electron 就很符合我的需求，内置一个浏览器，必要时也可以用外部浏览器打开，两边可以登录不同的号，
我原本在用 quiteRSS ，功能 OK 但内置浏览器过时太严重了，而且太吃内存，所以想找个 electron 实现的，
找到个 Fluent Reader 挺中意的，就是 electron 实现的，但作者好像不太喜欢内置浏览器，好多 issue 提议优化内置浏览器作者要么无理由拒绝要么直接无视，
只好自己 fork 改改，感觉挺满意的，平时刷 V2EX 就用这个了，

理论上可以，例如 ArchLinux 就是应用只打包 asar ，然后相同大版本的 electron runtime 全局共享。
但 Electron 版本蹦得太快了，而且现在也没有 abi 稳定化的计划，一个系统整七八个版本，空间收益不大还增加了管理难度。
如果某个项目做了深度定制，基本没有共用 runtime 的可能。

依赖系统 Edge Webview2 ，假设用 evergreen 部署模式，那还好些，但还是得小心由于用户原因版本过低导致的问题，至少比 CEF 好些。但 Edge Webview2 还差个 macOS 没上，跨平台差那么点意思。我还没说不支持 Win7 。

事实上，哪怕是现在微软主推的 WinUI3 和.NET ，也是偏好自带 runtime 了，第一方应用（例如 Powertoys ）都这么玩了。

破除一个迷思，对用户来说 electron 也是垃圾

用户的性情总是喜欢折中的调和的，譬如说你想要只支持 Chrome ，大家便会说你不支持 Firefox 不好。但你要给他们的电脑装个 Electron ，他们便会为 Tarui 拍手称快了。

曾经有杀毒软件就是这么做的，调用系统的 IE 浏览器来解析 UI 。。

然后病毒只需要把 IE 浏览器干掉，杀毒软件就崩溃了。。

@stinkytofu 本地跑一个 httpserver 可以做到离线运行，浏览器确实是一个受限环境，但不是还有 nodejs 么，node 负责进行系统层面的操作，然后与网页进行通信即可

当然也不一定限制于 nodejs ，只是如果使用 nodejs 可以很方便的回到 electron 罢了

@wjx0912 pwa 再怎么搞也是浏览器，如果 pwa 能解决问题，那也不会有 electron 往里面塞一个 nodejs 用来与系统进行交互了

@totoro52 对啊，你不然以为我为什么一定要把 nodejs 打包成二进制然后启动 httpserver 与 网页进行 socket 通信，不就是为了突破这个限制么

可能只有有的开发人员认为 electron 是垃圾吧。
真的用户，99.9999% 都不知道啥叫 Electron ，也不知道啥叫 http 。

话说本地二级制文件启动 http server + 系统浏览器的话，那么是不是直接给用户一个网址、二维码、或者直接下载一个网页的快捷方式，然后直接访问远端 http server 更省事呢。

@SHF 所以我也说了用系统原生平台写一个启动按钮嘛，，，而且这种场景下也不太有界面的需求，毕竟都在浏览器上打开了

@cdswyda 不要忽略那个 nodejs 二进制文件嘛，这个是用来操作用户本地文件之类的，单纯的网页又不能做到这种事情

@luyinge #51 那我个人认为还是老老实实用类 electron 这种平台吧，诚然是多点内存，但是真的用户不懂也不 care 的。

不过如果只是开发人员自己折腾的、自用小范围用的、测试用的那就无所谓了，怎么折腾都可以，能实现就行。
我也干过下载内容里面直接带个二进制起个本地 webserve 浏览下载附件的

看了你的一些回复，就知道知道哥们是乐观派（对技术不研究其原理）。
简单说几点，多个平台编译把 nodejs 编译成二进制的难点和需要兼容的地方。抛去 vm ，node 中很多库如何正确执行。
第二，html 的渲染技术，浏览器的接口平台兼容问题，Chromium 是已经经过很多人，很多时间去迭代修复的，electron 算是站在巨人的肩膀上。
如果你还是不是很理解，我就这样比喻吧，你开着电车（ electron ）再问，为什么不发明一种可以几分钟充满续航的燃油车（原生桌面方案）。

主要是纯 web 的很多功能是受限的，比如弹窗，置顶，文件访问之类的

看来只有我没读懂标题

@duron600 我也没懂

@miaomiao888 用户根本不知道什么是 Electron

先问有没有，再问为什么

https://github.com/dukelec/cdpnp

谁告诉你不用的，这么干的很多，只不过不被认为是一种 APP ，Electron 对标的不是这些“本地网站”

我感觉可以，虽然网页功能是受浏览器限制的，但是本地服务不受限，网页和本地服务通过 WebSocket 通信，网页发送指令给本地服务，由本地服务来进行系统交互，比如列出文件列表。
其实就是纯粹的前后端分离，有一些本地软件就是这样的架构，LF 文件管理器似乎就是。还有 bspwm 是通过 bspc 客户端进行几乎所有的操作，如果给 bspc 包装一层网络服务，感觉可以在浏览器里对 bspwm 进行操作。

软件和硬件的发展是相互促进的，就目前的硬件规模来说，electron 这点东西于用户来说根本不是事儿，用户更关心你的功能是否便利，能否提高自己的生产效率，能否让自己心情更舒适等等。

当然开发者关注的点，是硬件使用效率、代码是否优雅、可维护性是否好，开发效率是不是高。

公司关注的是 产品开发周期是否够短、上线速度是否够快、是否满足用户基本需求，成本是不是最低。

这三个角色里面，用户没有选择权，开发者其实也没什么选择权， 公司看了一圈选择 electron 简直是再自然不过的事情。因为开发者可以复用，做 web 的拉过来直接去做客户端，方便快捷，成本省的批爆。 你作为开发者的关注，毫无意义，另外两个角色丝毫不关心。

你这个思路在某些场景还是可以的，但是 Electron 也有它的一些场景优点

其实很简单啊，我当然能不用 Electron ，但是我需要给每个平台都重写一遍，ios ，windows ，mac ，android ，成本翻 4 倍，下载的时候找你收 68 ￥

你是不是就觉得 Electron 也还行？

我只有 ie,为什么你要给我装新浏览器???

以前见过有这样做的.
我觉得如果软件对本地 IO 要求不高, 可以这么搞. 再加上 PWA, 如果能自动把网页安装为 PWA, server 端启动后, 自动打开 PWA, 那么对用户来说, 这就是一个独立的软件了.

我一直很奇怪 为啥 electron 要每个应用都自己起一个引擎，而不是像浏览器多 tab 页一样共享同一个引擎

浏览器不能直接给高级权限

@cdswyda #46 用户不知道啥叫 Electron ，他们只会骂软件垃圾

那 webview2 是否比 electron 会更好一些呢

@ns09005264 #60 本地服务是不受限制, 但是你各个平台的本地服务还是得用各个平台的原生代码开发一遍, 只是省了网页 UI 那点代码, 还要额外的给每个平台都开发一个 http server, 实际上的工作量还不一定少, 和跨平台开发的初衷相悖

远程 PWA 能和本地起的服务端口有权限通信吗，如果可以那不安装本地部分可以只用远程部分，需要本地增强功能可以再安装个本地增强服务，这不比 electron 强多了

如果用户没有安装 Chrome 呢

@Nich0la5 为了解决兼容性问题。

OP 的这种做法太不可靠了，如果用户没有安装浏览器怎么办。如果用户安装的是 Firefox 或者其他小厂远古 Chromium 内核浏览器怎么办。

Electron 这么做就是为了最大程度确保所有用户看到的界面实现的效果是符合开发者预料的，开发者不需要关心兼容性问题只要处理业务就行了。Electron 是成熟是可以商业化方案，它面向的是所有 PC 平台的用户，不是给个人开发个项目发个版本就三五个用户用的，稳定可靠才是最重要的。

有这样做的啊，很多一开始针对超算远程平台设计的软件做一个本地运行的 desktop 版就这样搞，按 F12 打开控制台拿到链接就能直接在随便浏览器访问了。

#68 不知道哪里来的优越感，用 Electron 的都是垃圾吗？ 那么看看每天在用多少垃圾？

工具永远只是工具。

webview2：有人在叫我？
node 和.net 强强联合，但是限制是要 win10+

@Nich0la5 为了安全

主要还是权限和存储问题吧

这里主要是 windows 全责，推进 webview 时间太迟了，远远落后安卓和 mac 。
大体量用户的产品估计也不会用 webview 。。。表现不一的问题 firefox 和 chrome 相互都没打通。

@stinkytofu

後可用 Nodejs (portable zip 30MB), Node.js 自 http server.

我举个例，腾讯 qq 的 web 快捷登录，就是开了个 http 接口。

感觉看开发。有些应用还是很不错的，有些应用超卡。

当你说垃圾的时候，首先你想好是跟谁比。Electron 垃圾，是标的原生应用。这时候你再让 Electron 跟 Web 做对比，那只是垃圾跟圾垃的对比，毫无意义。

可以搞，但是需要考虑很多东西，也可以做的更完善一些，例如自动判断浏览器版本 路径， 以 APP 模式启动，如果不存在合适的浏览器 提示用户主动下载安装，跳转下载页。特别是现在基本都 win10 edge 了 就更好做了。

就应该让 chrome 内部实现自动共享资源，这是 chrome 的问题
还要共享的同时保证安全

Electron 一开始仅仅是为了 Atom 编辑器开发的
早知道今天那么多软件会用，估计就做成像 Flash Player 那样的了

用户才会觉得 Electron 垃圾...只是用户不知道而已
知道 Electron 的用户都是程序员所以产生了程序员觉得 Electron 垃圾的错觉

Electron 的问题是又臃肿又慢,核心就是 js 不够行

程序员写 Electron 方便得 1b 好么,总比用其他东西写 ui 来的快多了

electron 特别适合医院、企业等使用，都是统一定制机器，统一安装客户端，没兼容性，实际上大面积在用。

golang 的 wails 就是，调用浏览器的 webview

是有人这么做的

@luyinge #46 别硬拗了， 大部分场景是先确定要客户端应用才选型 QT/Electron/.Net Deskdop ，而不是做一个 web 项目要不要 Electron 打包的问题

另外远程启动的 nodejs 服务和用户本地启动 nodejs 服务 是一回事吗？

用户端插个 USB 证书也能通过远程服务读取吗？服务如果要开机启动呢？

Electron 是解决 CS 架构移植和开发效率问题， 不是替代 Web 项目的！

@bianhui #53 我举个更生动地例子：现在的手机都考虑提高充电速度和电芯大小来解决电量问题，为什么不“发明”可以更换电池的手机呢！

@jiangzm 有什么好硬拗的，我就是自己搞一个桌面端应用觉得 electron 太笨重了想换个法子啊。

远程启动 nodejs 跟本地启动 nodejs 当然不是一回事，但浏览器这种受限环境在本地启动一个 http server 来加载 ui 并且通过 socket -> nodejs 的链路来调用浏览器无法调用的本地服务有什么问题么？

我标题内容已经说了：“然后使用系统原生平台做一个启动按钮”，都原生有个启动器了，加个开机启动有什么难的

本质上我就是想要借助 web 构建 ui 界面的便捷，然后又不想要 electron 的笨拙，我当然知道这个方案不适合所有人，就像 electron 也不适合所有人一样，适合我就行了啊

手机 APP 的资源占用都是按 G 算的，电脑的资源比手机多多了，用户不差那点空间

我觉得跟小而美这个动辄吃我 40G 硬盘+3G 内存的玩意儿比，electron 的产品肯定不是垃圾，不如说多亏了 electron ，linux 上也能有一些现代的应用比如 spotify telegram discord 等等

一个是很多软件不是只做信息展示而已. 而且还要做很多浏览器无法实现的功能. 例如文件的读写, 调用本地程序, 跟硬件交互等. 例如 QQNT 就是. QQNT 的底层是 C++ 的, 只有展示层是 Electron. 这就涉及到大量的 ffnapi 操作. 浏览器怕是无法实现的.

另外很多 Electron 程序也是涉及到跟硬件驱动跟硬件 SDK 交互的 (如扫描仪, 打印机, 工控设备, 锁控板等), 纯浏览器是很难实现甚至可能无法做到的.

楼主说的架构好像类似 pgAdmin 这几年新版本的搞法。但是面向的使用者群体不一样的。
类似 pgAdmin 这种面相开发者的，问题确实不大。但是面向大众的应用使用这种方式，别说到普通用户了，就连产品经理和公司 Leader 那一关都不过去。

你说的方案很多也都在用啊，比如 LOL 客户端，steam 客户端都是 chromium embedded framework 的吧，然后很多功能就是点击跳转浏览器，不过基本只适合这种不怎么需要和系统硬件交互的前端

@AoEiuV020JP #40 老哥 Win 平台刷 RSS 有什么好用的客户端吗？ 能支持 Inoreader 的那种。
我试了能找到的所有的，没有一个能顺利的拉取 Inoreader 流的

具体还是要看应用场景的，比如工具类的软件，反正用户平时也是用 xx 工具在线去做转换，在浏览器里这种方式会更合适一些

目前 LafTools 采用的是这种设计，既可以 http 也可以 electron ，取决于用户是否在乎内存，这个项目还在开发中，欢迎 star

https://github.com/work7z/LafTools