Electron團隊提供remote模組給開發者，
主要目的是為了簡化渲染程式和主程式互訪的難度，
這個目的卻是達到了。
但也帶來了很多問題，
歸納起來主要分為以下四點：
第一：它很慢
通過remote模組可以訪問主程式的物件、型別、方法，
但這些操作都是跨程式的，
跨程式操作效能上的損耗可能是程式內操作的幾百倍甚至上千倍。
假設你在渲染程式通過remote模組建立了一個BrowserWindow物件，
不但你建立這個物件的過程很慢，
後面你使用這個物件的過程也很慢。
小到更新這個物件的屬性，
大到使用這個物件的方法，
都是跨程式的，
這種累積性的效能損耗，
可想而知影響有多大。
第二：它會製造混亂
假設我們在渲染程式中通過remote模組使用了主程式的某個物件，
此物件在某個時刻會觸發一個事件（BrowserWindow物件中就有很多這樣的事件），
事件處理程式是在渲染程式中註冊的，
當事件發生時，實際上是主程式的原始物件先接到這個事件，
再非同步的通知渲染程式要執行事件處理程式，
此時可能已經錯過了很多事情，
類似event.preventDefault()這樣的操作可能毫無意義。
在一個業務複雜的應用中這類錯誤非常難排查。
第三：它會製造假象
我們在渲染程式中通過remote模組使用了主程式的某個物件，
得到的是這個物件的對映，是一個代理物件，
它看起來像是真正的物件，但實際上不是。
首先這個物件原型鏈上的屬性不會被對映到渲染程式的代理物件上。
其次類似NaN、Infinity這樣的值不會被正確的對映給渲染程式，
如果一個主程式方法返回一個NaN值
那麼渲染程式通過remote模組訪問這個方法將會得到undefined。
第四：它存在安全問題
因為remote模組底層還是通過IPC管道與主程式通訊的，
那麼假設你的應用需要載入第三方網頁，
即使你讓這些網頁執行在安全沙箱內，
惡意程式碼仍可能通過原型汙染攻擊來模擬remote模組的遠端訊息
以獲取訪問主程式模組的權力，逃離沙箱的控制。
反思
remote模組並非一無是處
Electron程式間通訊確實非常複雜，
不但增加了開發人員的勞動，還增加了開發人員的心智負擔
沒有remote模組開發人員該怎麼辦呢
要麼就實現自己的程式間通訊工具（我就做過一個跨程式的訊息匯流排）
要麼就強行引入remote模組
實際上remote模組並非被幹掉了
而是從核心模組變成了可供開發者選擇的模組
決策權交給了開發者
但開發者再使用remote模組時，一定要考慮上面提到的那四個問題
不然你的應用程式可能會存在不穩定的現象。