[技術產品] 用node-webkit做桌面應用
陳天
· 2 年前 小長假就這麼結束了，本來打算抽空用node-webkit寫點什麼的，結果中間一天加班，前後兩天出去玩，累了個半死。也沒顧上。
node-webkit是兩週前我纔剛剛認識的桌面開發利器。那天程序君寫了篇關於github atom的文章，中間有段文字做了大膽的猜測：「這就是Atom最大的亮點！web native。在此之下，less style，coffeescript plugin，nodejs integration都水到渠成。看上去atom的源代碼來自chrome —— 我覺得atom很可能是一款以某種方式運行本地web app的瀏覽器。chrome的源代碼base在webkit上（貌似是bsd），所以atom可以任意修改。很可能chrome上面的沙箱環境（不允許web app訪問本地資源，如文件系統）被移除，然後nodejs以某種方式被集成進來（這樣javascript可以訪問文件系統等本地資源）。」
很快有不少朋友或在知乎上，或在微信裏給我留言，不約而同地提到了一個技術：node-webkit。所謂「三人行，必有我師」，感謝這些讀者，你們爲我開了一扇窗。^_^ 孤陋寡聞的程序君知道了這個技術後，便如飢似渴地研究了下去...如今兩週過去了，程序君也有點點小小的心得來回饋大家，尤其是當時爲我指引迷津的朋友。
我會按照：what - why - how 的順序介紹node-webkit。
What
不瞭解web-native技術的程序員可以先稍稍瞭解一下webkit和基於webkit之上的chromium兩個開源項目。兩者都是BSD license的瀏覽器項目。chromium的商業化產品就是我們熟悉的chrome瀏覽器（我的好基友）。chromium基本就是一個操作系統，裏面提供了非常複雜的協議棧和各種功能，包括但不限於：
- 跨平臺的系統資源訪問，如文件系統
- 各種互聯網相關協議，如HTTP, HTTPS, FTP, DNS, etc.
- 強大的併發處理能力
- 各種壓縮協議和算法
- 頁面快速渲染
- javascript執行引擎
- 磁盤緩存機制
- ...
可以看這張圖：
然而，爲了避免來自非受信域（互聯網）上的應用進行一些非法操作，chromium提供了嚴格的沙箱環境，讓本地的很多信息（比如文件系統）不會暴露給互聯網上的應用。
chronium強大的功能讓人垂涎，又是BSD license，以此爲基礎做一個應用程序誘惑力很大：跨平臺，各種已經建好的功能，深度整合互聯網技術等。所以它是做桌面應用的一個利器。可是，chronium對於未在瀏覽器行業浸淫的小團隊來說困難了些。因爲你要讀懂chronium的content API文檔，要了解很多技術細節，更重要的是，基本上你需要使用C++來開發應用。google看到了裏面的機會，將chronium項目封裝出一套使用簡單的API，並（在第三方的協助下）提供了很多不同語言的binding，這樣你就可以使用你熟悉的語言進行桌面應用程序的開發，這個就是CEF（Chrome Embedded Framework）。
投抱CEF懷抱的知名項目有：
- Adobe Bracket
- Evernote
- 豌豆莢
我沒有太研究CEF，所以就不多說。
node-webkit另闢蹊蹺，它沒有基於官方的CEF進行二次開發，而是做了如下事情：
(1) 將nodejs的消息循環和chromium的結合起來，讓使用者可以在dom裏調用nodej.js的函數。
(2) 合併nodejs和chromium兩者裏的web引擎（都基於v8）。這樣所有javascript運行在一個context下。
(3) 修改沙箱模型，去除很多對桌面應用而言沒有意義的安全手段，讓應用可以最大程度訪問本地資源（比如文件，本地網絡等）。
node-webkit最大優勢是很巧妙地把nodejs結合到chronium裏，讓你可以使用幾乎所有的nodejs社區裏的module。
投抱node-webkit的知名項目有 LightTable。
Why
無論CEF還是node-webkit，都大大降低了寫複雜桌面應用的難度：不需要C++，不需要QT，不需要java，你只需要懂html，css和javascript，就能寫出本來難度不小的桌面應用。 除此之外，還有好幾個跟現代軟件相關的原因：
現代軟件不和互聯網結合就是慢性自殺。
現代軟件沒有漂亮的UI就如同沒有學會打扮但很有內涵的姑娘。
現代軟件不能跨平臺就會少很多高端用戶（mac佔有率已經接近7%了）。
所有種種，CEF和node-webkit都能提供支持，相對於CEF，node-webkit使用起來更簡單，對nodejs社區的良好支持是個殺手鐗。如果你稍稍看看adobe brackets（一個代碼編輯器）的代碼，就會發現其在本地文件系統的支持上花了多少功夫。而使用node-webkit，引用fs的package即可。（當然，我相信不久的將來，CEF對此會做修改和優化）
How
"How" 是我們開啓一段程序旅程的最困難的部分。所謂細節是魔鬼，難就難在怎麼做這樣的細節上。對於node-webkit，你可以follow其repo（https://github.com/rogerwang/node-webkit）裏的wiki，一步一步做，就能成功做出一個Hello world程序。
這似乎很簡單 - 不就是寫個 package.json，外加個index.html？何難之有？
但我們想要的絕對不是hello world。我們想做的往往要複雜得多。所以我們需要一套完整的解決方案，問問自己這些問題：
(1) 我的代碼用什麼撰寫？（程序君用coffeescript, less和handlebars）
(2) 我的應用打算使用什麼樣的MVC庫？（ember, angular, backbone, etc.）
(3) 我的應用都有那些前端的（bower）和後端的依賴（npm）？
(4) 如何打包和發行？
(5) 如何測試？
(6) ...
怎麼撰寫代碼取決於你打算如何維護你的應用。最簡單的方式當然是直接撰寫html, css, js，但是這樣容易產生意大利麪條式的代碼。一般web前端都是使用各種技術最終打包出來html, css和js。
如何測試很重要。雖然你在寫桌面應用，但大部分代碼都是爲界面和交互提供服務的。如果這樣的代碼還不得不運行在node-webkit裏，而不是瀏覽器中，那麼開發的效率會大打折扣。
經過深入探索，程序君獲得的答案是這些工具和項目：
brunch是打包工具，後兩者都是項目的template。
angular的擁躉直接用node-webkit-hipster-seed就好了，封裝得已經近乎完美。但angular不是程序君的菜，所以程序君又重新拾起已一年多未使用的ember，基於 tapas-with-ember 做了一套符合程序君自己需要的template project。你如果感興趣，可以
$ brunch new https://github.com/coderena/node-webkit-template test
來試試這個template結構。基本上它提供了一個非常靈活的架構，可以適應應用程序的不斷增長。
先寫這麼多，等我有了更多的經驗，會繼續分享。
如果你對本文感興趣，歡迎訂閱公衆號『程序人生』（搜索微信號 programmer_life）。每天一篇原汁原味的文章，早8點與您相會。