有好幾個公眾號發文說“微軟要放棄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的支援力度和支援永續性是值得擔憂，尤其是：這個團隊剛剛在不久前放棄了自己的瀏覽器引擎！
