从用 AngularJS 开发 PC 客户端说起

Mr_Jing

最近一个多月一直在用 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 发起和维护。最近特别火的两款编辑器 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,逻辑抽象、编码能力还很强的前端工程师确实是件比较困难的事情。

阅读 24.3k

4.4k 声望
210 粉丝
0 条评论
4.4k 声望
210 粉丝
文章目录
宣传栏