本文翻译自国外网站，老外罗里吧嗦的讲了一堆，关键就10点理由，概括为一点：Angular是很好的工具包，值得你好好学习。^_^

原文地址：

https://www.codeproject.com/Articles/718046/Reasons-Web-Developers-Should-Learn-Angular

作者：Jeremy Likness, 25 Apr 2018

翻译：崔传新 （估计是本头条号第一个翻译的）

有兴趣的可以看一看引文版。

下面就看看所谓的10大理由吧……

0-引言

毫无疑问，AngularJS--自称为"超级英雄JavaScript框架" - 正在增强吸引力。 我会在这篇文章中经常将它称为"Angular"。 我有幸在一个大型团队（近10位开发人员，很快增长到20位以上）使用Angular的企业Web应用程序上工作超过半年。 更有意思的是，我们在开始使用纯JavaScript和KnockoutJS的更传统的MVC/SPA方法之后，开始使用TypeScript和Angular的功能组合。 需要注意的是，我们使用Jasmine添加了全面的测试，但整体而言，团队认同这些技术组合提高了我们的质量和效率：我们看到的bug更少，功能更快。

如果你熟悉Angular，这篇文章可能会给你一些想法，想想你以前没有遇到过。 如果您了解Angular并试图证明您在公司或您的项目中采用Angular的理由，本文可为您提供一些可能有所帮助的背景信息。 如果您不知道Angular是什么，请继续阅读，因为我将分享为什么它如此强大，然后将您的资源指向可快速提高速度的资源。

我只能假设其他组织在采用Angular之后会看到积极的结果。 根据谷歌趋势，与KnockoutJS（红色）和"单页应用程序"（黄色）相比，AngularJS（蓝色）的普及正在爆炸式增长。

首批单轨AngularJS大会之一ng-conf在短短几分钟内售罄了数百张门票。 参加会议时，我了解到Angular正在用于各种基于网络的应用程序，包括Google自己的Doubleclick Campaign Manager（DCM）等大量企业Web应用程序。

本文不打算打击KnockoutJS或Ember或Backbone或任何其他您可能已经使用且熟悉的流行框架。 相反，我想重点关注为什么我相信Angular如此迅速地获得如此巨大的发展势头，并且任何从事Web应用程序工作的人都应该非常认真地对待，并且至少要更多地了解如何将它放入您的应用程序工具箱中。

1-Angular数据绑定

（它为XAML开发人员提供了一个可选之地。）我让这个子弹有点"喋喋不休"，因为大多数使用Angular的开发人员可能没有用10英尺的杆来触及XAML。 没关系，XAML通过WPF，Silverlight和Windows Store应用程序开发，是其在微软世界流行的原因非常重要，因为它们非常适合Angular。 如果您不熟悉XAML，那么它是一种基于XML的声明性语言，用于实例化对象图和设置值。 您可以使用属性定义各种类型的对象，并从字面上标记将创建的集合。 要创建的最常见类型的对象是用户界面元素，例如创建显示的面板和控件。 XAML可以轻松布置可能随时间而改变的复杂UI。 XAML支持继承（属性定义为父级的孩子可以选择树中较高的值）并冒泡类似于HTML DOM的事件。

XAML的另一个有趣的组件是对数据绑定的支持。 这允许表示层和数据之间存在已声明的关系，而不会在组件之间创建硬依赖关系。 XAML层理解有一个契约 - 即"我期望一个名称将被发布"，而命令性代码仅仅暴露一个属性而不知道它将如何呈现。 这可以实现任意数量的测试场景，从而将UI从底层逻辑中分离出来，从而使您的设计在无需重构大量代码的情况下变得更加灵活，并且实现设计人员和开发人员之间的真正并行工作流程。

这可能听起来像口水般的服务，但我已经参与了很多项目，并已看到它在行动。 我记得两个具体的例子。 一个是与微软合作的项目，我们不得不在大约4个月内完成。 我们估计一个长达4个月的动手开发和一个单独的设计团队需要大约4个月的设计才能完成所有的工作 - 他们从线框到互补模型以及运动研究和其他让我感谢的术语 -当我专注于代码时，我可以让设计人员做到这一点。 当然，如果我们遵循传统的顺序方法，我们会错过最后期限并等待8个月（设计4个月，然后是4个月的编码）。 XAML允许我们并行工作，通过同意屏幕界面 - "这些是我们将要公开的内容。"开发人员致力于获取数据以使这些属性可用并编写所有测试，并且 设计师们将这些元素进行了操控，动画化，并将它们移动到了所需的设计中，最后它们都出色地汇合在了一起。

另一个现实的例子是一个电缆公司的试点项目。 我们正在构建基于Silverlight的交互式指南的版本。 可唯一的问题是他们还没有准备好API。 我们能够根据映射用户体验内容的域模型（列表，时间等）设计系统，然后在API定义好和可用后，用API填充这些域对象。 同样，它启用了并行工作流程，极大地提高了我们的效率和设计的灵活性。

2-Angular摆脱陈规和仪式

你有否想在一个模型上创建一个文本属性绑定到你的UI的模型上？ 这在各种框架中如何完成的？ 在Angular中，这将毫无问题地生效，并立即反映在你的span内：

{{synchronizeThis}}

当然，你很少有构建一个简单的应用程序的欲望，但它说明了在Angular世界中，数据绑定是多么容易和简单。 参与数据绑定的模型涉及很少的陈规或仪式。 您不必从现有对象派生或显式声明您的属性和依赖关系 - 大部分情况下，您只需将您已拥有的某些内容传递给Angular即可使用。 这非常强大。 如果您好奇它是如何工作的，Angular会使用脏跟踪。

虽然我知道其他一些框架已经越来越好了，但是离开我们现有的框架，我们必须明确地将所有内容映射到临时对象，以便将数据绑定到Angular，就像一股清新的空气......事情刚刚开始更加融洽-很快，我觉得我正在复制较少的代码（谁想要定义一个联系人表，然后是服务器上的联系人域对象，然后联系人JSON对象，然后必须传递给联系人客户端模型——显示关于联系人的详细信息？）

意思为绑定省略了很多模式化冗余代码或步骤。

3-Angular依赖注入

依赖注入是Angular做得很好的事情。 我承认我对此持怀疑态度，甚至在客户端需要类似的东西，但我习惯于关键场景是模块的动态加载。 哦，等等 - 你说什么？ 没错，像RequireJS这样的图书馆，你可以在需要时动态加载JavaScript。 但是依赖注入真正发挥有两种情况：测试和单页应用程序（SPA）。

为了进行测试，Angular允许您将应用程序划分为逻辑模块，它们可以彼此依赖，但是分别进行初始化。 这让你只需引入你感兴趣的模块就可以对你的测试采取非常有策略的方法。然后，因为依赖关系被注入，你可以使用Angular的$http服务等现有服务，并使用$httpBackend mock替换它来测试。 这使得真正的单元测试不依赖于服务，或者浏览器UI来呈现，同时也拥有创建端到端测试的能力。

SPA（单页应用程序）使用从基于Web的app中动态加载呈现出地道的"本地应用"的感觉。 人们喜欢大声说SPA的缩写，因为它是新的东西，但我们一直在构建Atlas和Ajax时代的那些风格应用程序。 很讽刺的是，尽管事实上很少有XML涉及，但因为它全部是JSON，所以现在认为Ajax是真正推动SPA的东西。 你会发现这些应用可以快速增长，并且对各种服务和模块有很多依赖。 Angular可以很容易地组织这些并根据需要抓取它们，而不用担心诸如"它生活在什么名称空间中？"或"我已经创建了一个实例？"而只是告诉Angular您需要什么，Angular会如何 并为您获取它并为您管理对象的生命周期（例如，您不会使用获取该联系信息的同一简单服务的100个副本运行）。

使用DI连接相关服务的示例：

var $$jsInject = new WintellectJs.$$jsInject();

$$jsInject.register("car", [Car]); // annotating deps at registration

$$jsInject.register("tires", ["engine", Tires]);

$$jsInject.register("engine", ["gas", Engine]);

$$jsInject.register("gas", [Gas]);

Car.$$deps = ["engine", "tires"]; // annotating deps on class

var car = $$jsInject.get("car");

console.log(car.drive());

要真正理解依赖注入的工作方式，请看看我创建的简单$$jsInject解决方案(https://github.com/jeremylikness/jsinject)。 它使用类似于Angular的语法，但将它全部提炼成100行以下的代码。 你可以在这里(http://jsfiddle.net/jeremylikness/tKHmT/)为它运行相关的测试。

4-Angular允许开发人员以声明方式表示UI以减少副作用

声明式用户界面有很多优点。 我在本文前面讨论过XAML时提到过几个，但HTML是同一条船。 拥有结构化的用户界面使其更易于理解和操作。 不一定是程序员的设计师可以比编程更容易学习标记。 如使用jQuery，您最终必须了解很多关于文档结构的知识。 这产生了两个问题：首先，结果是很多不稳定的代码作为"粘合剂"工作，与UI中的变化紧密结合;其次，仅就是UI将会做什么，从标记中看不到明显的"魔术" 。 换句话说，你可能会有很多行为和动画被"背后"联系起来，所以从表单标签中看不到任何验证或转换正在发生。

通过声明你的UI并直接在HTML中放置标记，你可以将表示逻辑放在一个地方并与命令逻辑分开。 一旦你理解了Angular提供的扩展标记，像上面那样的代码片段，就明确了数据绑定的位置以及绑定的内容。 添加诸如指令和过滤器之类的工具使得它更加清楚UI的意图是什么，以及信息如何被塑造，因为塑形是在标记中完成的，而不是在一些孤立的代码中完成的。

保持大型系统 - 无论是大型软件项目还是大型团队的中型项目 - 都是减少副作用。 副作用是当你改变什么时，导致意想不到的甚至是灾难性的结果。 如果你的jQuery依赖于一个id来锁定一个元素并且一个设计者改变它，你会失去这种绑定。 如果您明确填充下拉菜单中的选项，并且设计人员（或客户或您）决定切换到第三方组件，则代码会中断。 声明式用户界面通过在源代码处声明绑定来消除这些副作用，消除了将行为粘贴到用户界面的隐藏代码的需要，并允许数据绑定与依赖关系（即"列表"）与 表现（即，下拉框与选择列表）解耦。

5-Angular拥抱测试驱动开发

无论您采用测试驱动开发、行为驱动开发还是任何驱动开发方法，Angular都支持这种构建应用程序的方法。 我不想用这篇文章来探讨你应该采用测试开发方式的所有优点和原因（我真的很惊讶，在2013年，人们仍然质疑价值），但我最近采取了更多的传统" 测试第一"的方法，这是有帮助的。 我相信在我们的项目中，Jasmine的引入以及我们所包含的测试都有助于将缺陷减少高达4倍。 也许更少（或可能更多），但下降显著。 这不仅仅是因为Angular——它是需求、好的接受标准、理解如何正确编写测试、以及让框架运行它们的组合——但它确实更容易构建这些测试。

这是一个测试示例，显示Angular视图模型或"范围"的继承：

it("overrides from the parent", inject(function ($rootScope) {

 var scope = $rootScope.$new();

 var childScope = scope.$new();

 scope.a = 1;

 scope.b = 2;

 childScope.b = 3;

 expect(scope.$eval('a+b')).toBe(3);

 expect(childScope.$eval('a+b')).toBe(4);

}));  

如果你想看这像什么，看看我的6502模拟器，然后浏览源代码。 除了一些最初的管道外，该应用程序是用纯粹的测试优先方法编写的。 这意味着当我想添加一个操作代码时，我会为操作代码编写测试，然后围绕它并实现之。 当我想要扩展编译器时，我编写了一个测试，以验证编译失败的结果，然后重构编译器以确保测试通过。 这种方法为我节省了时间，并且既改变了我对应用程序的结构和思考方式，也为文档创建了文档 - 您可以自己查看规范并理解代码应该执行的操作。 模拟依赖并将它们注入到Angular中的能力非常重要，正如您从示例中所看到的，您可以测试从UI行为到业务逻辑的所有内容。

6-Angular支持大规模并行开发

我们在项目早期遇到的最大问题之一是开发人员踩在彼此的脚趾上。 其中一部分只是一门学科，即使使用原始JavaScript，您也可以遵循使其更加模块化的模式，但Angular将它提升到另一个级别。 这并不是说它完全消除了依赖性，但它确实使它们更易于管理。 作为一个具体的例子，应用程序中有一个巨大的网格用于驱动几个关键操作。 在一个传统的JavaScript应用程序中，在一个庞大的团队中进行扩展，这可能是一个合并的恶梦。 然而，通过Angular，将各种操作分解成自己的服务和子控制器非常简单，开发人员可以独立地测试和编写代码，而不会像往常一样崩溃。

很显然，对于大型项目来说，这是关键。 从它如何在客户端实现某些功能的角度来看，这不仅仅是关于技术，而实际上它是如何实现工作流程和处理过程，以便能够扩展团队。

7-Angular支持设计到开发双向工作流机制(Designer Developer)

好的，我在开玩笑吧？ 您可以通过HTML和CSS以及其他有趣的技术获得此信息。 然而，其得到自己的子弹的原因是因为它与Angular的协调工作的很好。 设计师可以添加标记而不会完全破坏应用程序，因为它依赖于某个ID或结构来定位元素并执行任务。 相反，重新安排部分代码就像移动元素一样简单，并且绑定和过滤的相应代码也随之移动。 尽管我还没有看到开发人员与UI / UX团队共享"设计合同"的灵敏环境，但我并不怀疑它离得很远 - 基本上这些团队就将要显示的元素达成一致意见， 然后将其展示出来，尽管他们希望在$scope中使用其控制器和其他逻辑进行开发连接，最后这两个部分才会结合在一起。 我们用XAML做到的，没有什么能够阻止你对Angular做同样的事情。

如果您是Microsoft开发人员并曾与Blend合作......看到了解Angular的IDE，并且可以提供用于设置绑定和设计时数据的UI，这不是很酷吗？ 这种能力在那里，它只是需要建立，随着所看到的人气，我不相信这会花费很长时间。

8. Angular提供控制模板（Directives"指令"）

我听说过有关转向MVC的最常见的抱怨之一是"我们对所有这些控件怎么处理？"早期认为控件不起作用/不会在非ASP.NET空间中运行，而是使用其他平台的web 开发人员知道情况并非如此。 有多种方法可以在Web上引入可重用代码，从jQuery插件的概念到像我最喜欢的KendoUI之类的第三方控件供应商。

Angular启用了一种称为"指令"(directive)的新方案，允许您创建新的HTML元素和属性。 在早期的T6502示例中，"data-ng-model"指令允许进行数据绑定。 在我的模拟器中，我使用一个指令来创建两个新标签：一个用于编写控制台消息的"控制台"标签和一个使用SVG为模拟器渲染像素的"显示"标签（如果您已经 检查出来，我意识到它更像一个模拟器）。 这为开发人员提供了控制 - 更重要的是控制了控件。

我一直在做的一个项目已经发展了几十个指令，他们都加入了以前的观点:

•指令是可测试的

•指令可以并行处理

•指令启用声明性方式来扩展UI，而不是使用代码来连接新的构造

•指令减少陈规和仪式

•指令参与依赖注入

请记住我是如何提到该项目的巨多网格的？ 我们碰巧使用了很多网格（几乎所有企业Web应用程序都是这样写的）。 我们使用KendoUI变体，并且您必须采取几个步骤来初始化网格。 就我们的目的而言，许多配置选项在网格中是一致的，那么为什么让开发人员输入所有的代码呢？ 相反，我们使他们能够删除一个新的元素（指令），用一些属性（指令）标记它们，并且它们已经启动并正在运行。

9. Angular帮助管理状态

我毫不犹豫地补充了这一点，因为精明和有经验的Web开发人员理解HTTP的概念以及如何管理其应用程序状态。 这是由ASP.NET延续的状态的"幻觉"，当开发人员转向MVC时，这会让开发人员感到困惑。 我曾经在一个颇受欢迎的论坛上看过一位自谓的架构设计师，其声明MVC是网页设计的劣质方法，因为他必须"建立自己的状态管理"。什么？ 这只是表明完全缺乏对网络工作原理的理解。 如果你依赖15K视图状态来让应用程序工作，那么你就错了。

我更多地指的是客户端状态，以及如何在浏览器中管理应用程序中的属性、权限和其他常见交叉问题。 Angular不仅处理依赖注入，还为您管理组件的生命周期。 这意味着你可以用完全不同的方式处理代码。 这里有一个简单的例子来解释我的意思:

应用程序的其中一部分涉及复杂的搜索。 这是一种传统模式：输入您的搜索条件，单击"搜索"并查看包含结果的网格，然后单击一行即可查看详细信息。 最初的实现包含两个页面：第一个是详细的标准页面，然后是一个带有窗格的网格页面，可从右侧滑入以显示当前选定行的详细信息。 在项目后期，这被重构为覆盖网格本身的搜索条件的对话框，然后是单独的全屏页面以获取细节。

在传统的Web应用程序中，这将涉及重写一些逻辑。 我可能会有一些调用会获取详细信息，并希望在同一页面上将它们传递给面板以获取详细信息，然后突然必须重构该信息以将详细信息ID传递到单独的页面并让该页面进行调用 等等。如果你已经为网络开发了无数时间，那么你必定经历一些重写，这些重写感觉他们对于移动东西有点多。 有多个"状态"要管理，包括显示详细记录的选择标准和标识符。

在Angular中，这是一件轻而易举的事情。 我为搜索对话框创建了一个控制器，为网格创建了一个控制器，并为详细信息页面创建了一个控制器。 一个父类控制器跟踪搜索标准和当前细节。 这意味着从一种方法切换到另一种方法，真的意味着只需重新组织标记。 我将细节移至新页面，将标准切换为对话框，并且我必须编写的唯一真实代码是在请求时调用对话框的新函数。 所有其他逻辑 - 获取和过滤数据并显示它 - 保持不变。 这是一个快速的重构。 这是因为我的控制器不关心页面是如何组织或流动的 - 他们仅仅关注获取信息并通过示波器展示信息。 该组织是一个关于路由的问题，我们使用Angular的路由机制来"重新路由"到新的方法，同时在UI之后保留相同的控制器和逻辑。 即使搜索标准的标记保持不变 ，它只是从整页的模板更改为在对话框中使用的模板。

当然，由于应用程序是混合单页应用程序（SPA），因此可能会进行此类重构。

10. Angular支持单页面应用

如果你错过了，这一点继续最后一个理由。 单页应用程序因为一个很好的理由而变得越来越流行。 它们满足了一个非常特殊的需求。 更多的功能正在被转移到网络上，浏览器最终意识到了它作为分布式计算节点的潜力。 通过设计，SPA应用程序反应更加敏捷（即使其中一些是感知）。 他们可以提供一种感觉就像在网络上的本地应用程序。 通过在客户端渲染，他们减少了服务器上的负载，并减少了网络流量 - 而不是发送整页标记，您可以发送数据负载并将其转化为客户端的标记。 当然，Angular并不强迫你构建SPA应用程序，它只提供大量内置支持。

根据我的经验，大型应用程序更适合构建混合SPA应用程序。 我的意思是，将整个应用程序视为一个单页面应用程序，将其划分为贯穿系统的逻辑工作单元或路径（"活动" ）。最终会导致整个页面刷新某些区域，但主要交互发生在一系列不同的SPA模块中。 例如，联系人可能是一个"迷你"SPA应用程序，而产品则是另一个。

结论

我经常听到Angular被称为框架。 尽管可以这样使用它，但我认为它更像是一个库和工具集。 它提供了诸如数据绑定之类的竞争库功能，还增加了依赖注入，输出过滤和通过指令的高级模板。 Angular的真正亮点在于允许您构建自己的模块，可重用的JavaScript，然后将其插入库中以与其他组件交互。 在最近的一次采访中，我将Angular描述为可以编织应用程序组件以提供最终体验的结构。 这很重要，因为它不会将您完全锁定到框架中，并且正如我自己的团队所经历的那样，可以轻松将现有应用程序迁移到使用Angular的应用程序。

閱讀更多 3T教育編程猿 的文章

關鍵字: XAML Google 罗里