CEF Detector - 你的电脑上共有几个 Chromium 内核的应用？ - 小众软件 (appinn.com)
本讨论基于以上文章，我在想，java的应用，其实是可以精简掉JRE，然后使用系统中已经存在的JRE来运行的。那么像electron之类的Chromium 内核应用，能不能也把内核删掉，然后调用系统中已经有的内核呢？
补充一下：我看回复大家好像误解了，我的意思不是从开发角度，而是从用户角度，比如我下载了一个electron应用，100+M，但是核心只有2M，其他都是chrome核心占的空间，那我删除掉该应用的chrome核心，用什么方式让它去调用系统中已经存在的chrome核心，同样可以跑起来呢。。
您是否在搜索：IE？
正经的说，这事肯定有人想过，然后他们发现Chromium等内核版本差异太大没法信赖系统自带的，于是只能把自己用的版本打包进去……
有的，可以看看tauri还有go语言的wails。
都是调用的系统的webview，编译出来程序就几M，占用和性能也比electron强不少。
现在系统webview兼容性已经比当年强太多了。
然而可惜很多人还是在用electron。
如果只做 Windows 的话，还有一个技术是 .hta 文件，随便写个 html 页面改名 .hta 就能跑起来，里面运行的 javascript 不会有安全限制，能够随意读写电脑里面的文件，也能联网。
使用 Qt 的话，也有 QtActive 技术，能够嵌入 IE 内核，现在应该也能嵌入 edge 内核。
非 Windows 环境一般就不用考虑了。反正也没什么用户。
您是否在找：Edge Webview2
补充一下：我看回复大家好像误解了，我的意思不是从开发角度，而是从用户角度，比如我下载了一个electron应用，102M，但是核心只有2M，其他100M都是chrome核心程序占的空间，那我删除掉该该应用的chrome核心，用什么方式让它去调用系统中已经存在的chrome核心，同样可以跑起来呢。。这样我就给这个应用节约了100M，也方便分享。 
这个可能很难，每个开发者用的版本不同，可能有兼容性问题
想法很好,开发者都应该换webview2
electron不可能有好方法一键替换,毕竟不同electron程序的ffi,node,内核版本都可能有兼容问题,32和64的也不一样
微软基于Edge搞了一个Webview2，目的是为了替代iehtml，就类似于你说的。目前tauri做出来的东西都是调用这个作为浏览器内核。
之所以能“精简”，也是开发 Java 应用的人有意无意地提供了这种调用“系统中已经存在的 JRE” 的特性。
只能从用户角度来解决的话，我能想到的思路是，对比应用里包含的文件和”系统中已经存在的“文件，然后把共通的文件从应用里删除，改为用硬链接（以 Windows 系统为例）映射到”系统中已经存在的“文件。这样就能节省一些磁盘空间。
这种老是想精简省空间的想法，总是想着一个个都统一使用依赖库调用，其实都挺极客的。
对于普通用户其实很不友好。
在硬件发展到今天这个底部，存储空间其实挺充裕的，并不是特别重要的矛盾点。
反到是开发者基于不同版本的依赖库，实现不同的特性，导致不同的兼容问题，才是系统内置的弊端。一旦出现奇奇怪怪不兼容的问题，就不是开发的问题，是用户与产品之间的信任问题。
程序直接打包好所有依赖库，正确的版本，正确的功能实现，正确的兼容，开箱即用，多好。
让普通用户关注系统里的依赖库，关注内置webview版本，大部分产品就都得死。
说到库版本依赖冲突，我一直很奇怪，
明明有很简单的解决办法，但从linux到win到js都没有解决：
整个os只需要一套公共库目录，里面放库名子目录，库名子目录里面是版本号子目录
应用需要什么库就到对应的库名目录，如果版本还有特别要求，就到对应的版本号目录 去加载库文件。
如果这些目录不存在，就去下载或提醒用户去下载补齐
好像很简单直观有效，为什么没人想到没人去实现？
为什么专门提到js，因为它是最近实现的，但nodejs/npm（低版本）还是搞出了一个笑话
是的，webview的确在这么做，也挺好用。但这仍然是未来的一种解决方案，而不能解决目前的问题。
其实也并不是这么绝对，很多小工具，明明一个exe就解决了，分享也方便，小白也不用告诉他需要在众多文件中找到xxx.exe，或者安装完毕打开快捷方式。而且除了硬盘空间，这种被迫做大的文件打开是真的慢。
没可能，原因前面的讲了不兼容，除非让electron重做v2的时候考虑兼容性进行设计
在electron项目仓库有一个9年前的Issuse，现在还是Open状态。
各种解决方案都有，但显然维护团队对此的态度很冷淡。
目前各类主流框架走的就是社区驱动风格，更新速度快，维护周期短。electron是其中的佼佼者，更新策略尤其激进，八周一个大版本，每个大版本不到一年甚至不到半年的维护周期，动辄增删改旧有API，没有稳定的LTS版本 。
在这种情况下，大多数开发者肯定都会选择整体打包，一键部署的模式，在硬件成本低廉的现在，这种模式对用户来说安装难度更低，更友好。
我自己的话倒是觉得这种打包的模式没什么不好，我真正反感的是有些或蠢或坏的倒霉玩意儿，强制把应用安装到%appdata%文件夹，导致我现在遇到安装程序，第一步不是运行，而是解压。
回到正题，“从用户角度”，如果一定想要搞，办法是有，但麻烦且糟心。
首先，下载二十几个一共两三G的electron版本。未必每个发行版都要下载，但一定要对照重要更新列表，把有API变动的版本搞全。
然后检查现有应用保留resources文件夹和locales文件夹中需要的语言，然后写个配置。例如
AppName=Foo;
AppPath=resources/Foo.asar;
RuntimeVersion=22.0;
最后直接写个程序或者写个bat，ps之类的脚本，通过这个配置，用相应的electron版本运行程序……
要是人家的electron版本是自己编译的，加了私货，那还得继续折腾……
这个办法吧，用户弄起来就是费力不讨好。开发者主动支持倒是可以，但凭啥啊，人家凭本事改的图标和文件名对吧。
实际上也没用他想象中那么差。
当年还没有flatpak这类东西，作为一个普通用户接触linux并尝试当主力系统的时候，装几个软件结果依赖地狱一天没整明白后二话不说直接放弃转回windows
一个exe可以分为很多很多种情况。。。
我自己也会偶尔写c#，那个exe真的小，还带gui，几百kb，很多功能。但是要装.net库，其实整体的程序实现并不小，算上运行库的话。安装.net库就是一个门槛，给一些普通员工用，教安装运行库，费神。
网上有些绿色单文件exe其实就是个压缩包，打包了一大堆文件，在temp解压再运行，这其实也不小，还乱丢垃圾。
还有一些情况，某些软件经常依赖各种版本的vc运行库，门槛是真的有，直接目录下放好各种dll就好了。不要那么抠门，省那点硬盘空间。