纯网页服务历来广受大家认可，有些网站甚至以其作为亮点。但就我个人来看， Electron 应用常常因资源开销大、强制从网页版转至客户端等性质而令人十分膈应。
若能将任意electron程序提取并整合至一般浏览器中，作为普通标签页运行，即可实现内核共享、统一资源调度与一致的视觉体验。
然而，Electron 依赖 Node.js 等专属 API，Chrome等浏览器不能直接运行。
我暂时想出了下面几个解决方案：
-
编写浏览器兼容层： 手动实现所有扩展api，在权限范围内尽可能完成原api的功能，并且在必要时返回欺骗数据。
优点是开销低、用户无感；缺点是工程量大，兼容性处理难度极大，适配性强弱还得看具体情况。
-
视觉上嵌入浏览器标签页： 把electron应用窗口直接拼进浏览器标签页中。
优点是工程量小、用户无感；缺点是开销较高，且资源调度只有部分能转发，且底层未真正融入浏览器。总感觉有点在哄人（？）
-
令用户改用 Electron 内核浏览器：在新标签页中直接打开electron程序。
优点是开销低、资源统一调度且适配完美；缺点是可能需要强制更改用户习惯，阻力极大。这可能比前两个方案的问题还要大…
-
待补充，上面的方案的修补、混合或折中，或者，还有更优解？
光搞定 Node.js 的专属 API 不够，还得搞定 Node.js 调用的其他各种 API，所以关于兼容层，可以等大佬搞定在浏览器中跑完整的 Linux 发行版
我不是开发者，目标是转换现有的所有electron程序
shadows
(shadows)
5
不一定能吧，网页上的限制很多，这种问题可以先问ai
而且你修改了浏览器，还得electron软件方面配合你，浏览器还在不断更新，想想都觉得后续维护很恐怖
electron软件使用的chrome内核不一定同一版本，不同版本的兼容你也要弄 
1 个赞
那肯定是不能的，一般涉及到electron的问题，想想一个极端案例vscode就能想通99%的问题）
2 个赞
其实已经借助ai对三个方案进行了初步验证。
是的，您提到了文中的方案一，在初步验证中方案一也确实跑不通，但是方案二和三就不需要更改内核了，或许有一定可行性
方案一要实现确实实在是太难了…但二和三对vscode有效
Xenon
(苦逼学生)
9
有没有想过一个问题：为什么electron应用要自己打包一个浏览器环境？
原因很简单，浏览器本身的生态就很复杂，你永远不知道用户在用什么古董。
别的暂且不提，光javascript这座屎山就够开发者喝一壶了
所以回到标题，我并不认为能做到，不只是专属API的问题。
哪怕是传统SPA应用，也不能保证在所有浏览器上完美运行，全靠polyfill一类的项目撑着
2 个赞
3_5105
10
如果使用方案2或3，则可以保证用户跟随electron的最新版本，2可能有点形式主义，但3则可以使得electron程序有最新的内核可供调用。
但是仍然有问题，用户很可能不愿意更换浏览器，electron程序如果版本太旧，新内核也无法兼容。
laizn
(Readman)
11
大部分electron应用应该没有魔改Electron的能力，所以只要把兼容层做好肯定能做到复用chromeium内核，主进程+node.js肯定得独立进程吧，然后渲染进程倒是可以合并，但是合并了以后如果所有应用的renderer js走同一个事件循环，很可能容易卡。
关键搞这么费劲应该只能得到一个有缺陷的简单闭源App。像QQ这种魔改过的Electron肯定别想塞进来了。
1 个赞
vevan
(vevan)
12
你先问问为什么开发者不直接开发网页版，而要用electron呢？