最近一个多月一直在用 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，逻辑抽象、编码能力还很强的前端工程师确实是件比较困难的事情。
