從用 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。

StarUML二、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，邏輯抽象、編碼能力還很強的前端工程師確實是件比較困難的事情。