知乎专栏使用 AngularJS 框架有什么经验心得
AngularJS 与 jQuery 等传统操作 DOM 的思想有所不同， 对于 jQuery 等，一般是先有完整 DOM 然后在这些 DOM 的基础上进行二次调教。
而 AngularJS 等框架则是 根据 数据模型 以及其对应的 DOM 模版，然后通过模版像搭积木那样组合页面。
显然的...
AngularJS 为什么成功了
AngularJS 与 JavaScript, 在我看来, 都属于 2014 年度最佳框架(语言).我们来详细谈谈它的优点与缺点.全栈 VS 简单有人说, AngularJS 太庞大了, 太复杂了, 根本就是发展方向错误. 实则不然, 相反, 我的观点是, 全栈解决方案远大于简单的方案.既然我对 Rails 很熟悉, 我来举一个 Ruby 界的例子: Rails vs Sinatra. 一个是复杂到 Web 整站解决方案, 既包括了后端, 还包括了前端, 连打包, 压缩, 布署都帮你做好了. 而另一个则是简单到极致, 几行代码就可以写一个 Web 服务. 然而, Sinatra 永远无法打败 Rails, 只能处于小众圈子. 因为只要项目一大, 他们就要重新造一遍 Rails 的轮子.这个时候, 大部分人需要的是全栈解决方案, 不是小而美的东西.那么, 显而易见, BackboneJS 与 ReactJS 从这个竞争中出局了.实际上, AngularJS 像 Rails 一样, 它内部的轮子是可自由替换的, 事实上, 全栈的背后也是以简单作为基础的.思想的背后EmberJS 是 AngularJS 强有力的对手, 有很多支持者, EmberJS 的核心实现也是从 Rails 学到了很多东西.但为什么大家依然选择了 AngularJS, 我以为真正核心的原因只有一点: 一个框架的哲学思想.貌似有点深奥, 实际上很简单: AngularJS 从一诞生, 就认定了一件事: 在 Web 世界里, 声明式语法要远远好于命令式语法. 从这一点, 就引出了 AngularJS 的主要特性:双向数据绑定永不操作 DOM而 EmberJS, 一开始就是 Rails 在前端的实现, 当然很多概念不适用, 并且有些特性又不够, 而现在, 也是补了许多该有的特性, 比如正在开发中的 HTMLBars, View 层无法理解 DOM( HandleBars 只能理解字符串 )是一个硬伤, 这让 AngularJS 优势太明显了: 哲学概念单一, 便于理解. 而 EmberJS, 更像一个后端的思想的框架, 有点水土不服.或者, 应该换个说法: AngularJS 就像官方想做的那样, 只是想扩展 HTML 语法, 而不得不造了一些概念. 而 EmberJS 则是为了实现而实现. 如果你深入使用, 自会明白我的意思.易于上手AngularJS 真的太容易上手了, 当你做过官网上的 Hello World 例子后, 你就会惊讶: 原来不会 JavaScript 也能写好 Web2.0.而 Ember 则一开始就教你理解各种概念, controller, action, template, router. 等一等, 我们需要一步步向上爬.但是, 没有银弹随着前端项目的复杂度上升, jQuery 这种命令式语法已经无法管束整个项目的高质量推进. 但 AngularJS 也不是银弹.我们俗话有讲: 进入一个世界, 往往会放弃另外的世界. 这放与 AngularJS 身上非常合适: 正是 AngularJS 想把它的哲学思想做到极致, 才会带来诸多新的问题:动态作用域问题依赖注入问题digest loop 双向绑定性能问题directives 不必要的复杂度这几点, 相信你只要是 AngularJS 深入使用过都会遇到类似问题.我们看中它的优点, 用它来开发极动感的 AngularJS 前端应用, 也须理解并避开它的缺点.1. 动态作用域由于 AngularJS 双向绑定的需要, 你必须给数据指派一个域( scope ), 就像 JavaScript 中的 function, 会将每个不同的域中的数据隔开开来. 但不同的是, JavaScript 或 Java 等拥有完整语言特性的语言, 它们的 scope 的行为是预定义的, 只有有限的几种. 而 scope 则不然, 你无法真正理解它, 就无法理解为什么在 ng-repeat 中修改绑定的值却对应 controller 中的值是无效的一样困惑不解. 但是, 好的是, 当你真正成为程序员时, 你就会豁然开朗.2. 依赖注入问题这个问题出现的原因也是由于 AngularJS 的哲学导致: 依赖概念要够简单. 开发者想了一个极取巧的方法: 利用参数的名字作为依赖注入的对象. 正是因为 JavaScript 的强大多变, 他们才能做的到.然而, 新手们总是发现, 坑来了: 为什么压缩后代码就不能用了? 高手们说: 我们专门做了个轮子, 避免你打包出错. 新手们: 好牛X...3. 双向绑定的性能问题双向绑定的目的是大大提高我们开发者的效率, 却因为当今浏览器引擎的缺陷( 无法真正理解事件影响范围 ), 而只能采用最笨拙的思路:只要有事件触发, 就全面执行一次所有的监听( watcher ), 如果监听中有新的值出现, 则再次执行所有的监听, 进行重新计算, 反复最多 10 次.这里就不解释原理了. 简而易见, 这里可能有性能问题.但经过测试, 只要绑定对象不超过 2000 次, 则每一次 loop 都不会超出 50 ms. 这个时间差对我们人眼是无感知的.但我认为, 比起这一点潜在的性能问题( 而且是可以轻松调优的, chrome 下有很好用的插件 ), 我们还是值得去学习应用 AngularJS 的.4. directives 不必要的复杂度这个问题是唯一一个从设计上欠考虑的模块了. directives 是一个好东西, 你可以用它来封装各种 HTML 操作, 然后把它们做成组件. 这个特性太酷了.本来, 一鼓做气, 就可以把 ReactJS 比下去, 可是, 由于设计缺失. 我们只能得到一个半成品:语法定义非常蛋疼scope 在其中非常绕, 难于理解parser, link 等对于普通开发人员暴露的东西太多, 而难于理解. 而问题是, 对于我们普通开发者而言, 这个 directives 特性是我们必修的.总结AngularJS 依然拥有不可比拟的优势, 占据前端开发框架之首也是理所当然. 但 AngularJS 第一代框架确实不够大气, 第二代框架又太超前, 我们也不得不像使用 JavaScript 那样坑的语言那样来使用 AngularJS 了. 因为, 我们确实找不到更满意的取代品了.更为可喜的是, AngularJS 的测试框架设计的极为出色, 这也让它能够不断快速迭代, 也让我们写的应用更为健壮.这也是我选择一个框架的原因之一.
关于angularjs去哪里可以学介绍详细一点
AngularJS的官方网站上给出了这个框架的基本使用方法，如：如何引入AugularJS，从而让你的web应用使用该框架如何添加控件，并对其进行数据绑定如何进行表单验证如何与服务器通信如何创建可重用的组件如何对组件进行本地化如何让应用可嵌入、可注入和可测试另外，网站上还给出了一系列教程，跟随这些内容，我们可以从深入浅出地逐渐对AngularJS的各种特性和用法有很好的了解，进而很好地开始使用这一框架。
但是，正如Brian Ford所说，官方文档中并没有告诉开发者，当应用逐渐增长，其中包含上万甚至几十万行代码的时候，应该如何组织和管理它，而他的blog正是对这些内容以及最佳实践的总结。
这篇blog特别关注的是大型应用程序，作者首先给出的建议是，尽量不要让应用变得太巨大。
而应该编写小型、功能专注的、模块化的部分，然后逐渐把它们组合起来，变得越来越大，从而构成你的应用。
接下来，Brian Ford首先讲述了如何组织应用的结构，然后对性能、测试、工具、服务器和构建过程做了简要的总结。
在应用的组织结构方面，Brian Ford针对各个方面给出如下建议：目录：建议在根目录中只放置index.html一个文件，然后根据需要创建scripts、styles、views等目录，在scripts目录下，首先会存放app.js文件，然后在之下又可以创建多个子目录，如：controllers、directives、filters、services、vendor等，在其中分门别类地存放不同的内容。
并且，随着你为应用创建更多内容，也许会增加更多子目录来存放各种文件。
文件：每个文件中应该只有一件事物，这件事物可能会是控件、指令、过滤器或者服务等等。
这会生成比较小但更专注的文件。
也有利于更好地进行测试。
模块：首先在app.js中定义和配置所有模块，如：angular.module('yourAppName', ['yourAppDep']);angular.module('yourAppDep');然后在模块中定义控件、服务等，如：angular.module('yourAppDep').controller('MyCtrl', function () { \\\/\\\/ ...});依赖关系：一般来说，服务、控件、指令等应该拥有尽可能少的依赖关系，这是非常好的软件开发实践，会有助于测试。
API应该分层。
控件尤其不能综合多种不同级别的抽象。
指令：对指令使用app专用的前缀，这有助于避免与第三方的组件重名。
例如下面的代码中就用“btla”作为前缀：angular.module('yourAppDep').directive('btlaControlPanel', function () { \\\/\\\/ ...});服务：你可以使用下面的方式声明服务：angular.module('yourAppDep').service('MyCtrl', function () { \\\/\\\/ ...});模型：AngularJS作为JavaScript框架，其独到之处就在于让你可以完全掌控模型层。
这是AngularJS的强大之处，因为应用程序的核心是你的数据，而各种应用之间的数据又有很大区别。
所以Brian Ford强烈建议要仔细考虑使用和中数据，以及将会如何存储数据。
控制器：建议控制器以“Ctrl”开头，如：angular.module('yourAppDep').controller('MyCtrl', function () { \\\/\\\/ ...});除了上述内容，Brian Ford还在文章中针对性能、测试等方面给出了各种建议：在性能方面，AngularJS应用一般会非常非常快。
大多数应用不需要做任何特殊的优化，因此，除非你发现严重的性能问题，否则就应该把时间花在其他方面来改善应用。
对于大型项目来说，测试非常重要。
它让你可以自信地进行重构，而这对于保持大型项目代码整洁非常重要。
大型应用应该既拥有单元测试，也要拥有端到端（end-to-end）测试。
单元测试有助于定位问题，而端到端的测试能够确保整个应用像期望的那样工作。
每个控制器、服务、过滤器和指令都应该拥有一系列单元测试。
而应用的每个特性都应该拥有端到端的测试。
在工具方面，首先推荐使用Yeoman，从而获得最佳实践和很好的项目结构，另外还有AngularJS Batarang，它对于调试和找到性能瓶颈会很有效。
在服务器方面，你可以使用任何想要的服务器和AngularJS协作。
它只是客户端的程序库。
我的推荐和喜欢的设置是使用Node.js加nginx。
我使用nginx存放静态文件，使用Node.js创建RESTful的API和嵌入的（socketed）应用。
对于云提供商，我曾经成功使用过Nodejitsu 和Linode。
前者会让你更容易地部署程序，你不需要关心服务器的环境。
如果你需要对服务器环境有更多控制，那么Linode会让你从底层控制虚拟机。
Linode还提供了很好的API，可以用来管理虚拟机。
构建过程方面，我认为Angular还需要做更多改进，我在2013年最大的目标就是要对此有所贡献。
我已经发布了ngmin，希望这个工具可以最终解决为生产环境最小化AngularJS应用的问题。
……最后，Brian Ford做出结论：AngularJS是一种非常适合编写大型应用的JS框架。
你可以直接拿来使用，它很快，并且会对组织应用的结构很有帮助。
为什么我的AngularJS路线不问题，怎么解决
jQuery是dom驱动，AngularJS是数据驱动，这里有一篇文章阐述的非常好，建议看看本文来自StackOverFlow上How do I “think in AngularJS” if I have a jQuery background?一题中得票最高的回答。
该回答得票超过3000次，回答者Josh David Miller是活跃于开源社区的开发者，也是Emergenesis公司的联合创始人。
该答案最初由数云架构师韩铮翻译并发布在自己的博客上，在征得Josh同意后由韩铮本人推荐给 InfoQ进行分享，并在经过InfoQ社区编辑崔康审校后发布在此。
1. 不要先设计页面，然后再使用DOM操作来改变它的展现在jQuery中，你通常会设计一个页面，然后再给它动态效果。
这是因为jQuery的设计就是为了扩充DOM并在这个简单的前提下疯狂的生长的。
但是在AngularJS里，必须从头开始就在头脑中思考架构。
必须从你想要完成的功能开始，然后设计应用程序，最后来设计视图，而非“我有这么一个DOM片段，我想让他可以实现XXX效果”。
2. 不要用AngularJS来加强jQuery类似的，不要以这样的思维开始：用jQuery来做X，Y和Z，然后只需要把AngularJS的models和controllers加在这上面。
这在刚开始的时候显得非常诱人，这也是为什么我总是建议AngularJS的新手完全不使用jQuery，至少不要在习惯使用“Angular Way”开发之前这么做。
我在邮件列表里看到很多开发者使用150或200行代码的jQuery插件创造出这些复杂的解决方案，然后使用一堆callback函数以及$apply把它粘合到AngularJS里，看起来复杂难懂；但是他们最终还是把它搞定了
问题是在大多数情况下这些jQuery插件可以使用很少的AngularJS代码重写，而且所有的一切都很简单直接容易理解。
这里的底线是：当你选择解决方案时，首先“think in AngularJS”；如果想不出一个解决方案，去社区求助；如果还是没有简单的解决方案，再考虑使用jQuery。
但是不要让jQuery成为你的拐杖，导致你永远无法真正掌握AngularJS。
3. 总是以架构的角度思考首先要知道Single-page应用是应用，不是网页。
所以我们除了像一个客户端开发者般思考外，还需要像一个服务器端开发者一样思考。
我们必须考虑如何把我们的应用分割成独立的，可扩展且可测试的组件。
那么如何做到呢
如何“think in AngularJS”
这里有一些基本原则，对比jQuery。
视图是“Official Record”在jQuery里，我们编程改变视图。
我们会将一个下拉菜单定义为一个ul ：
- Home<\\\/a> <\\\/li>
- Menu 1<\\\/a>
- Submenu 1<\\\/a><\\\/li>
- Submenu 2<\\\/a><\\\/li>
- Submenu 3<\\\/a><\\\/li> <\\\/ul> <\\\/li>
- Menu 2<\\\/a> <\\\/li><\\\/ul>在jQuery里，我们会在应用逻辑里这样启用这个下拉菜单：$('.main-menu').dropdownMenu();当我们只关注视图，这里不会立即明显的体现出任何（业务）功能。
对于小型应用，这没什么不妥。
但是在规模较大的应用中，事情就会变得难以理解且难以维护。
而在AngularJS里，视图是基于视图的功能。
ul声明就会像这样：
- ... <\\\/ul>这两种方式做了同样的东西，但是在AngularJS的版本里任何人看到这个模版都可以知道将会发生什么事。
- Data Received!<\\\/li>'); } });对应的视图:
- <\\\/ul>除了要考虑多个方面，我们也会遇到前面视图中的问题。
- <\\\/li> <\\\/ul>但是其实还可以这样来做：
上一篇：ansys软件建模心得体会下一篇：android学习的心得体会
但是更重要的是，需要手动引用并更新一个DOM节点。
如果我们想要删除一个log条目，也需要针对DOM编码。
那么如何脱离DOM来测试这个逻辑
如果想要改变展现形式怎么办
这有一点凌乱琐碎。
但是在AngularJS里，可以这样来实现：$http('\\\/myEndpoint.json').then(function (response) { $scope.log.push({ msg: 'Data Received!' });});视图看起来是这个样子的：
- <\\\/li> <\\\/ul>但是其实还可以这样来做：
不论何时一个新成员加入开发团队，他看到这个就会知道有一个叫做dropdownMenu的directive作用在这个标签上；他不需要靠直觉去猜测代码的功能或者去看任何代码。
视图本身告诉我们会发生什么事。
清晰多了。
首次接触AngularJS的开发者通常会问这样一个问题：如何找到所有的某类元素然后给它们加上一个directive。
但当我们告诉他：别这么做时，他总会显得非常的惊愕。
而不这么做的原因是这是一种半jQuery半AngularJS的方式，这么做不好。
这里的问题在于开发者尝试在 AngularJS的环境里“do jQuery”。
这么做总会有一些问题。
视图是official record（译者注：作者可能想表达视图是一等公民）。
在一个directive外，绝不要改变DOM。
所有的directive都应用在试图上，意图非常清晰。
记住：不要设计，然后写标签。
你需要架构，然后设计。
数据绑定这是到现在为止最酷的AngularJS特性。
这个特性使得前面提到的很多DOM操作都显得不再需要。
AngularJS会自动更新视图，所以你自己不用这么做
在jQuery里，我们响应事件然后更新内容，就像这样：$.ajax({ url: '\\\/myEndpoint.json', success: function ( data, status ) { $('ul#log').append('
- Submenu 2<\\\/a><\\\/li>
- Menu 1<\\\/a>
