84669 person learning
152542 person learning
20005 person learning
5487 person learning
7821 person learning
359900 person learning
3350 person learning
180660 person learning
48569 person learning
18603 person learning
40936 person learning
1549 person learning
1183 person learning
32909 person learning
现在很多的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接口你敢用?
属性、尺寸访问的操作 很多都会触发重渲染 这个时候就看哪个浏览器优化的好渲染的地方少了