vue 等框架不如 jquery 的地方： dom 无法参与计算，仅仅是用来展示。

[gs139]

比方说一排按钮，点击过以后变成灰色，灰色的再点击就不参与计算，用 jquery 的话，直接根据这个按钮的颜色就可以判断是否再参与计算。而 vue，必须得给这个按钮加一个属性，用来记录它的颜色。

这只是个简单的例子，如果是 n 排按钮，按钮要用 div 包裹，点击过后 div 的背景也变色，也要根据这个按钮的父元素 div 的颜色来判断，如果是 n 层 div 嵌套，用 vue 就很复杂了，用 jquery 直接用 parent().parent().parent()向上取父元素的属性即可。

简而言之，jquery 计算页面逻辑就像图形数据库，图形本身是参与运算的，而 vue 等框架，你必须得在脑子里建模，图形不参与运算，只用来展示。

[murmur]

@aokihu DOM 速度慢？妈呀，如果真的优化到点子上会比虚拟 dom 慢
还是你想说那种 batch insert 一个一个创建节点要比 template 渲染完字符串一次插入刷新要快
你可以说现在浏览器牛逼 数据没到多的能看出差异
但是的却虚拟 dom 就是改善开发体验而不是改善性能体验的

[liuguangcuican]

这贴有种'PHP 是最好的语言'的 影子:dog

[leekafai]

真是……
这是各种 vm 不同于 jquery 的地方，不是“不如”。
想当初我都用的 jquery 肉搏页面，后来历史进程到了，只要用心去使用一次 vm 框架，就能体验到不去直接操作 dom 有什么好处的：
1. 状态统一。如果多个控件归属一个全局状态，用 jquery 的时候，很多人需要去肉搏样式修改，用 vm 就不需要了，这是代码上去帮你完成的事。
2.document 对象滥用。很多 jquery 使用者，产品性能低下的原因是滥用 document 对象，不习惯去使用常量保存数据，导致每次都要过一遍 document 对象。
3.无需直接操作 dom。这件事情有多重要，我想如果拥有一定量项目经验的开发者一定可以感受出来，页面变化是最大的，但是前端逻辑变化是很小的，逻辑操作数据，设置状态，再自动响应到页面中，可以写少超多代码。

[svenzhao]

@feverzsj mvvm/ui 数据绑定 是客户端开发用了多少年的东西了 到你这就成了畸形产物了???????????????????

[aokihu]

楼主一看就是没有开发过 ie6，时代变了，以前的英雄居然现在被你认为是魔王

[svenzhao]

@aokihu
"
React 和 VUE 都是采用了虚拟 DOM 来维护自己的内部状态，虽然为此要多消耗一部分内存，和处理时间，但是跟直接去操作 DOM 来说，快的不是一点点，至少 10 倍的速度是有的，如果你的项目非常大的话，那可能就是 100 倍甚至 1W 倍的差距了。
"
就这句话好意思来 教育别人?????dom 慢?????
所有直接操作 dom 的行为 一定是比虚拟 dom 快的

谁告诉你 vue1.0 是脏检测的??? 你分的清楚脏检测和虚拟 dom 吗

以后知识没学清楚 不要在网上乱科普 你这种半吊子吹水 单反差不多的公司面试都过不去

[SilentDepth]

@aokihu #114 Vue 1.0 解决的是精确依赖跟踪的问题，通过绑定 watcher 更新细粒度元素，但 watcher 过多会带来性能损失，所以 Vue 2.0 引入 VDOM 平衡一下。VDOM 是提高性能的手段，并不是目的（ React 是这样，Vue 更是）

[SilentDepth]

@svenzhao #126 直接操作 DOM 咋就比 VDOM 快了……如果直接操作 DOM 快的话 React 搞 VDOM 是图啥

[lscho]

不是。。。我就想问一句，到底是你的颜色控制是否可用，还是数据控制是否可用？如果是颜色，难道设计给你一张图，上面画着灰色，就一直不可用吗？
既然是数据控制颜色，那 vue 为什么还要去操作 dom ？直接绑定就可以了啊，相当于给你省去操作 dom 的步骤了。

不要假设实际应用中不存在的情况好吗，实际应用中，你点个按钮不做任何判断就让他禁用？实际应用中，div 的颜色会无缘无辜的变化？按照你的设想就是纯 ui 特效啊，连 jq 都不用就行，原生 js 也是两行代码的事。

没有最好的技术，只有最适合的技术。一味的否定某种东西，只能证明自己没有接触到他的使用场景，只能证明自己的水平还没有达到理解这种技术的地步。

[WenJimmy]

萌新瑟瑟发抖

[svenzhao]

@SilentDepth
首先 Vdom=>diff=>render 最后是不是还是使用浏览器 dom 的 api?

我的意思是 Vdom 目的是为了解放程序员在 diff 这一层的浪费的时间和代码量还有维护成本.
Vdom 最终也无法避免操作 dom,它优化是 diff 过程.最后显示在浏览器上还是要使用普通的 api.

//举例
有一个 10 行数据展示 然后通过 ajax 获取第一行数据 只修改第一行.
这一个非常明确需求下 直接 callback 之后操作第一行的文字内容改变 就少了 diff 的操作了 因为人你脑直接改了啊

[SilentDepth]

@svenzhao #131 也许是你表达得不具体。就是因为 DOM 操作慢（相对于 JS 的计算速度）但又无可避免，所以才要尽可能减少 DOM 操作，而 VDOM 就是实现这个目的的一种方案。你后面的举例太不普适了，哪有那么多只需要修改确定位置元素的需求

[svenzhao]

@SilentDepth 共勉

[MinonHeart]

神特码 dom 慢，dom 是文档对象模型，慢个屁啊！慢的是渲染，渲染，渲染。

[DaraW]

@aokihu
槽点太多，随便挑两个说下。

Vue1 使用的是依赖收集和追踪而不是 ng1 的脏检测，不信自己去翻源码。Vue2 引入了 V-DOM 也只是把组件级别的更新交给了 V-DOM 而没有改变依赖收集和追踪的本质。

另外，React 和 Vue 使用的 V-DOM 并没有解决 DOM 操作慢的问题（ http://www.zhihu.com/question/31809713 ），不信我们开个 Repo 撸 ToDo List 跑 benchmark，Vue/React 随你挑，我就用原生 JS，我们比比谁写的性能更好？

[binux]

@SilentDepth 这个场景并不罕见，手动维护 DOM 的时候，都是尽量手动优化，尽量少的修改 DOM。达到比 VDOM 好的性能并不奇怪。

[Ethan92]

楼上大佬👆

[SilentDepth]

@binux #136 我说的「场景」是指那个「只修改第一行」来着。谈性能问题不能太理想化，毕竟所有需求都进行「底层优化式开发」是不现实的，也是没有（工程）意义的