最新消息:看到那些跳动的图片、文字了吗?点击点击 O(∩_∩)O~~

别再说虚拟 DOM 快了,要被打脸的

深夜食堂 onlyling 2232浏览

文章转载自公众号 前端桃园 前端桃园 , 作者 桃翁

如果你觉得虚拟 DOM 很快,那么这篇文章可能就是你所缺少的

我经常听到有人在群里,或者在社区里说的一个很严重的错误,那就是说 React 的 Virtual Dom 是以快出名的,比原生 DOM 快多了,啥啥啥的,每次都一两句话说不清楚,所以下次有谁再说 React 是以快出名的,你就把这篇文章丢给他,下面进入正题。

在过去的几年里,你一直在跟踪 JavaScript 社区的发展,你至少听说过 Virtual DOM(React,Vue.js 2,Riot.js,Angular 2等等)。他们承诺(或者更确切地说,他们的宣传)更快的渲染界面,特别是更新,减少麻烦。你很快的上手了使用虚拟 DOM 的应用程序,这很好。几个月后,您的应用程序现在变得越来越复杂,你可能从用户交互到屏幕更新只需要一两秒钟的更新。你可能会想,这东西很神奇,应该会比 jQuery 快,但是实际上不是这个样子的。

虽然我同意虚拟 DOM 为我们提供了很多便利,但我将解释为什么我认为根据定义,更快的渲染和更快的更新是不正确的。要付出代价,其利益并不是大多数人想象或至少希望的。

要阅读本文,您需要熟悉 DOM。理想情况下,您至少可以使用 DOM API。如果你只使用 DOM API 构建东西,你可能不需要这篇文章,但我仍然希望你阅读它并在评论中留下一点评语。

目录

  • 渲染和更新
  • 进入虚拟 DOM
  • 为什么有些开发人员认为 Virtual DOM 更快
  • 我们得到了什么?这值得么?

别再说虚拟 DOM 快了,要被打脸的

结论

React 厉害的地方并不是说它比 DOM 快,而是说不管你数据怎么变化,我都可以以最小的代价来进行更新 DOM。 方法就是我在内存里面用心的数据刷新一个虚拟 DOM 树,然后新旧 DOM 进行比较,找出差异,再更新到 DOM 树上。

这就是所谓的 diff 算法,虽然说 diff 算法号称算法复杂度 O(n) 可以得到最小操作结果,但实际上 DOM 树很大的时候,遍历两棵树进行各种对比还是有性能损耗的,特别是我在顶层 setState 一个简单的数据,你就要整棵树 walk 一遍,而真实中我可以一句 jQuery 就搞定,所以就有了 shouldComponentUpdate 这种东西。

框架的意义在于为你掩盖底层的 DOM 操作,让你用更声明式的方式来描述你的目的,从而让你的代码更容易维护。没有任何框架可以比纯手动的优化 DOM 操作更快,因为框架的 DOM 操作层需要应对任何上层 API 可能产生的操作,它的实现必须是普适的。

针对每一个点,都可以写出比任何框架更快的手动优化,但是那有什么意义呢?在构建一个实际应用的时候,你难道为每一个地方都去做手动优化吗?出于可维护性的考虑,这显然不可能。框架给你的保证是,你在不需要手动优化的情况下,我依然可以给你提供过得去的性能。

转载请注明:OnlyLing - Web 前端开发者 » 别再说虚拟 DOM 快了,要被打脸的