angular react

Angular 2 has reached Beta and appears poised to become the hot new framework of 2016. It’s time for a showdown. Let’s see how it stacks up against 2015’s darling: React.

Angular 2已达到Beta版本，并有望成为2016年炙手可热的新框架。该是对决的时候了。 让我们来看看它与2015年的宠儿： React的关系 。

Disclaimer: I enjoyed working in Angular 1 but switched to React in 2015. I’ve published Pluralsight courses on React and Flux and React and Redux in ES6 (free trial). So yes, I’m biased. But I’m attacking both sides.

免责声明：我喜欢在Angular 1中工作，但是在2015年改用React。我已经在ES6中发布了关于React和Flux以及React和Redux的 Pluralsight课程( 免费试用 )。 所以是的，我有偏见。 但是我在攻击双方。

Alright, let’s do this. There will be blood.

好吧，让我们这样做。 在那里将会有流血。

您正在比较苹果和猩猩！ (You’re Comparing Apples and Orangutans!)

Sigh. Yes, Angular is a framework, React is a library. Some say this difference makes comparing them illogical. Not at all!

叹。 是的，Angular是一个框架，React是一个库。 有人说，这种差异使得将它们进行比较是不合逻辑的。 一点也不！

Choosing between Angular and React is like choosing between buying an off-the-shelf computer and building your own with off-the-shelf parts.

在Angular和React之间进行选择就像在购买现成的计算机和使用现成的零件构建自己的计算机之间进行选择。

This post considers the merits of these two approaches. I compare React’s syntax and component model to Angular’s syntax and component model. This is like comparing an off-the-shelf computer’s CPU to a raw CPU. Apples to apples.

这篇文章考虑了这两种方法的优点。 我将React的语法和组件模型与Angular的语法和组件模型进行了比较。 这就像将现成计算机的CPU与原始CPU进行比较。 苹果到苹果。

Angular 2的优势 (Angular 2 Advantages)

Let’s start by considering Angular 2’s advantages over React.

让我们首先考虑Angular 2相对于React的优势。

低决策疲劳 (Low Decision Fatigue)

Since Angular is a framework, it provides significantly more opinions and functionality out of the box. With React, you typically pull a number of other libraries off the shelf to build a real app. You’ll likely want libraries for routing, enforcing unidirectional flows, web API calls, testing, dependency management, and so on. The number of decisions is pretty overwhelming. This is why React has so many starter kits (I’ve published two).

由于Angular是一个框架，因此它提供了开箱即用的更多意见和功能。 使用React，您通常可以从其他许多库中获得现成的应用程序。 您可能需要使用库来进行路由，执行单向流，Web API调用，测试，依赖管理等。 决定的数量非常庞大。 这就是为什么React有这么多入门工具包的原因(我已经发布了 两个 )。

Angular offers more opinions out of the box, which helps you get started more quickly without feeling intimidated by decisions. This enforced consistency also helps new hires feel at home more quickly and makes switching developers between teams more practical.

Angular提供了更多开箱即用的意见，可帮助您更快上手，而不会被决策吓到。 这种强制性的一致性还可以帮助新员工更快地感到宾至如归，并使在团队之间切换开发人员更加实用。

I admire how the Angular core team has embraced TypeScript, which leads to the next advantage…

我很佩服Angular核心团队如何接受TypeScript，这带来了下一个优势……

TypeScript =清除路径 (TypeScript = Clear Path)

Sure, TypeScript isn’t loved by all, but Angular 2’s opinionated take on which flavor of JavaScript to use is a big win. React examples across the web are frustratingly inconsistent — it’s presented in ES5 and ES6 in roughly equal numbers, and it currently offers three different ways to declare components. This creates confusion for newcomers. (Angular also embraces decorators instead of extends — many would consider this a plus as well).

当然，并不是所有人都喜欢TypeScript，但是Angular 2坚决认为使用哪种JavaScript风格是一个大赢家。 整个Web上的React示例都令人沮丧地不一致-它在ES5和ES6中以大致相等的数量显示，并且目前提供三种不同的方式来声明组件 。 这给新来者造成了困惑。 (Angular还接受装饰器而不是扩展器，许多人也认为这是一个加号)。

While Angular 2 doesn’t require TypeScript, the Angular core team certainly embraces it and defaults to using TypeScript in documentation. This means related examples and open source projects are more likely to feel familiar and consistent. Angular already provides clear examples that show how to utilize the TypeScript compiler. (though admittedly, not everyone is embracing TypeScript yet, but I suspect shortly after launch it’ll become the de facto standard). This consistency should help avoid the confusion and decision overload that comes with getting started with React.

虽然Angular 2不需要TypeScript，但Angular核心团队肯定会接受它，并且默认在文档中使用TypeScript。 这意味着相关示例和开源项目更容易感到熟悉和一致。 Angular已经提供了清晰的示例，展示了如何利用TypeScript编译器 。 (尽管可以肯定， 并不是每个人都在接受TypeScript ，但是我怀疑它在发布后不久就会成为事实上的标准)。 这种一致性应该有助于避免React入门带来的混乱和决策过载。

减少流失 (Reduced Churn)

2015 was the year of JavaScript fatigue. Although React itself is expected to be quite stable with version 15 coming soon, React’s ecosystem has churned at a rapid pace, particularly around the long list of Flux flavors and routing. So anything you write in React today may feel out of date or require breaking changes in the future if you lean on one of many related libraries.

2015年是JavaScript疲劳的一年。 尽管预计React本身将很快稳定在第15版中 ，但React的生态系统却在快速发展，尤其是在Flux口味和路线 列表中 。 因此，如果您依靠许多相关的库之一，那么您今天在React中编写的任何内容都可能会过时或需要在未来进行重大更改。

In contrast, Angular 2 is a careful, methodical reinvention of a mature, comprehensive framework. So Angular is less likely to churn in painful ways after release. And as a full framework, when you choose Angular, you can trust a single team to make careful decisions about the future. In React, it’s your responsibility to herd a bunch of disparate, fast-moving, open-source libraries into a comprehensive whole that plays well together. It’s time-consuming, frustrating, and a never-ending job.

相反，Angular 2是对成熟，全面框架的精心，有条不紊的重塑。 因此，释放后，Angular不太可能以痛苦的方式搅动。 作为一个完整的框架，当您选择Angular时，您可以信任一个团队就未来做出谨慎的决定。 在React中，您有责任将许多不同的，快速移动的开源库整合到一个可以很好地协同工作的综合库中。 这是耗时，令人沮丧且永无止境的工作。

广泛的工具支持 (Broad Tooling Support)

As you’ll see below, I consider React’s JSX a big win. However, you need to select tooling that supports JSX. React has become so popular that tooling support is rarely a problem today, but new tooling such as IDEs and linters are unlikely to support JSX on day one. Angular 2’s templates store markup in a string or in separate HTML files, so it doesn’t require special tooling support (though it appears tooling to intelligently parse Angular’s string templates is on the way).

正如您将在下面看到的，我认为React的JSX是一个巨大的胜利。 但是，您需要选择支持JSX的工具。 React已经变得如此流行，以至于工具支持在今天几乎不再是问题，但是诸如IDE和linters之类的新工具不太可能在第一天就支持JSX。 Angular 2的模板将标记存储在字符串中或单独HTML文件中，因此它不需要特殊的工具支持(尽管似乎正在智能地解析Angular的字符串模板的工具)。

Web组件友好 (Web Component Friendly)

Angular 2’s design embraces the web component’s standard. Sheesh, I’m embarrassed I forgot to mention this initially — I recently published a course on web components! In short, the components that you build in Angular 2 should be much easier to convert into plain, native web components than React’s components. Sure, browser support is still weak, but this could be a big win in the long-term.

Angular 2的设计包含Web组件的标准。 嘘，我很不好意思，我最初忘记提及这一点-我最近发布了有关Web组件的课程 ！ 简而言之，与React组件相比，在Angular 2中构建的组件应该更容易转换为普通的本机Web组件。 当然， 浏览器支持仍然很薄弱 ，但是从长远来看，这可能是一个巨大的胜利。

Angular’s approach comes with its own set of gotchas, which is a good segue for discussing React’s advantages…

Angular的方法带有它自己的陷阱，这是讨论React优势的好方法……

React优势 (React Advantages)

Alright, let’s consider what sets React apart.

好吧，让我们考虑一下React的不同之处。

JSX (JSX)

JSX is an HTML-like syntax that compiles down to JavaScript. Markup and code are composed in the same file. This means code completion gives you a hand as you type references to your component’s functions and variables. In contrast, Angular’s string-based templates come with the usual downsides: No code coloring in many editors, limited code completion support, and run-time failures. You’d normally expect poor error messaging as well, but the Angular team created their own HTML parser to fix that. (Bravo!)

JSX是一种类似于HTML的语法，可以编译为JavaScript。 标记和代码组成在同一文件中。 这意味着，在键入对组件的函数和变量的引用时，代码完成功能将为您提供帮助。 相比之下，Angular基于字符串的模板具有通常的缺点：许多编辑器中没有代码着色，有限的代码完成支持以及运行时失败。 通常，您也会期望错误的消息传递也很糟糕，但是Angular团队创建了自己HTML解析器来解决该问题 。 (好！)

If you don’t like Angular string-based templates, you can move the templates to a separate file, but then you’re back to what I call “the old days:” wiring the two files together in your head, with no code completion support or compile-time checking to assist. That doesn’t seem like a big deal until you’ve enjoyed life in React. Composing components in a single compile-time checked file is one of the big reasons JSX is so special.

如果您不喜欢基于Angular基于字符串的模板，则可以将模板移到一个单独的文件中，然后返回到我所说的“旧时光”：将两个文件连接在一起，无需任何代码完成支持或编译时检查以提供帮助。 直到您在React中享受生活，这似乎并不重要。 在单个编译时检查的文件中组成组件是JSX如此特别的主要原因之一。

For more on why JSX is such a big win, see JSX: The Other Side of the Coin.

有关为什么JSX如此大获胜的更多信息，请参见JSX：硬币的另一面 。

ReactSwift失败 (React Fails Fast and Explicitly)

When you make a typo in React’s JSX, it won’t compile. That’s a beautiful thing. It means you know immediately exactly which line has an error. It tells you immediately when you forget to close a tag or reference a property that doesn’t exist. In fact, the JSX compiler specifies the line number where the typo occurred. This behavior radically speeds development.

当您在React的JSX中输入错误时，它不会被编译。 那是一件美丽的事。 这意味着您可以立即准确地知道哪一行有错误。 当您忘记关闭标签或引用不存在的属性时，它会立即告诉您。 实际上， JSX编译器会 指定发生错字的行号 。 这种行为从根本上加快了发展速度。

In contrast, when you mistype a variable reference in Angular 2, nothing happens at all. Angular 2 fails quietly at run time instead of compile-time. It fails slowly. I load the app and wonder why my data isn’t displaying. Not fun.

相反，当您在Angular 2中错误键入变量引用时，则什么也没有发生。 Angular 2在运行时(而非编译时)安静地失败 。 它慢慢地失败了。 我加载了应用程序，想知道为什么我的数据没有显示。 不好玩。

React是以JavaScript为中心的 (React is JavaScript-Centric)

Here it is. This is the fundamental difference between React and Angular. Unfortunately, Angular 2 remains HTML-centric rather than JavaScript-centric. Angular 2 failed to solve its most fundamental design problem:

这里是。 这是React和Angular之间的根本区别。 不幸的是，Angular 2仍然以HTML为中心，而不是以JavaScript为中心 。 Angular 2无法解决其最基本的设计问题：

Angular 2 continues to put “JS” into HTML. React puts “HTML” into JS.

Angular 2继续将“ JS”放入HTML。 React将“ HTML”放入JS。

I can’t emphasize the impact of this schism enough. It fundamentally impacts the development experience. Angular’s HTML-centric design remains its greatest weakness. As I cover in “JSX: The Other Side of the Coin”, JavaScript is far more powerful than HTML. Thus, it’s more logical to enhance JavaScript to support markup than to enhance HTML to support logic. HTML and JavaScript need to be glued together somehow, and React’s JavaScript-centric approach is fundamentally superior to Angular, Ember, and Knockout’s HTML-centric approach.

我不能足够强调这种分裂的影响。 它从根本上影响了开发经验。 Angular的以HTML为中心的设计仍然是其最大的弱点。 正如我在“ JSX：硬币的另一面 ”中介绍的那样，JavaScript比HTML强大得多。 因此， 增强JavaScript以支持标记比增强HTML以支持逻辑更合乎逻辑 。 HTML和JavaScript需要以某种方式粘合在一起，React以JavaScript为中心的方法从根本上优于Angular，Ember和Knockout以HTML为中心的方法。

Here’s why…

这就是为什么...

React以JavaScript为中心的设计=简单 (React’s JavaScript-centric design = simplicity)

Angular 2 continues Angular 1’s approach of trying to make HTML more powerful. So you have to utilize Angular 2's unique syntax for simple tasks like looping and conditionals. For example, Angular 2 offers both one and two way binding via two syntaxes that are unfortunately quite different:

Angular 2延续了Angular 1的尝试使HTML更强大的方法。 因此，您必须将Angular 2的独特语法用于诸如循环和条件语句之类的简单任务。 例如，Angular 2通过两种语法提供的一种和两种方式绑定，这两种语法非常不同：

{{myVar}} //One-way binding
ngModel="myVar" //Two-way binding

In React, binding markup doesn’t change based on this decision (it’s handled elsewhere, as I’d argue it should be). In either case, it looks like this:

在React中，绑定标记不会根据此决定而改变(它在其他地方处理，正如我认为的那样)。 无论哪种情况，它都看起来像这样：

{myVar}

Angular 2 supports inline master templates using this syntax:

Angular 2支持使用以下语法的内联主模板：

<ul><li *ngFor="#hero of heroes">{{hero.name}}</li>
</ul>

The above snippet loops over an array of heroes. I have multiple concerns:

上面的代码片段遍历了一系列英雄。 我有多个担忧：

• Declaring a “master template” via a preceeding asterisk is cryptic.通过前面的星号声明“主模板”是很神秘的。
• The pound sign in front of hero declares a local template variable. This key concept looks like needless noise (if preferred, you can use `var`).hero前面的井号声明一个本地模板变量。 这个关键概念看起来像是不必要的噪音(如果需要的话，可以使用`var`)。
• The ngFor adds looping semantics to HTML via an Angular-specific attribute.ngFor通过特定于Angular的属性将循环语义添加到HTML。

Contrast Angular 2’s syntax above with React’s pure JS*: (admittedly the key property below is React-specific)

将以上Angular 2的语法与React的纯JS *进行对比：(当然，下面的关键属性是特定于React的)

<ul>{ heroes.map(hero =><li key={hero.id}>{hero.name}</li>)}
</ul>

Since JS supports looping natively, React’s JSX can simply leverage all the power of JS for such things and do much more with map, filter, etc.

由于JS本身支持循环，因此React的JSX可以简单地利用JS的所有功能来处理此类事情，并使用map，filter等来做更多的事情。

Just read the Angular 2 Cheat Sheet. That’s not HTML. That’s not JavaScript. It’s Angular.

只需阅读Angular 2备忘单 。 那不是HTML。 那不是JavaScript。 它是Angular 。

To read Angular: Learn a long list of Angular-specific syntax.

阅读Angular：学习一长串针对Angular的语法。

To read Angular: Learn a long list of Angular-specific syntax.

阅读Angular：学习一长串针对Angular的语法。

React is unique in its syntactic and conceptual simplicity. Consider iterating in today’s popular JS frameworks/libraries:

React在语法和概念上的简单性是独一无二的。 考虑在当今流行的JS框架/库中进行迭代：

Ember: {{# each}}
Angular 1: ng-repeat
Angular 2: ngFor
Knockout: data-bind=”foreach”
React: JUST USE JS. :)

All except React use framework specific replacements for something that is native and trivial in JavaScript: a loop. That’s the beauty of React. It embraces the power of JavaScript to handle markup, so no odd new syntax is required.

除React之外的所有工具都使用特定于框架的替代品来替换JavaScript中的本机和琐碎的东西： 一个loop 。 那就是React的美丽。 它包含了JavaScript处理标记的功能，因此不需要任何奇怪的新语法。

Angular 2’s syntactic oddities continue with click binding:

Angular 2的语法奇怪之处在于单击绑定：

(click)=”onSelect(hero)"

In contrast, React again uses plain ‘ol JavaScript:

相反，React再次使用普通的'ol JavaScript：

onClick={this.onSelect.bind(this, hero)}

And since React includes a synthetic event system (as does Angular 2), you don’t have to worry about the performance implications of declaring event handlers inline like this.

而且由于React包含一个综合事件系统(与Angular 2一样)，因此您不必担心像这样内联声明事件处理程序的性能影响。

Why fill your head with a framework’s unique syntax if you don’t have to? Why not simply embrace the power of JS?

如果不需要，为什么还要用框架的独特语法来解决呢？ 为什么不简单地使用JS的功能呢？

奢华的发展经验 (Luxurious Development Experience)

JSX’s code completion support, compile-time checks, and rich error messaging already create an excellent development experience that saves both typing and time. But combine all that with hot reloading with time travel and you have a rapid development experience like no other.

JSX的代码完成支持，编译时检查和丰富的错误消息传递已经创造了出色的开发经验，可以节省键入和时间。 但是，将所有这些与热重装以及时间旅行相结合，您将拥有无与伦比的快速开发经验。

尺寸问题 (Size Concerns)

Here’s the sizes of some popular frameworks and libraries, minified (source):

以下是一些流行的框架和库的大小，已最小化( 源 )：

Angular 2: 566k (766k with RxJS)Ember: 435kAngular 1: 143kReact + Redux: 139k

Angular 2： 566k(RxJS为766k) Ember： 435k Angular 1 ： 143k React + Redux： 139k

Edit: Sorry, I had incorrect numbers earlier that were for simple ToDoMVC apps instead of the raw frameworks. Also, the Angular 2 number is expected to drop for the final release. The sizes listed are for the framework, minified, in the browser (no gzip is factored in here).

编辑 ：对不起，我之前的数字不正确，用于简单的ToDoMVC应用程序而不是原始框架。 此外，预计最终版本的Angular 2编号也会减少。 列出的大小是针对浏览器中最小化的框架的(此处未包含gzip)。

To make a real comparison, I built Angular 2’s Tour of Heroes app in both Angular 2 and React (I used the new React Slingshot starter kit). The result?

为了进行真正的比较，我在Angular 2和React中都构建了Angular 2的Tour of Heroes应用程序(我使用了新的React Slingshot入门套件)。 结果？

Angular 2: 764k minifiedReact + Redux: 151k minified

Angular 2 ：最小764k React + Redux ：最小151k

So Angular 2 is currently over four times the size of a React + Redux app of comparable simplicity. (Again, Angular 2 is expected to lose some weight before the final release).

因此Angular 2的当前大小是可比简单的React + Redux应用程序的四倍 。 (同样，Angular 2有望在最终发布之前减轻一些重量)。

Now that said, I admit that concerns about the size of frameworks may be overblown:

话虽如此，我承认对框架大小的担忧可能被夸大了：

Large apps tend to have a minimum of several hundred kilobytes of code — often more — whether they’re built with a framework or not. Developers need abstractions to build complex software, and whether they come from a framework or are hand-written, they negatively impact the performance of apps.

大型应用程序通常至少具有数百KB的代码(通常更多)，无论它们是否使用框架构建。 开发人员需要抽象来构建复杂的软件，无论它们来自框架还是手写的，都对应用程序的性能产生负面影响。

Large apps tend to have a minimum of several hundred kilobytes of code — often more — whether they’re built with a framework or not. Developers need abstractions to build complex software, and whether they come from a framework or are hand-written, they negatively impact the performance of apps.

大型应用程序通常至少具有数百KB的代码(通常更多)，无论它们是否使用框架构建。 开发人员需要抽象来构建复杂的软件，无论它们来自框架还是手写的，都对应用程序的性能产生负面影响。

Even if you were to eliminate frameworks entirely, many apps would still have hundreds of kilobytes of JavaScript. — Tom Dale in JavaScript Frameworks and Mobile Performance

即使您要完全消除框架，许多应用程序仍将具有数百KBJavaScript。 — JavaScript框架和移动性能中的 Tom Dale

Tom is right. Frameworks like Angular and Ember are bigger because they offer many more features out of the box.

汤姆是对的。 像Angular和Ember这样的框架更大，因为它们提供了更多的现成功能。

However, my concern is this: many apps don’t need everything these large frameworks put in the box. In a world that’s increasingly embracing microservices, microapps, and single-responsibility packages, React gives you the power to “right-size” your application by carefully selecting only what is necessary. In a world with over 200,000 npm modules, that’s a powerful place to be.

但是，我担心的是：许多应用程序并不需要将这些大型框架放入盒子中。 在一个日益接受微服务，微应用程序和单一职责包的世界中 ， React提供了通过仔细选择所需内容来“调整大小”应用程序的功能 。 在拥有超过200,000 npm模块的世界中，这是一个强大的地方。

React拥抱Unix哲学 。 (React Embraces the Unix Philosophy.)

React is a library. It’s precisely the opposite philosophy of large, comprehensive frameworks like Angular and Ember. So when you select React, you’re free to choose modern best-of-breed libraries that solve your problem best. JavaScript moves fast, and React allows you to swap out small pieces of your application for better libraries instead of waiting around and hoping your framework will innovate.

React是一个库。 恰恰是与Angular和Ember这样的大型综合框架相反的哲学。 因此，当您选择React时，您可以自由选择最能解决问题的现代最佳库。 JavaScript快速发展，React允许您将应用程序的一小部分换成更好的库，而无需等待并期待您的框架进行创新。

Unix has stood the test of time. Here’s why:

Unix经受了时间的考验。 原因如下：

The philosophy of small, composable, single-purpose tools never goes out of style.

小型，可组合，单一用途工具的理念永不过时。

React is a focused, composable, single-purpose tool used by many of the largest websites in the world. That bodes well for its future (That said, Angular is used by many big names too).

React是世界上许多最大的网站使用的专注，可组合的单一用途工具。 这对它的未来来说是个好兆头(也就是说， 许多大公司也使用 Angular)。

摊牌摘要 (Showdown Summary)

Angular 2 is a huge improvement over version 1. The new component model is simpler to grasp than v1’s directives, it supports isomorphic/universal rendering, and it uses a virtual DOM offering 3–10x improvements in performance. These changes make Angular 2 very competitive with React. There’s no denying that its full-featured, opinionated nature offers some clear benefits by reducing “JavaScript fatigue”.

Angular 2是对版本1的巨大改进。新的组件模型比v1的指令更易于掌握，它支持同构/通用渲染，并且使用虚拟DOM可以将性能提高3-10倍。 这些更改使Angular 2与React竞争非常激烈。 不可否认的是，它功能齐全，自以为是的特性通过减少“ JavaScript疲劳”提供了一些明显的好处。

However, Angular 2’s size and syntax give me pause. Angular’s commitment to HTML-centric design makes it complex compared to React’s simpler JavaScript-centric model. In React, you don’t learn framework-specific HTML shims like ngWhatever. You spend your time writing plain ‘ol JavaScript. That’s the future I believe in.

但是，Angular 2的大小和语法让我停下来。 与React以JavaScript为中心的简单模型相比，Angular对以HTML为中心的设计的承诺使其变得复杂。 在React中，您不会学习诸如ngWhatever之类的特定于框架HTML填充。 您花时间编写普通的'ol JavaScript。 我相信那是未来。

Comments? Chime in on Reddit or Hacker News.

注释？ 订阅Reddit或Hacker News 。

Cory House is the author of “Building Applications with React and Flux”, “Clean Code: Writing Code for Humans” and multiple other courses on Pluralsight. He is a Software Architect at VinSolutions and trains software developers internationally on software practices like front-end development and clean coding. Cory is a Microsoft MVP, Telerik Developer Expert, and founder of outlierdeveloper.com.

Cory House是“ 使用React和Flux构建应用程序 ”，“ 纯净代码：为人类编写代码 ”以及其他有关Pluralsight的课程的作者。 他是VinSolutions的软件架构师，并就前端开发和干净编码等软件实践对国际软件开发人员进行培训 。 Cory是Microsoft MVP，Telerik开发专家和outlierdeveloper.com的创始人。

翻译自: https://www.freecodecamp.org/news/angular-2-versus-react-there-will-be-blood-66595faafd51/

angular react