React和动态网站接口的经济学
React and the economics of dynamic web interfaces
自从2000开始我就一直在做web开发，曾见过很多以各种库和框架的起起落落，这些库和框架作为一种时代标志。Ajax时代和JQuery的时代几乎相同，几年后Backbone时代开始了，而React则开始于两年前。
这些时代带来了一种新的实现方式--我们可以通过可用工具提供的手段来创造动态网站接口。JQuery使用浏览器抽象和css查询提高对开发人员友好程度，Backbone介绍了客户端结构的概念，React则开启了创造UI组件来取代之前的模版。
有大量的博客帖子，言论，和视频去宣扬Ract工作方式以及它为什么对web开发有益。有很多讨论围绕虚拟DOM，在JSX文件（javascript）中嵌入HTML代码，将UI转化为组建展开。这些都是React中有趣的技术点，无论怎样，我不相信仅仅是技术方面会让它如此火爆。经过一段事件的深入探究，我意识到React真是太牛逼了：它从根本上改变了N多年前的等式，并且这种思想远比具体的技术实现牛逼多了。
动态web接口的经济学
自从DOM被介绍以及在web浏览器的广泛采用后，web的开发人员都看到过一个相同的建议：DOM是比较慢的。避免DOM更新，你会得到重绘制和重布局。总言之，动态更新网站的耗费是有形的，可以从一下三个角度分解：
关于repaint和reflow具体请参考repaint和reflow讲解l
- 执行 - 对DOM做出的改变比较慢原因是重绘和重布局
- 效率 - 你可以因为丢失节点参考的情况造成内存泄漏
- 复杂性 - 必须保证你可以在正确的位置上绑定和取消事件处理器
我们可以从一下几个方面减少损耗
- 仅仅做出少量的更改。大量更改是非常慢的，如果你制作少量更改会减少损耗。 React通过比较获得最小差异来做到
- 对于大的改变，从文档中解除节点，做出改变然后再重新加到文档里。这样可以避免重绘制和重排版。 React有这种思路，一位html是通过javascript操作的，操作完，才渲染，可以有效避免重绘和重布局
- 在父节点上使用事件代理，这样就不会在删除子节点的时候意外删除了事件处理程序。
每一个建议都是减小损耗但实际上没有从根本上改变耗费等式。在这样的条件下，你肯定不想用一个命令去反复多次重渲染页面，无疑会带来特别差劲的用户体验。那正是React能够发挥作用的时候。
React改变了这个等式
你不曾怀疑的意识到，React解决了很多问题。他管理了你的事件处理程序，确保他们被添加和解除在正确的事件和正确的节点上；它创造和销毁DOM结构考虑到内存泄漏（效率）；它使用虚拟DOM比较去决定哪一个变更组建要更新，并且只更新那些有必要更新的部分。所有的这些解决方案改变了曾经的等式：DOM更新现在很快！
（当然，在React是否有人们所有的那样块上仍有争论[1]，争论并没有什么意义，知道这种思想更重要）
在我们开发Web应用程序的时候，改变方程导致了一个连锁效应。这发生在我第一次看React Router[ 2 ]。React Router的基本前提是当网址发生变化时，它被历史状态管理机制[3]拦截，然后整个视图被重新渲染。在React没出现的时候，你永远不会想到动态重新绘制一个完整的页面，这太慢了。确保页面正确工作的复杂性是很高的，虽然有些人会这样做，但它无疑是错误的来源。所以我们只会坚持重新绘制页面的较小部分。
有了React你会想到，在一组相似性的页面中，你没有必要重新渲染一切。仅仅是更新页面中变化了的那部分就可以啦。
反应，具有讽刺意味的是，让我们再次思考编写关于Web应用程序的一个系列的网页，而不是单一的BLOB的JavaScript代码。与传统的服务器模型相同，一个页面被渲染，一些变化被请求，然后一个页面呈现这些变化。唯一不同的是，这一切都可以发生客户端。
结论
我仍然在学习React，而技术细节是有趣的，它改变了动态Web界面方程的方式真的给我留下深刻印象。最后，我问自己这样的问题：“如果没有客户端渲染的成本，你会建立什么？”.我意识到React改变了游戏规则。
参考
- React + Performance = ? (aerotwist.com)
- React Router (github.com)
- History API (developer.mozilla.org)
Disclaimer: Any viewpoints and opinions expressed in this article are those of Nicholas C. Zakas and do not, in any way, reflect those of my employer, my colleagues, Wrox Publishing, O'Reilly Publishing, or anyone else. I speak only for myself, not for them.
自从2000开始我就一直在做web开发，曾见过很多以各种库和框架的起起落落，这些库和框架作为一种时代标志。Ajax时代和JQuery的时代几乎相同，几年后Backbone时代开始了，而React则开始于两年前。
这些时代带来了一种新的实现方式--我们可以通过可用工具提供的手段来创造动态网站接口。JQuery使用浏览器抽象和css查询提高对开发人员友好程度，Backbone介绍了客户端结构的概念，React则开启了创造UI组件来取代之前的模版。
有大量的博客帖子，言论，和视频去宣扬Ract工作方式以及它为什么对web开发有益。有很多讨论围绕虚拟DOM，在JSX文件（javascript）中嵌入HTML代码，将UI转化为组建展开。这些都是React中有趣的技术点，无论怎样，我不相信仅仅是技术方面会让它如此火爆。经过一段事件的深入探究，我意识到React真是太牛逼了：它从根本上改变了N多年前的等式，并且这种思想远比具体的技术实现牛逼多了。
动态web接口的经济学
自从DOM被介绍以及在web浏览器的广泛采用后，web的开发人员都看到过一个相同的建议：DOM是比较慢的。避免DOM更新，你会得到重绘制和重布局。总言之，动态更新网站的耗费是有形的，可以从一下三个角度分解：
关于repaint和reflow具体请参考repaint和reflow讲解l
- 执行 - 对DOM做出的改变比较慢原因是重绘和重布局
- 效率 - 你可以因为丢失节点参考的情况造成内存泄漏
- 复杂性 - 必须保证你可以在正确的位置上绑定和取消事件处理器
我们可以从一下几个方面减少损耗
- 仅仅做出少量的更改。大量更改是非常慢的，如果你制作少量更改会减少损耗。 React通过比较获得最小差异来做到
- 对于大的改变，从文档中解除节点，做出改变然后再重新加到文档里。这样可以避免重绘制和重排版。 React有这种思路，一位html是通过javascript操作的，操作完，才渲染，可以有效避免重绘和重布局
- 在父节点上使用事件代理，这样就不会在删除子节点的时候意外删除了事件处理程序。
每一个建议都是减小损耗但实际上没有从根本上改变耗费等式。在这样的条件下，你肯定不想用一个命令去反复多次重渲染页面，无疑会带来特别差劲的用户体验。那正是React能够发挥作用的时候。
React改变了这个等式
你不曾怀疑的意识到，React解决了很多问题。他管理了你的事件处理程序，确保他们被添加和解除在正确的事件和正确的节点上；它创造和销毁DOM结构考虑到内存泄漏（效率）；它使用虚拟DOM比较去决定哪一个变更组建要更新，并且只更新那些有必要更新的部分。所有的这些解决方案改变了曾经的等式：DOM更新现在很快！
（当然，在React是否有人们所有的那样块上仍有争论[1]，争论并没有什么意义，知道这种思想更重要）
在我们开发Web应用程序的时候，改变方程导致了一个连锁效应。这发生在我第一次看React Router[ 2 ]。React Router的基本前提是当网址发生变化时，它被历史状态管理机制[3]拦截，然后整个视图被重新渲染。在React没出现的时候，你永远不会想到动态重新绘制一个完整的页面，这太慢了。确保页面正确工作的复杂性是很高的，虽然有些人会这样做，但它无疑是错误的来源。所以我们只会坚持重新绘制页面的较小部分。
有了React你会想到，在一组相似性的页面中，你没有必要重新渲染一切。仅仅是更新页面中变化了的那部分就可以啦。
反应，具有讽刺意味的是，让我们再次思考编写关于Web应用程序的一个系列的网页，而不是单一的BLOB的JavaScript代码。与传统的服务器模型相同，一个页面被渲染，一些变化被请求，然后一个页面呈现这些变化。唯一不同的是，这一切都可以发生客户端。
结论
我仍然在学习React，而技术细节是有趣的，它改变了动态Web界面方程的方式真的给我留下深刻印象。最后，我问自己这样的问题：“如果没有客户端渲染的成本，你会建立什么？”.我意识到React改变了游戏规则。
参考
- React + Performance = ? (aerotwist.com)
- React Router (github.com)
- History API (developer.mozilla.org)
Disclaimer: Any viewpoints and opinions expressed in this article are those of Nicholas C. Zakas and do not, in any way, reflect those of my employer, my colleagues, Wrox Publishing, O'Reilly Publishing, or anyone else. I speak only for myself, not for them.
