从 2010 年左右开始，Angular 就成为了顶级开发者首选的MVC 框架。这是最受欢迎的，它提供了开箱即用的最令人印象深刻的功能。这一切都在 2015 年发生了变化，这次的变化来自脸书的工程师。React 开始占据很大的市场份额，大量的玩家开始采用它:网飞、雅虎和 Airbnb，仅举几例。

*React 是一个巨大的革命性成功；它简单而有效，它永远改变了我们设计视图的方式。

React 不是一个 MVC 框架——它只是一个视图库。React 引入的概念使它成为一件大事。包括 Angular 在内的其他框架已经从 React 的工作中学到了东西，并部分或完全复制了它。

然而，这个故事并不是关于一个从脸书接手的闪亮的新图书馆。这里的故事是关于 MVC 不是大型应用程序的最佳方法，以及到目前为止一直是标准的 REST APIs，不是客户端和服务器之间数据通信的最佳解决方案。

脸书的工程师正在挑战 MVC 和 REST 标准。以下是他们的备选方案，总结如下:

• 前端系统应该有单向数据流，而不是 MVC 和数据绑定。视图不应该直接改变模型；他们只能从模型中阅读。对于写作来说，视图触发最终被分派给模型的动作(模型在这个流程中被称为“商店”)。React 完全符合它对商店中数据变化的反应方式。React 组件将监听这些变化，并且当这些变化发生时，React 将有效地重新呈现视图。
• 不是 REST 和在服务器端公开什么数据的逻辑，也不是针对不同的需求管理不同的端点(例如，一个端点公开顶级帖子，一个端点公开帖子，一个端点公开包含评论的帖子)，而是让客户端向服务器询问他们到底需要什么。然后，服务器将解析客户的问题，并以他们要求的东西作为响应(没有过度获取或不足获取)。这是脸书工程师在 2015 年发布的 GraphQL 运行时和查询语言背后的概念。
• 不要使用分离数据和视图的标准建议，而是在视图组件本身中表达数据需求。因为视图确切地知道它需要呈现哪些数据元素，所以这两者根本不应该分开。这是脸书工程师在 2015 年发布的 Relay.js 框架背后的概念。

这本书不会涉及 GraphQL 或 Relay，但是理解 React 本身是理解脸书工程师提出的架构其余部分的第一步。

我为什么要写这本书？

我喜欢大框架(我不能撒谎)。它们服务于一个伟大的目标，尤其是对于年轻的团队和初创企业。已经为我们做出了许多聪明的设计决策，并且有一条清晰的路径来编写好的代码。这使我们能够专注于应用程序的逻辑。

然而，框架也有一些缺点，对于大型应用程序和有经验的开发人员来说，这些缺点有时会破坏交易。

我将列举框架的两个相关缺点:

• 框架并不灵活，尽管有些人会声称如此。框架希望我们以某种方式编码一切；如果我们试图偏离这种方式，框架通常会在这个问题上与我们发生冲突。
• 框架很大，充满了特性。如果我们只需要使用其中的一小部分，我们无论如何都必须包含整个东西(希望这将随着 HTTP2 而改变)。

有些框架正在走向模块化，我认为这很好，但我是 Unix 哲学的忠实粉丝:

”写做一件事并且做好的程序。编写程序一起工作。编写程序来处理文本流，因为这是一个通用接口。”—道格·麦克洛伊

React 是一个做一件事的小程序，它做得非常好。关于 React 的虚拟 DOM 的表现有很多议论，但我不认为这是 React 最伟大的地方。虚拟 DOM 性能是一个很好的优势。

React 真正擅长的是在开发人员和浏览器之间使用一种通用语言，允许开发人员声明性地描述用户界面，并对这些界面的状态而不是其上的事务进行建模。基本上，React 教会了我们和机器一种我们现在都理解的新语言:用户界面结果语言。

这种认识是我对 React 所做的最重要的一个认识，我认为它值得一本专注于让每个学习 React 的人都明白这一点的书。

谁应该读这本书？

你需要 JavaScript 的基础知识才能在这本书里生存。这本书不会教你 JavaScript。如果你对 JavaScript 本身感到满意，但以前从未使用过 JavaScript 框架或库，这本书就是为你准备的。

如果你正在学习使用其他 JavaScript 库后的反应，这本书也会有一个“为什么”的答案可能在你脑海中的问题:为什么要费心学习新的东西？*