忘记Angular和Ember，React已经赢得了客户端战争

Nilson Jacques ， Chris Perry和Thomas Greco对本文进行了同行评审。 感谢所有SitePoint的同行评审人员使SitePoint内容达到最佳状态！

在SitePoint的论坛上，我偶然发现了一个名为So Many Frameworks的线程，其中Guido对可用的众多选项感到困惑，他问他应该采用哪种JavaScript框架来使他的应用程序更具动态性。 鉴于我在该行业中所看到的以及自己使用它的经验，我说React已经赢得了客户之战 。 像这样的战斗用词需要更多解释，所以这里是。

React不仅是热门新手，而且是统一的范例。 它可以作为Web应用程序的基础技术，我们可以放心地在此基础上构建它，因为它不会在下个月被更热的表亲取代。 让我们看一下React在当前MVC框架中的位置，探索其优势，并以对JavaScript未来发展方向的预测为结尾。

客户端MVC

在过去的几年中，许多聪明人一直在尝试构建用于制作单页应用程序（由JavaScript渲染的应用程序）的完美框架，这些应用程序通过即时响应用户输入和数据随时间的变化而提高了感知性能。 Guillermo Rauch的文章7富Web应用程序原理是为什么这很重要以及构建它们时应该考虑的事情的最佳理由之一。

您可以在TodoMVC上找到有关如何构建这些类型的应用程序的示例 ，顾名思义，它们在传统上是由模型，视图和控制器组成的。

反应从舞台左侧进入

当React首次发布时，它看起来有些奇怪。 它只专注于View层，没有模型或控制器。 这些代码示例是用一种称为JSX的奇怪语法编写的，在许多人看来，这似乎是向Ye'Olden Days倒退的一步，在该时代，通常将HTML和JavaScript混合在一起。

除了组件层次结构之外，没有提供任何有关如何构造应用程序的信息，UI的可组合块可以在状态改变时有效地重新呈现。 React对这个领域中存在的流行想法采取了一些明显的立场，诸如双向数据绑定和模板之类的功能被爆破，这是最好避免的坏主意。

广泛采用

反应迅速达到临界质量。 如今很难找到与JavaScript相关的邮件列表，会议或聚会， 而这些日子都没有提到React。 我城市中的所有本地开发团队似乎都在采用React，并且与其他流行的框架相反，判决似乎是一致的-我与之交谈的每个人都吹捧了单向数据流，组件层次结构和简单的显式呈现的优点，使任务更简单，代码更可预测。

React的采用使我感到惊讶，因为JavaScript的局面非常不稳定。 我们很少就任何事情达成如此广泛的共识。 忠于一个框架的人不胜枚举，但是我们大多数人已经从一个框架跳到另一个框架，并以引入复杂性和错误的某些模式感到沮丧。 我还没有听说过有人因为这些挫败感而离开 React，这并不是因为jQuery看起来我们前面有这么一个明显的赢家。

你有一份工作，一份工作。

它专注于视图层，这意味着它比试图解决每个问题的其他框架要少得多。 它的晶圆薄API意味着实际上没有太多要学习的东西，而且只需要几页的文档即可。 这对那些学习者有很大的帮助，也使开发更加简单，因为您没有太多的认知负担。 只要有可能，React都会选择简单的JavaScript结构和语言功能，而不是自定义API或模板语言。

这种设计也吸引了JavaScript开发人员，他们似乎偏爱专注于实用工具的库（例如Underscore和Moment） ，它们很好地完成了一件事情，非常符合Unix哲学 。 做好一件事情还为对项目感兴趣的人们留出了空间，将自己的作品贡献给React生态系统。 由于像React Router ， Redux和CSS Modules这样的项目的出现。

React组件很简单

组件负责隔离的UI小块，它们每次都接受数据并一致地呈现。 前端开发人员，后端开发人员和设计人员可以轻松理解组件并为它们做出贡献，因为它们看起来像HTML，并且API占用空间最小 ，这意味着您可以一天了解有关组件的知识并立即开始做出贡献。

服务器渲染的HTML

React使服务器端渲染变得微不足道，因为组件可以被认为是获取数据并返回HTML的函数。 通过这种设计，可以轻松地将服务器端渲染集成到任何服务器端编程语言或框架中。

在客户端MVC的早期，我们采用了hashbang路由和巨大的加载时间等方法使网络中断，然后一切都无法进入屏幕。 页面加载后，我们还使用JavaScript呈现了所有内容，从而打破了搜索引擎爬虫的范围。 从那以后，我们从错误中吸取了教训，并再次认真对待Web的这些核心原则-URL，服务器呈现的HTML和快速的加载时间。 React在其他框架苦苦挣扎的地方闪耀。

DOM更新很麻烦

骨干网是JavaScript的重要里程碑。 作为将MVC引入客户端的第一个也是最突出的尝试，它向我们展示了一种构建应用程序的新方法。 它在其文档中提到的第一件事是，在DOM中维护您的状态是一个坏主意。 当DOM仍然是事实的来源时，您的应用程序很快就会变得脆弱且难以遵循。 不可能知道哪段代码更改了哪个元素。 Backbone鼓励始终根据当前世界状况重新渲染视图的理想，React通过单向数据流模式实施了同样的想法。

React组件没有定义状态之间的过渡。 相反，他们根据当前状态显式渲染视图，从而完全消除了手动调整DOM的任务。 它的单向数据流阻止DOM成为事实的来源。

诚然，这会使某些任务（例如动画） 更加困难，因为在某些情况下您确实想定义状态之间的过渡。 不过，对于绝大多数情况而言，只关心组件呈现方式的最终状态要简单得多。

未来

React将继续变得越来越流行，我们将看到更多支持工具和项目。 随着React周围的生态系统的成熟，库可能会发生变化，但是单向数据流，组件层次结构，显式渲染和虚拟DOM协调的核心思想将继续存在。

React Native已经展示了如何将简单的视图层重新构造成其他类型的UI。 业界已经朝着这种构建UI的模式转变，并且这种情况不会很快消失。

简而言之，React赢了，未来是光明的。

有什么想法吗？

您是否同意React的原则会继续存在，还是我们下个月会找到更好的主意？

您开始使用React了吗？ 到目前为止，您有什么想法？

请务必在下面的评论中让我知道。

From: https://www.sitepoint.com/react-has-won-the-client-side-war/