從用 AngularJS 開發 PC 客戶端提及

最近一個多月一直在用 AngularJS 作公司的一個項目(尚未作完),我以前主要是用 PHP 開發服務端的,AngularJS 也是現學現賣,整個過程仍是比較有意義的,以爲頗有必要寫篇文章記錄一下。html

緣起

事情是這樣的……咱們團隊的產品是一款 PC 客戶端,客戶端的界面主要是用 C++ 開發的,還有部分界面其實就是用 IE 瀏覽器內嵌了服務端的 web 頁面。在這個時期,項目經理帶着一個 C++ 同事寫界面(對的,咱們項目經理是寫代碼的老手),而後很苦……而對於 IE 瀏覽器,策略是用戶 PC 上是哪一個版本的 IE 瀏覽器就用那個版本的,這也苦了前端同事和咱們倆 PHP(主要是前端同事特別苦)。並且產品經理對於實現效果也不是很滿意。前端

後來,通過團隊的一致贊成,決定採用谷歌瀏覽器內核,放棄了 IE 瀏覽器。因而客戶端使用了 CEF,用 Chromium&Webkit 來呈現 web 頁面。這個時期,客戶端的開發任務逐漸改成由一個C++ 同事(暱稱:小白)承擔,項目經理輔助。其間小白同窗還掉 CEF 的坑裏面了……恩,仍是很苦的。以後不少新功能點的開發任務就向服務端傾斜,客戶端裏面採用 web 頁面的功能也愈來愈多。可是,這樣的用戶體驗不是很好。連其餘團隊的同事都說咱們組不是在作客戶端,而是客戶端裏面嵌瀏覽器,瀏覽器裏面跑網頁。node

再後來,領導說,web 版也得有。用戶說,大家爲何不開發 Mac 版(咱們組連 Mac 都沒有,鬼來給大家開發 Mac 版啊)。因而,項目經理就把咱們倆 PHP 叫到跟前,語重心長地說:「大家看,小白作客戶端也挺累的。咱們如今固然也不可能開發 Mac 版,可是,Mac 版可能仍是得有的,在不遠的未來。大家說能不能就用 web 的開發模式來實現客戶端啊?這樣 web 版、Window PC 版、Mac 版就都有了。大家看,有道雲筆記、StarUML、釘釘這些就挺吊的。」 恩,我明白,其實咱們須要作的東西是單頁應用。git

調研和選型

有道、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 進行調試。github

這篇博客《heX:用HTML5和Node.JS開發桌面應用》講述了 heX 的前世此生,貌似有道詞典是用 heX 開發的,可是有道雲筆記是否使用了 Hex,文章和官網沒有說起。我粗略地對比了一下有道雲筆記和有道詞典安裝後的目錄及文件,估計有道雲筆記仍是使用的 CEF。web

而有道雲筆記界面是使用的是: AngularJS。ajax

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 的版本。json

釘釘

看安裝後的目錄和文件,目測應該是基於 NW.js + AngularJS後端

Atom、Visual Studio Code、Electron

除了 CEF、heX、nw 以外,還有一個比較新的利用web技術構建跨平臺桌面軟件的平臺:Electron。一樣,Electron 的底層也是基於Chromium 和 node.js。這個項目由 GitHub 發起和維護。最近特別火的兩款編輯器 AtomVisual 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,邏輯抽象、編碼能力還很強的前端工程師確實是件比較困難的事情。

相關文章
相關標籤/搜索