React过誉了吗？

React过誉了吗？抛开和Facebook的关系，它确实有“两把刷子“吗？

今年年初，我抱着诚恳的态度尝试了一下React。我自己以前是Angular用户，所以在尝试的过程中对这个库所展示的理念一直抱有开放的态度。

刚开始用React的感觉很奇怪——这个世界里的所有事物都要以一种特殊的方式来构造，其中需要用自动化处理程序来处理数据流。涉及到数据时，React总有自己的一套强制单向数据流机制。

但这些并不是我放弃React的原因——是社区中那些玻璃心的狂热信徒让我受不了的。也许是因为我的Angular用户背景，我会仔细观察，在两者间做出许多对比，结果引来了这帮人（他们大部分只会用React），气势汹汹地要找我较量。有那么几个月他们赢了，我撤退到了自己安全的Angular世界里。但是最近，我有机会在工作中用上了React Native，所以想写一写自己对这个话题的诚实看法。

这是一个库

React是一个库——而库必须与其他库搭配使用才能解决特定问题。React的问题解决能力主要体现在渲染前端界面和管理经常变化的数据上。

React的优势在于单向数据流，在面对突变和意外继承时可以确保高度稳定性和可预测性。React非常讨人喜欢的另一个因素是它处理关注点分离的方式。它颠覆了传统的筒仓（silo）方法，也就是将CSS、JavaScript和HTML分离成单独的文档文件，并将它们放在同一个空间中以备处理。

以Angular为例，传统的处理关注点分离的方式。

需要新事物时的处理方式。这种结构不是Angular特有的。

React中基于关系的关注点分离方式。

从理论上讲，在Angular中也可以实现基于关系的关注点分离，但不会像React中那样是默认方法，也没那么直观。

React之所以能实现这一目标，是因为其原则是代码组件都要维持在足够小的体积上，从而使这些组件的域和边界都易于检测和理解。但这不是硬性规定，组件的最终大小是由开发者确定的。

回归本源

React的流行主要是因为市面上缺少像样的起步架构，人们很需要这种架构来上手。React与Angular是不一样的，在Angular中需要用CLI来为框架生成必要的设置，而React需要的准备工作非常少。

但很多人在对比它们的时候都会犯一个错误。React是一个库，这意味着它体积很小，功能专一，且有针对性。但Angular是一个框架，这意味着它是符合同一套规则的一系列库的集合。因此，说Angular臃肿是不公平的，因为它俩并不是同一类事物。

框架决定了开发代码的方式，并充当所有关联库的协调者。它根据一组原则或规则确保所有部分均按预期工作。这是必要的，因为当你有多个库需要搭配使用时，为了让程序平稳运行，你需要有某种共同的基础。

React不是干这个的。

它从来都不是为这个目标设计的——因为它的唯一目的就是将事物渲染到屏幕上，并让你的数据以干净的方式连接到DOM。这就是为什么要将状态管理委派给Redux的原因。如果你想做的事情不只是处理数据和DOM，就需要找第三方应用程序来解决问题。

这也没错。这就是React的机制，这就是React的用途所在。

不能因为它易用，就说它更好

Angular与React的争论似乎持续了很长时间。但这本质上不是谁更好的问题，而是谁更适合你开发需求的问题。

我看到很多人最后都会拿出来的论点，就是说React是由Facebook创造的。但并不是所有事情上Facebook的出身都有那么大的意义。是的，它是由Facebook创造的，但React也不是他们唯一使用的技术。在他们的后端，也许还有前端，还有其他很多东西。

如果我们要谈出身，那么Angular与Google有关，Java来自Oracle，.Net还是Microsoft的心血呢。

需要承认，React比Angular更容易上手——特别是对于开发新手来说，他们对前端代码并没有清晰的认识。他们可能是自学成才的，或者可能是其他领域经验丰富的工程师转型过来的。不管用户是什么水平，React都像是JavaScript刚诞生时的样子——上手很简单，但是用法几乎没什么限制。

React作为一个库所面临的问题是没有结构上的约束——只有语法的约束。这可能导致应用结构松散，缺乏命名约定，文件夹结构（如果有这种东西）随意混乱，生产部署中还可能打包进去很多冗余文件。

从理论上讲，如果你不遵守那些最佳的编程方式，那么做出来的任何事物都可能落得这样的下场。可是这些最佳方法并没有在代码中通过约束固定下来。

你要了解JavaScript，还有其他知识

React是JSX，它是JavaScript的一种变体，这意味着你仍然需要了解JavaScript的实际机制。React可能比Angular更接近JavaScript，Angular在结构上更像是通过TypeScript实现类型转换和控件的传统编程语言。

这就是为什么你需要对JavaScript的机制有深入的了解，才能成为一名高水平、高效率的React开发人员。你需要深入研究的还有其他一些事物，其中包括状态和数据流的概念——因为这是React所打交道，并且优势很大的两大主题。

一旦你从菜鸟阶段成长起来，架构模式和结构就变得越来越重要。做电商应用时，你不能把整个销售系统，包括单品推荐、交叉推荐和历史购买推荐的代码都塞进根文件夹里面。

React的入门教程并不会教这些内容。实际上，大多数在线编程教程并没有认真去讲架构，也不会教你如何实现与框架或库相关的元事物。

https://medium.com/better-programming/a-comprehensive-guide-on-the-meta-knowledge-you-need-to-accelerate-your-code-creation-process-d0f5f3b67473

虽然代码编译后就没人能看到这些东西了，但是你的开发同事或接手你代码的人是会看到的——如果你的代码一团糟，改起来要人命，他们会发疯的。

React的优点

React作为一个库，意味着具有高度可移植性。你随便把它放在哪里都能正常工作——就像jQuery和Ajax那样。有时我们需要做微前端，抑或是处理一些和旧式系统有着密切联系的过渡型应用，这时React的可移植优势就非常有用了。

它与React Native的关系也是一个优点，它们改变了渐进式Web应用的制作方式。与其他基于JavaScript的框架（例如Ionic）不同的是，Ionic基本上就是打包你的Angular、Vue或React代码以生成能发布到商店的应用，而React Native则更进一步，会将代码转换为苹果和谷歌要求的原生语言。

因此，React Native不会把网站伪装成应用程序，而是将其转变为实际的应用程序——从而提供更好的整体性能，以及更好的途径来访问设备上的原生功能（如地图、指南针、图像和相机等）。代码本身还是以React为主，但是变成了适应各种移动设备的React版本。

React烦人的部分

作为从Angular住民踏入React世界的用户，我最烦React的事情之一，就是它缺乏很多常用功能，例如自动数据绑定等。而且为了给它开路，你得找来几乎所有基于JavaScript的库才行。作为对比，Angular这边你只要选一个已经打包进Angular的可用库即可。你只要记得导入它，然后就万事大吉！一切都很顺利，很正常。但React很大程度上要依赖第三方库，这些库可能彼此之间看不对眼，或者不能很好地与React搭配工作。

在React社区中，关于组件设计和组件组织的讨论也很少——或者只是我没找对地方？随着项目的发展，你经常会发现自己毫无必要地把状态推到树上面去了，结果在全局空间造成了意外的污染。一般会用Redux来解决这个问题——但是Redux并不是React，前者是一个完全独立的实体。

结 语

先声明一下，这些都只是我个人的看法，都是基于我对这个库已有的经验。总的来说，React的社区非常棒，但我在其中遇到的一些敌意在Angular世界中并不那么常见。

那么React被过誉了吗？

这实际上取决于你要与哪些圈子的粉丝打交道，而且什么事物都有自己的怪癖。React并不是前端解决方案的终极圣杯，但它已经做得够好了，所以非常有用。

当我也成长为老一代开发者，看过了那么多项目花开花谢，我再学习新技术时就不会把它们当成已有事物的终极解决方案了，而只会把它们看作是升级更新，并加入到我自己的知识库里。

React本身也不是全新的东西。它只是将JavaScript、HTML和CSS打包在一起的另一种途径。Angular刚出来的时候用的也是这种方法，之前的jQuery也一样。

业界永远都在追捧下一个热点，但最佳方法就是学习如何正确地编写代码，然后把这件事做好即可——因为不管现在的热点是什么框架、库、支架之类花哨的东西，都是无关紧要的。作为开发人员，你的水平取决于你能以多快的速度，凭借良好的编程基础来适应当前的需求和环境。

感谢你的阅读。

原文链接： https://medium.com/better-programming/is-react-overrated-c7f8efb75e3e