這幾天在構思項目，研究了一下Electron，記錄下來。 說起WEB桌面程式，當前最火的就是Electron了。 Electron的架構用一句話總結，就是一個main.js進程加上一個或數個chrome視窗，每個視窗都包含一個獨立的Node.js。 這樣的架構，使得這種桌面應用必須是一個（或數個）單 ...
這幾天在構思項目，研究了一下Electron，記錄下來。
說起WEB桌面程式，當前最火的就是Electron了。
Electron的架構用一句話總結，就是一個main.js進程加上一個或數個chrome視窗，每個視窗都包含一個獨立的Node.js。
這樣的架構，使得這種桌面應用必須是一個（或數個）單頁面應用（SPA），而這個SPA還擁有訪問本地API的能力（Node.js）。
一方面，程式對前端框架的依賴必然加強，想再JQuery打天下就不那麼容易了；另一方面也大大加強了前端框架的能力與版圖。
這樣它把前端與後端的戰火，從伺服器蔓延到了桌面。使得JS解決一切的宗旨，又得到了貫徹。
相比較這種新的架構，還有三種早已出現在WEB桌面程式。一般基於嵌入式Chromium框架（CEF）。
一種就是CEF+遠程訪問。這種程式體驗極差，就是個單頁面的網站。
值得註意的是Electron+遠程訪問，是極度危險的，只需劫持JS，則可利用Node.js為所欲為。
另一種就CEF+本地服務。本地服務常見的有.net和java，也有用PHP和Node.js的。
這種組合與前一種組合體驗類似，而且體積臃腫，但勝在頁面延時較小。
最後一種就是CEF+本地資源+遠程API介面。這種是手機WebAPP的常用模式。體驗尚可。
和這些架構比較起來，Electron的體驗和能力上得到很大的增強，但是有著天生的弱點。
一、安全性，這是腳本語言的弱點
二、投入大，SPA不同於原有的WEB開發，必然導致新的投入和舊資源的浪費。
三、體驗，雖然WEB應用的體驗在不斷增強，但天生就必然限制在chrome視窗中
理想當中的混合應用應該是Electron作為模塊嵌入其它編譯型語言中，不必追求JS解決一切，更不要追求一切皆是WEB。
強強聯合，團隊作戰的效果遠大於語言或平臺大一統帶來的好處。
比如這個go-astilectron項目，使用GO語言開發主進程代替main.js，弱化JS的依賴是個不錯的想法，但還遠不成熟。
（完）
