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 的入门教程并不会教这些内容。实际上,大多数在线编程教程并没有认真去讲架构,也不会教你如何实现与框架或库相关的元事物。
虽然代码编译后就没人能看到这些东西了,但是你的开发同事或接手你代码的人是会看到的——如果你的代码一团糟,改起来要人命,他们会发疯的。
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
相关文章:
React vs Angular vs Vue.js——2019 该选谁?(更新版)
Angular 重大版本升级: 8.0 正式发布! 支持更多 Web 标准
评论 5 条评论