以前多少做过一点点前端，大概知道些JS，HTML，CSS的知识。最近技术选型又调研了下Angular——叹一句世界变化真快呢。
0. 思考
起先团队中有用到AngularJS，当时并不是太理解用它和velocity模板有什么不同，感觉也没有减少太多的工作量，而代码结构却更加复杂了。
本人前端小白，纯粹个人感觉，并非指AngularJS不好用。
1. 工具或者框架
我的概念大概还停留在JQuery，Ajax等阶段，因此第一次看到Angular这样的框架，觉得非常新奇，所以想从我的角度谈一下对“工具”或者“框架”的一些理解。
对JQuery等，应该算是工具，它们更多的是方便开发，提升开发便捷性，例如方便操作DOM、方便异步请求等。但框架一般都需要有一整套闭环的设计理念、开发规范和约定在里面，这也是我初看Angular能够深刻体会到的。
Angular对前端开发提出了一整套的解决方案，它脱离了传统后端的束缚，独立出来，成为了与后端平级的应用或模块，甚至可以称之为服务（可视化服务）。
2. 技术历史
虽我前端小白一枚，但断断续续也和前端打了四五年交道，说点历史吧。
在很久之前，前端是被限定在浏览器里的，而大多数前端工程师都挣扎在兼容各大浏览器的努力之中——样式+事件。
直到Ajax出现，让大家发现JavaScript并不仅仅可以用来做超酷炫的弹窗，其实可以做的更多。再之后开源浏览器引擎，Google Chrome和JavaScript V8的出现，终于JavaScript“成为”了一种脚本语言——其实一直都是。
NodeJS的横空出世，让我这个做后端的码农十分惊愕，当时还没有完全接受JavaScript作为脚本语言的事实——尴尬。
NodeJS受到热捧，最终确定了JavaScript的独立发展，而不再仅仅是前端语言。
3. 技术趋势
在我的印象中，随着互联网的发展，几乎所有框架都旨在解决工程性的问题，之后才是性能上的优化，如动静分离，更多是部署考虑，而不是开发时衡量。
以前端为例，这些年的发展方向也是在向应用化和工程化方向发展，其实想想这个是十分自然的。
前些年，大家努力在兼容各大浏览器（ＰＣ端），但近几年，随着移动互联网，ＨＴＭＬ５等的发展，前端工程师需要做到的则更多是在多终端、多分辨率下，对同一数据进行多样式、多布局的前端设计，这本身已经差不多是工程性的工作了。
引申： RESTFul
写到这里，想到后端技术栈也曾尝试过渗透到前端啊，只是没流行起来，如基于Java的Applet。
4. Angular初体验
按照其官网-CN的教程，写了一遍Heros的例子，大概理解了Angular的基本逻辑和框架。——对我这个太久不接触前端的人，简直是惊叹啊。
上面也有提到，Angular的设计理念，将前端提升到与后端平级的位置，成为“可视化服务”，是整个平台服务体系的一部分。
纯粹从开发的角度看，这将使之前基于Velocity之类的技术很尴尬，即需要面对二选一的抉择，我在最终决定技术选型时也纠结了很久。
相对于前端，后端的框架和封装，以及技术栈相对更成熟一些，所以在移动互联网发展这几年，后端相对来说还是老几样，没太多变化，而被最多提及的应该就是RESTful API吧。
RESTful API大行其道，其实就是为了应对前文提到的“多终端，多分辨率，多应用”等，我很喜欢的一个例子，就是天气预报API（暂不论是否是RESTful风格的），可以体会一下。
鉴于我只是走了一遍官方教程，所以就不写过多使用方面的内容，可移步官网查看，https://www.angular.cn/。
总结
本文从个人经历，大概说了下初探Angular这个陌生框架的一些感触和想法。因本人对前端了解有限，一些想法或表述会不准确，甚至是谬误的，所以建议大家亲自尝试一下，再做判断。
那么，对于我们团队最后的技术选型呢？
我们主要考虑以下几个问题：
- 后端是否已经ＡＰＩ化；
- 前端应用是否有多终端，多分辨率需求；
- 前后端分离，是否为开发需求；
- 团队技术储备情况;
