Electron團隊為什麼要幹掉remote子產品

Electron團隊提供remote子產品給開發者，

主要目的是為了簡化渲染程序和主程序互訪的難度，

這個目的卻是達到了。

但也帶來了很多問題，

歸納起來主要分為以下四點：

第一：它很慢

通過remote子產品可以通路主程序的對象、類型、方法，

但這些操作都是跨程序的，

跨程序操作性能上的損耗可能是程序内操作的幾百倍甚至上千倍。

假設你在渲染程序通過remote子產品建立了一個BrowserWindow對象，

不但你建立這個對象的過程很慢，

後面你使用這個對象的過程也很慢。

小到更新這個對象的屬性，

大到使用這個對象的方法，

都是跨程序的，

這種累積性的性能損耗，

可想而知影響有多大。

第二：它會制造混亂

假設我們在渲染程序中通過remote子產品使用了主程序的某個對象，

此對象在某個時刻會觸發一個事件（BrowserWindow對象中就有很多這樣的事件），

事件處理程式是在渲染程序中注冊的，

當事件發生時，實際上是主程序的原始對象先接到這個事件，

再異步的通知渲染程序要執行事件處理程式，

此時可能已經錯過了很多事情，

類似event.preventDefault()這樣的操作可能毫無意義。

在一個業務複雜的應用中這類錯誤非常難排查。

第三：它會制造假象

我們在渲染程序中通過remote子產品使用了主程序的某個對象，

得到的是這個對象的映射，是一個代理對象，

它看起來像是真正的對象，但實際上不是。

首先這個對象原型鍊上的屬性不會被映射到渲染程序的代理對象上。

其次類似NaN、Infinity這樣的值不會被正确的映射給渲染程序，

如果一個主程序方法傳回一個NaN值

那麼渲染程序通過remote子產品通路這個方法将會得到undefined。

第四：它存在安全問題

因為remote子產品底層還是通過IPC管道與主程序通信的，

那麼假設你的應用需要加載第三方網頁，

即使你讓這些網頁運作在安全沙箱内，

惡意代碼仍可能通過原型污染攻擊來模拟remote子產品的遠端消息

以擷取通路主程序子產品的權力，逃離沙箱的控制。

反思

remote子產品并非一無是處

Electron程序間通訊确實非常複雜，

不但增加了開發人員的勞動，還增加了開發人員的心智負擔

沒有remote子產品開發人員該怎麼辦呢

要麼就實作自己的程序間通信工具（我就做過一個跨程序的消息總線）

要麼就強行引入remote子產品

實際上remote子產品并非被幹掉了

而是從核心子產品變成了可供開發者選擇的子產品

決策權交給了開發者

但開發者再使用remote子產品時，一定要考慮上面提到的那四個問題

不然你的應用程式可能會存在不穩定的現象。