84669 人學習
152542 人學習
20005 人學習
5487 人學習
7821 人學習
359900 人學習
3350 人學習
180660 人學習
48569 人學習
18603 人學習
40936 人學習
1549 人學習
1183 人學習
32909 人學習
现在很多的js框架为了提高运行性能,会提出一个叫virtual dom的概念,最有名的是facebook的react。研读了一下,virtual dom的原理基本是在dom操作层之上用js另外模拟dom以达到减少dom操作的目的。我觉得很受启发,但细想一下,这一层如果是在浏览器中完成岂不是更快,为什么要在js库中实现呢?有什么具体原因么?求大神解答
人生最曼妙的风景,竟是内心的淡定与从容!
浏览器提供商想什么我不清楚,大致猜想大概会有这样一些考虑:
浏览器一般提供底层的 API,virtual DOM 算是很应用层面的技术了。
一般修改浏览器的 API 会涉及到制定和修改标准,然而制定标准很麻烦,多种 virtual DOM 并存的情况下不好统一。即便 React 的 virtual DOM 也一直在升级和调整。
Facebook 没能控制一款浏览器,推不动。
首先更正你的一个观点:虚拟DOM并不比原生DOM更快,react快是相对于其他框架来说的。
react
此外,原生DOM也有批量添加节点的接口(DocumentFragment)。并且浏览器为了提高渲染效率,在每次刷新时只更新变化的部分而不是整个窗口。
DocumentFragment
说到底,虚拟DOM只适合在react这种富客户端的UI框架里搞,而不具有普适性。更一般的情况现有的原生DOM已经能满足了。
问题你要有把握让每一个人都是用这样一个浏览器
即便浏览器支持虚拟dom出也不是新的接口为了向前兼容 浏览器做虚拟dom的可能性不太大何况为了兼容没虚拟dom的浏览器,就算给你虚拟dom接口你敢用?属性、尺寸访问的操作 很多都会触发重渲染 这个时候就看哪个浏览器优化的好渲染的地方少了
浏览器提供商想什么我不清楚,大致猜想大概会有这样一些考虑:
浏览器一般提供底层的 API,virtual DOM 算是很应用层面的技术了。
一般修改浏览器的 API 会涉及到制定和修改标准,然而制定标准很麻烦,多种 virtual DOM 并存的情况下不好统一。即便 React 的 virtual DOM 也一直在升级和调整。
Facebook 没能控制一款浏览器,推不动。
首先更正你的一个观点:虚拟DOM并不比原生DOM更快,
react
快是相对于其他框架来说的。此外,原生DOM也有批量添加节点的接口(
DocumentFragment
)。并且浏览器为了提高渲染效率,在每次刷新时只更新变化的部分而不是整个窗口。说到底,虚拟DOM只适合在
react
这种富客户端的UI框架里搞,而不具有普适性。更一般的情况现有的原生DOM已经能满足了。问题你要有把握让每一个人都是用这样一个浏览器
即便浏览器支持虚拟dom出也不是新的接口
为了向前兼容 浏览器做虚拟dom的可能性不太大
何况为了兼容没虚拟dom的浏览器,就算给你虚拟dom接口你敢用?
属性、尺寸访问的操作 很多都会触发重渲染 这个时候就看哪个浏览器优化的好渲染的地方少了