從用 AngularJS 開發 PC 客戶端說起
最近一個多月一直在用 AngularJS 做公司的一個項目（還沒有做完），我之前主要是用 PHP 開發服務端的，AngularJS 也是現學現賣，整個過程還是比較有意義的，覺得很有必要寫篇文章記錄一下。
緣起
事情是這樣的……我們團隊的產品是一款 PC 客戶端，客戶端的界面主要是用 C++ 開發的，還有部分界面其實就是用 IE 瀏覽器內嵌了服務端的 web 頁面。在這個時期，項目經理帶著一個 C++ 同事寫界面（對的，我們項目經理是寫代碼的老手），然后很苦……而對于 IE 瀏覽器，策略是用戶 PC 上是哪個版本的 IE 瀏覽器就用那個版本的，這也苦了前端同事和我們倆 PHP（主要是前端同事特別苦）。而且產品經理對于實現效果也不是很滿意。
后來，經過團隊的一致同意，決定采用谷歌瀏覽器內核，放棄了 IE 瀏覽器。于是客戶端使用了 CEF，用 Chromium&Webkit 來呈現 web 頁面。這個時期，客戶端的開發任務逐漸改為由一個C++ 同事（昵稱：小白）承擔，項目經理輔助。其間小白同學還掉 CEF 的坑里面了……恩，還是很苦的。之后很多新功能點的開發任務就向服務端傾斜，客戶端里面采用 web 頁面的功能也越來越多。但是，這樣的用戶體驗不是很好。連其他團隊的同事都說我們組不是在做客戶端，而是客戶端里面嵌瀏覽器，瀏覽器里面跑網頁。
再后來，領導說，web 版也得有。用戶說，你們為什么不開發 Mac 版（我們組連 Mac 都沒有，鬼來給你們開發 Mac 版啊）。于是，項目經理就把我們倆 PHP 叫到跟前，語重心長地說：“你們看，小白做客戶端也挺累的。我們現在當然也不可能開發 Mac 版，但是，Mac 版可能還是得有的，在不遠的將來。你們說能不能就用 web 的開發模式來實現客戶端啊？這樣 web 版、Window PC 版、Mac 版就都有了。你們看，有道云筆記、StarUML、釘釘這些就挺吊的。” 恩，我明白，其實我們需要做的東西是單頁應用。
調研和選型
有道、heX、AngularJS
于是，我們就開始了調研和選型的任務。既然說到了有道云筆記、StarUML、釘釘這幾款軟件，那么我們就從它們開始著手。
有道云筆記可能就是最貼近我們想法的產品，有客戶端，有 web 版。
有道自己有個項目叫 heX 。這是其官網的介紹：
heX 項目于 2012 年啟動，基于開源項目 CEF，它內部整合了開源項目 Chromium 及 Node.JS，將兩者的 V8 引擎和消息循環合并，從而達到了在 Chromium 所展現的 Web 頁面內可以直接使用 Node.JS 原生和及第三方擴展的 API 以及 Node.JS 最大的特色——異步回調與事件循環。heX 最初的目標是，采用純前端 （HTML，CSS，JavaScript） 的方式開發客戶端軟件，解決傳統桌面開發中大量繁瑣的 UI 工作。以實現跨平臺 (Windows，OS X，Linux)，高效的桌面程序開發。隨著持續的開發，heX 被賦予了更多的角色，它可以作為 web 容器嵌入到客戶端工程中，還可以作為瀏覽器 (HeXium) 對 Node.js 進行調試。
這篇博客 《heX：用HTML5和Node.JS開發桌面應用》 講述了 heX 的前世今生，貌似有道詞典是用 heX 開發的，但是有道云筆記是否使用了 Hex，文章和官網沒有提及。我粗略地對比了一下有道云筆記和有道詞典安裝后的目錄及文件，估計有道云筆記還是使用的 CEF。
而有道云筆記界面是使用的是： AngularJS。
StarUML2、nw、Kendo UI
StarUML2 是基于 NW.js（原名node-webkit） ，NW 是基于Chromium 和 node.js，利用 web 方式開發跨平臺桌面應用的平臺技術。
StarUML 上有很多很復雜的 UI 控件，這些控件是由 Kendo UI 提供。Kendo UI 是一款杰出的 Web UI 框架，貌似是收費的。Kendo UI 還提供了 AngularJS 的版本。
釘釘
看安裝后的目錄和文件，目測應該是基于 NW.js + AngularJS
Atom、Visual Studio Code、Electron
除了 CEF、heX、nw 之外，還有一個比較新的利用web技術構建跨平臺桌面軟件的平臺： Electron 。同樣，Electron 的底層也是基于Chromium 和 node.js。這個項目由 GitHub 發起和維護。最近特別火的兩款編輯器 Atom 和 Visual Studio Code 都是基于 Electron 開發的。
最后，小白同學決定還是使用 CEF。 原因很簡單：他在 CEF 的坑里面摸爬滾打過，熟悉。
平臺已經確定使用 CEF 了，但是單頁應用用什么技術好哩？上面一路看下來，其實我內心已經很偏向 AngularJS 了。
Angular、React、Vue、Avalon、Backbone
前端框架遍地開花，選得我眼花繚亂的。我最后綜合了：框架成熟度、社區活躍度、第三方組件數量、背后干爹、GitHub Star 數目、成熟案例、搜索引擎關鍵字熱度、百度指數、文檔和資料數目……等等一系列因素，艱難地決定使用 Angular（其實是我一拍腦袋決定的）。
當然，為了說服項目經理，我還是花了一個下午的時間邊看 Angular 文檔邊看產品經理的原型，寫了一個比原型還丑一百倍的 demo，只是產品的一個架子雛形。demo 丑得驚為天人，同事們可能也就在心中吐槽了一把，并沒有什么其他反應。當我把 JS 文件打開給同事們看時，里面只有幾十行代碼。如果是用 jQuery，實現同樣的功能代碼量肯定是多出很多的。于是，大家就一致同意使用 Angular 了。其實，在寫的過程中，我就對于 Angular 雙向數據綁定、幾乎無需操作 DOM 的特性給折服了。這大概是從 jQuery 風格突然跳出來時特有的激動吧。
前端框架也定了，后端就是提供 API 接口了。我本來是想用 Laravel +dingo/api 的，但是考慮到我們人少和工期都十分有限。另一名 PHP 同事建議直接將原有系統的代碼 copy 一份，將返回 html 視圖的頁面直接改為返回 json 數據。新增的接口繼續在原有系統上添加。這樣開發速度最快，大家欣然接受。
于是，我們巴拉巴拉地開始這個項目了。
產品經理產出原型->
設計師根據原型產出設計圖->
前端同事切圖，編寫HTML和CSS->
我負責寫大部分的 Angular 代碼和極少數的 PHP API 接口->
另外一名 PHP 同事寫少部分的 Angular 代碼和絕大數的 PHP API 接口->
C++ 同事附近寫客戶端相關的一些功能
沒圖我會亂說？
這是在客戶端中的效果：
這是在瀏覽器中的效果：
最后，總結下吧。
優點：
跨平臺：本質上還是網頁，所以跨平臺不必多說。移動端也有 inoic 這個方案。
前后端徹底分離：一般服務端的 MVC 架構，都會有視圖這個概論，返回給瀏覽器端的是 HTML。這就意味著，服務端程序員還是需要寫視圖，需要將前端給的頁面改成模板。但是，采用 Angular 這些前端框架，服務器就只需要提供接口，返回 json 數據。這樣，前端和后端就徹底分離開了。每次老板說要大改版時，服務端接口不用變，前端就是最苦的了。
純API接口：上面說過，服務端以往對于瀏覽器請求返回 HTML，對于移動端請求，一般是返回 json 數據。但是，如果使用前端框架都走 API 的形式，那么就真是大統一了。不管是 web 站點、Android 客戶端、iPhone 客戶端、window phone 客戶端，統統都只返回接口數據。
可測試性：API 接口降低了服務端單元測試的難度，而 Angular 本身也提供了測試套件，讓前端應用更加易于測試。（我并沒有實踐過，原因懂的）
缺點：
SEO：Angular 基本都是利用 ajax 異步獲取數據，這樣對于搜索引擎是不太友好的。但是，如果是工具類應用（例如：web 即時聊天室、網站管理后臺），重點并不是在內容上，就不用太顧忌這個缺點。
瀏覽器兼容性：做 web 的，瀏覽器兼容真是一個老大難的問題。Angular 在 1.3 后就減少了對 IE8 的支持了。
項目難度：如果用 Angular 做一般 web 項目，是非常容易的。但是，如果真的是要達到客戶端交互的體驗，這個肯定是有難度的。不過，這一點不是針對 Angular，而是說想用 web 技術實現客戶端交互體驗這件事本身是有難度的。
前端人才：Angular 本身還是有一定難度的，很多概念還是從服務端引入的，專注于前端開發的工程師可能難以適應。而要找到懂設計懂UI，邏輯抽象、編碼能力還很強的前端工程師確實是件比較困難的事情。