最近一個多月一直在用 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，邏輯抽象、編碼能力還很強的前端工程師確實是件比較困難的事情。