有好几个公众号发文说“微软要放弃Electron了”，实际情况是微软旗下的Teams产品打算把Electron框架换成WebView2而已。接下来我就聊一下这个事情：
微软不会放弃Electron
第一：Electron是GitHub的产品，GitHub是微软的子公司，WebView2是Edge团队的产品（是Edge的副产物），Edge团队是微软直属的团队，所以事情就是：Teams打算切换一下自己的底层框架，而且这两个框架都是自己公司的产品，并不是放弃自己公司的框架，用了其他公司的框架。
第二：微软内部有很多软件都是基于Electron开发的，比如VSCode和GitHubDesktop，不仅仅是只有Teams这么一个产品在用它，非但微软内部，包括Facebook、MongoDB、twitch、Slack、迅雷、字节跳动、阿里、拼多多、京东等大企业都在用这个框架，这么一个好东西，微软怎么会放弃它呢？
第三：Teams之所以要把Electron换成WebView2，并不是因为Electron不好，而是因为Electron不称手，就像一个木匠换个锤子敲钉子一样普通，对于那些Electron的从业者，或者想进入Electron这个领域的开发者，没什么好担心的。
具体的技术细节
第一：开发者是没有办法只用前端技术基于WebView2开发桌面应用的。开发者要满足类似：读写文件、访问剪切板、设置托盘图标这类系统级需求，就必须自己写C 或者C#代码来实现。而这对于Electron的开发者来说，只要写JavaScript就可以了。
第二：WebView2目前是没跨平台能力的，也就是说基于WebView2开发的桌面应用仅能在Windows操作系统下运行，无法在Mac或者Linux下运行，即使将来WebView2提供了跨平台能力，那么开发者写的C 代码就要考虑如何在不同的平台下调用不同的系统API，如果开发者写的是C#代码，那么就要考虑如何把.NET框架分发给他们的用户了。显然Teams产品是一个跨平台的产品，他们财大气粗，很有可能Windows系统用WebView2实现，其他系统用原生技术实现，或者与系统API有关的C 代码写3次也没问题。我们普通开发者就很难这么做。
第三：WebView2要求开发者使用C 或者C#实现系统级需求，这就给了开发者精细化控制的能力，我想这也是Teams团队看中的东西，然而要想获得这种能力为什么不直接选Qt的QWebEngin或者cef呢？毕竟他们和WebView2一样都是对Chromium内核的封装，很显然微软的团队是不能做这种决定的，因为Qt有版权的问题，cef也不是自家的东西。相对来说我们普通开发者在这种选择上就自由很多。
第四：WebView2目前还很不成熟，我上次调研它时，它还不支持自定义Scheme（如果它不支持，开发者很难通过C 或C#代码让应用具备这方面的能力的），甚至连PrintToPdf这类API也还是几个版本前才提供出来的。
第五：WebView2的生态很不好，想想看：你如何在应用中自如的使用Sqlite（能获得类似Knex.js这样的支持吗）、如何让你的应用读取并显示一个本地大文件（大概率要自己实现流式读取的机制，要把文件数据Chunk转成ArrayBuffer再交给界面的Js，涉及到各种编解码及进程间通信的问题）
第六：WebView2是不开源的，这更加恶化了WebView2的生态；而且对于一些疑难杂症来说，开发者也很难进行源码级别的调试。有些开发者可能会认为这或许有利于保护源码，估计这些开发者不知道怎么让Electron保护自己的源码，这里说一下思路：开发者可以把Electron源码拉到本地，修改asar拆包封包的逻辑，然后再自己编译一下Electron，这样就可以保护应用的源码了。
第七：WebView2的性能提升或资源消耗削减可能并没有那么明显，我们都知道，只要使用Chromium，就难逃多进程架构，WebView2也不例外，它的进程甚至比Electron的进程还要多一个。多进程才是资源消耗高的症结所在。它的优势就是可以和其他应用共享进程。但假设用户也没开Edge，也没打开其他WebView2应用呢？这种优势还体现的出来吗？因为要自己实现系统级需求，不再需要加载Node框架，性能提升或许有一些（这取决于开发者的能力），但为了这些性能提升舍弃的东西也太多了，我们普通开发者难以承受。
第八：WebView2是Edge团队的副产物，没错，是个副产物，他们的主要职责是做好Edge，而不是做好WebView2，他们对WebView2的支持力度和支持持久性是值得担忧，尤其是：这个团队刚刚在不久前放弃了自己的浏览器引擎！
