likes
comments
collection
share

[译文]为什么 Angular 比 React 更适合企业级应用程序

作者站长头像
站长
· 阅读数 20

概述

React 是一个非常好的库。它是第一个彻底改变 Web 开发的工具，并影响了其后出现的许多工具。但是 React 库有很多缺点，用它来开发大型企业应用程序并不是一个好的选择。在这篇文章中，我将讨论一些问题。这篇文章的目的不是将 React 的缺点归咎于它，而是解释了为什么 Angular 比 React 是开发大型企业应用程序的更好选择。

React 的演变和崛起

React 是 Facebook 为满足 Facebook 内部需求而开发的一个库，其唯一目的是将内容渲染到屏幕上并以干净的方式将您的数据连接到 DOM。而且 Facebook 不仅仅将 React 用于其完整的 UI 层。Facebook 仅将 React 用作其内部开发的自定义 PHP 版本的视图层。

  • 由于 Virtual DOM 的炒作和 React Native，许多初创公司采用了 React。许多初创公司希望重用相同的代码库来开发 Web 和移动应用程序，因为这对他们来说具有成本效益。
  • 在 React 的最初阶段，Google 发布了 Angular，这是与 AngularJS 完全不同的框架。许多公司认为从 AngularJS 迁移到 Angular 很困难。这有助于 React 抢占市场。
  • 由于 Angular 的初始版本发生了许多重大变化，许多初创公司、中小型公司认为 React 是未来，而 Angular 很快就会消亡（但事实恰恰相反）。
  • 因此，React 获得了高势头和用户群。
  • 在当前情况下，许多公司没有花时间为他们的应用程序确定合适的 UI 框架/库。他们只是落入了被高估的 React 炒作。
  • 由于采用率很高，许多开发人员开始学习 React。

让我们消除误解

也许有很多文章，比如 “Angular 和 React 之间的对比” 或 “为什么 React 更好” 等。这些文章中的大多数只是诱惑点击，没有足够的数据点。如果您关注他们，您可能会对 Angular 和 React 有一些看法。在讨论实际话题之前，我想澄清一下您是否有任何误解。

第一个误解：Angular 的学习曲线比 React 陡峭

传说 —— “Angular 的学习曲线很高，而 React 的学习曲线很低，开发人员需要时间来掌握。”

Angular v2 于 2016 年 9 月发布。从那时起，Angular 发布了许多重大变化，直到 2017 年。Angular 于 2017 年 11 月发布了 v5，并进行了很多修正和改进。由于在此期间发生了很多变化，许多开发人员/公司认为 Angular 的学习曲线陡峭，而 React 更容易。所以这个传说在 Angular v5 之前都是真的。

让我们检查一下当前的现实

[译文]为什么 Angular 比 React 更适合企业级应用程序

如果你的 JavaScript 知识足够好，上手 create-react-app 不会花太多时间。但是学习 React 的所有来龙去脉需要更长的时间，因为要开发 React 应用，你需要学习 props、states、Component 生命周期等等...... 而在Angular中，您还需要学习类似的概念，如模块、指令、管道、组件生命周期等...... 所以没有太大的区别。

但是使用 React 你需要学习非传统的 JSX，即使你在练习一段时间也会让你变慢。不仅如此，React 还不断引入新的东西，比如 React Suspense、React Hooks 等。另一方面，Angular 完全改变了一切。Angular CLI 使 Angular 开发速度更快，但create-react-app与 Angular CLI 相比显得乏力。从 v7 开始，Angular 对于每个新版本都变得更加标准化和简化。

但是，在处理现实生活中的应用程序时，您永远不会单独使用 React：Redux（或类似的）用于状态管理、Axios（或类似的）用于执行 HTTP 调用、Webpack（或类似的）来捆绑你的代码、一些用于路由和样式的第三方，这个列表还在继续。如果你想切换到不同的工具，你必须重新学习。

第二个误解：因为 Virtual DOM，React 比 Angular 更快

因为 Virtual DOM，React 比 Angular 更快 是 React 团队自己传播的一个误解。他们后来从 React 官方网页上删除了这句话。在下面的文章中，已经清楚地解释了为什么 Virtual DOM 并不快：

React 的问题

过多的依赖

React 只是一个视图层，但是为了构建一个项目，您需要实现路由，进行一些 HTTP 调用，您需要在 Redux 和 React 和 Redux 和路由器之间建立连接等。对于每种机制，您都必须安装第三方库，它们之间可能会或可能不会很好地相互配合或与 React 配合使用。在许多情况下，您将编写额外的代码以使它们能在一起良好工作。最后，您必须通过维护过多的依赖项来确保所有依赖项良好地协同工作。对于大型应用程序，这会消耗大量时间，并且会带来很大风险，不得不替换库和重写代码，而不是专注于我们的核心产品功能。

默认情况下，Angular 在其框架中提供了大部分常规功能。你只需要导入它，一切都很顺利。Angular CLI 将帮助您顺利升级 Angular 依赖项。

关注点分离

React 极大地普及了 JSX 的概念——在 JS 代码中具有类似 HTML 的标签。现在，JSX 已经被广泛采用，甚至在其他库中！许多 React 开发人员争辩说——“JSX 只是编码实践的问题，根本不是问题”。但现实情况是 JSX 还存在许多其他问题，例如：

  • 这里的一个大问题是代码重复的可能性非常高。你也不能这样做：内联样式中使用 :hover， :focus, :active ，你不能指定媒体查询，并且覆盖现有组件样式的唯一方法是使用 !important 。如果过于频繁使用可能会很糟糕。因此，您最终会遇到一些乏味的解决方法或使用一些第三方库来管理样式。
  • 尝试从组件模板中调用方法往往会导致无法访问 this ，导致您必须手动绑定它们。
  • 如果你在你的应用程序中编写了很多条件语句，那么 JSX 方式就很糟糕。这种编写循环的方式将是一场噩梦。
  • linter（如 ESlint）和代码分析工具（如 SonarQube）通常不足以防止最恶劣的编码实践。

真正的响应式？

响应式框架的想法是一个组件可以响应应用程序中另一个组件的状态更新，而无需轮询更新。

在 React 中只有两种流行的方式在整个应用程序中传播状态。他们是：

  • 父子层次结构
  • Redux

无需解释为什么在父子层次结构中导航会很痛苦。Redux 是一个巨大的全局键值存储，它比父子层次结构更好，但非常有限。它实际上是一个美化的全局对象。它的性能对于平面数据来说还可以，但是一旦你有了几层层次结构，它就会开始崩溃。

在真正的响应式应用程序中，任何组件的状态都是通用的、直接的、独立的，可供任何其他组件订阅。它们更节省内存，提供更好的性能，并且更容易开发和组织。对开发人员来说最重要的是，无需过多设置即可轻松从任何地方更新任何组件的状态。

然而，React 可以通过 rxjs 实现真正的响应式。还有其他解决方案，但为什么 React 不是开箱即用的响应式？

自 2015 年以来，Angular 一直使用带有 rxjs 的现代响应式模式作为官方文档的一部分。即使是最初的 AngularJS（从 2009 年开始）也比现代 React 更易于使用开箱即用的响应式模式。

React 没有标准的数据层

React 没有标准的数据层。如果你使用 Redux，Redux 遵循 Flux 架构。您的应用程序中将有数百/数千/百万个通量实现，它们的执行方式都略有不同。对于 Flux，数据层的工作方式尚不清楚。由于多个团队都在努力，一致性总是一个折腾。为了使其保持一致，您需要付出的努力程度高于 Angular。当您将新开发人员加入您的团队时，他们可能不得不努力理解数据流。而 Angular 不会遇到这个问题。

其他问题

  • React 的另一个最糟糕的部分是它没有解决组件样式。这是一个视图库，看在上帝的份上！为什么我必须进行研究并探索数以千计不同的 React 附加组件，这些附加组件声称已经“解决”了样式的“问题”——有什么要解决的？！只写一些该死的样式！
  • React Hooks 让情况变得更糟。现在它过于严格，甚至不允许 TypeScript 工作。对于任何在 Angular 中不费吹灰之力的普通操作，您都必须跳过额外的循环，想出非常奇怪的技巧，并浪费数天时间寻找解决方案。例如，您不能将组件扩展为 TypeScript 类，因为它们甚至不再是类。进化的一大步。
  • 时间估计非常容易，因为实现一个功能不需要比开发人员估计更多的东西，这会导致少量可能的混淆、错误或疏忽。需要理解的少量概念使与项目经理的沟通更加容易。

Angular 相对于 React 的优势

Angular + Web 组件

Angular + Web Components 的好处是它们可以通过属性和事件以相同的方式进行通信。您可以像任何其他 Angular 组件一样在 Web 组件上使用绑定语法。这意味着您可以在两者之间来回传递任何复杂的数据结构。这将允许 Angular 在 Web 组件保持无状态/可重用的同时管理状态/数据。

延迟加载和预加载

如果您想在应用程序中进行延迟加载或预加载，使用 Angular 非常简单。使用 Angular，您无需像使用 React 那样创建机制，只需添加简单的配置。

更多补充

  1. 零配置，无需关心任何 Webpack 配置。
  2. 由官方提供基础设施库（cli、http、router、animation、ssr、e2e 等），且保证兼容升级。
  3. 内置 RxJS，从 View 的操作到 Http 全部都是响应式的，可以随意组合。
  4. 版本升级只要运行一行命令就会自动迁移到新版本，并修复所有的可能的不兼容问题。

结论

在开发企业应用程序时，一致性、可扩展性、可升级性和可维护性是重中之重。React 不好，因为它不是帮助开发人员编写解耦、易于扩展和维护的代码，而是通过其 props 和状态共享机制耦合组件。

编写 React 代码就是整天处理变通方法（参见“代码清晰性”部分），努力编写真正有意义的代码，最终破解它并产生一个非常不清楚的解决方案。几个月后，当您再次阅读该解决方案时，您将很难阅读该解决方案。你会更加努力地发布你的项目，它会很难维护，有错误，需要大量的培训才能修改。React 受到其支离破碎的生态系统和以代码复杂性为代价致力于性能改进的阻碍。对于大型应用程序，这会带来太多的风险，即不得不交换库和重写代码，而不是专注于我们的核心产品功能。

Angular 非常标准化，CLI 消除了您必须做的大量样板工作，并且 CLI 在创建组件或升级依赖项时提供了很大的安全性。Angular 是标准化和简化前端开发工作的更好选择。

参考

本文翻译自 medium.com/@kanth.vall…