这是一个创建于 2447 天前的主题，其中的信息可能已经有所发展或是发生改变。
比方说一排按钮，点击过以后变成灰色，灰色的再点击就不参与计算，用 jquery 的话，直接根据这个按钮的颜色就可以判断是否再参与计算。而 vue，必须得给这个按钮加一个属性，用来记录它的颜色。
这只是个简单的例子，如果是 n 排按钮，按钮要用 div 包裹，点击过后 div 的背景也变色，也要根据这个按钮的父元素 div 的颜色来判断，如果是 n 层 div 嵌套，用 vue 就很复杂了，用 jquery 直接用 parent().parent().parent()向上取父元素的属性即可。
简而言之，jquery 计算页面逻辑就像图形数据库，图形本身是参与运算的，而 vue 等框架，你必须得在脑子里建模，图形不参与运算，只用来展示。
这只是个简单的例子，如果是 n 排按钮，按钮要用 div 包裹，点击过后 div 的背景也变色，也要根据这个按钮的父元素 div 的颜色来判断，如果是 n 层 div 嵌套，用 vue 就很复杂了，用 jquery 直接用 parent().parent().parent()向上取父元素的属性即可。
简而言之，jquery 计算页面逻辑就像图形数据库，图形本身是参与运算的，而 vue 等框架，你必须得在脑子里建模，图形不参与运算，只用来展示。
第 1 条附言 · 2018-03-15 13:16:26 +08:00
jquery 直接操作 dom 是天然的数据可视化。
第 2 条附言 · 2018-03-15 14:26:34 +08:00
vue 等框架遇到复杂的 UI 操作，可能得给模型实现一套状态机 state machine。
而 dom，天然就是一个状态机，并且是看得见摸得着的，在开发过程中随时可以对这个对象的状态进行手动操作，从而调试、验证自己的代码逻辑
而 dom，天然就是一个状态机，并且是看得见摸得着的，在开发过程中随时可以对这个对象的状态进行手动操作，从而调试、验证自己的代码逻辑
 |
101
gouflv 2018-03-15 21:07:56 +08:00
数据可视化应该描述 D3 还差不多，套在 JQ 和 DOM 上很搞笑。。。
|
 |
102
sox 2018-03-15 21:12:34 +08:00  3
理智告诉我，不能鄙视小白
|
 |
103
TanJunqiang 2018-03-15 21:32:48 +08:00
数据为什么要和视图长在一起呢
|
 |
104
er567 2018-03-16 00:46:43 +08:00 via iPhone
炸出一堆前端送铜币（我也是
|
 |
105
msg7086 2018-03-16 02:05:28 +08:00 2
> 在开发过程中随时可以对这个对象的状态进行手动操作
当楼主还在沉迷于对每个对象手动操作的时候，Vue 程序员们早早地建完了模型写完了组件下班回家打游戏去了。 |
|
107
msg7086 2018-03-16 02:30:00 +08:00
|
 |
109
shynome 2018-03-16 03:06:15 +08:00 via Android
我只问一句多窗口同一数据渲染怎么弄？
数据一份更新多窗口同步更新，难道从其他页面中的 Dom 中查找数据，还不是要抽出一个数据源来通知其他页面进行更新 |
 |
110
eurokingbai2 2018-03-16 09:14:15 +08:00
MVC 都这样吧
|
 |
111
SilentDepth 2018-03-16 09:24:18 +08:00
一个数组生成一个列表，根据请求的数据切换不同元素的不同状态的时候怎么办？
根据数据切换元素的结构（<input> 变 <button> 这种）的时候怎么办？ 大量并发数据密集更新同一个元素的时候（性能）怎么办？ 需要组件化并引用到多个页面场景的时候怎么办？ 写一个内容不确定（需要其他人按要求填充）的组件的时候怎么办？ 一个 Object 映射为一堆元素的整合体的时候（更新视图）怎么办？ 我想专注于数据，不想思考 DOM 结构的时候怎么办？ --- jQuery 就是一套操作 DOM 的工具，甚至不算框架。当你需要给应用分层的时候，你依然需要基于 jQuery 封装一个「视图层」出来。看看 jQuery 和 Vue 的体积，jQuery 真的有那么大的优势吗？ |
 |
112
aokihu 2018-03-16 10:19:51 +08:00 2
我想说在座的各位都 TM 的是垃圾，没有一个回答到点子上的，首先这个提问者就是一个小白，如果你工作好几年了，那么恭喜你，你一点进步都没有，在座的各位也是
为啥开发了 React 和 VUE 还有 angular 框架，angualr 先不去管他，因为他的设计理念跟那两个不同，但是 React 和 VUE 要解决的就是 DOM 速度慢的问题 React 和 VUE 都是采用了虚拟 DOM 来维护自己的内部状态，虽然为此要多消耗一部分内存，和处理时间，但是跟直接去操作 DOM 来说，快的不是一点点，至少 10 倍的速度是有的，如果你的项目非常大的话，那可能就是 100 倍甚至 1W 倍的差距了。 你以为你改变了 DOM 属性这个操作很简单？你知道 DOM 的全称吗？ Document Object Model，看清楚 Document，也就是说你改的只是一个标签，实际计算的是整个标签树，同时还有样式的渲染，布局的计算等等，你如果什么都不懂，直接一个一个去操作 DOM 对象，你知道浏览器被你折磨成什么样子么？而 React 和 VUE 就是将你的数据变化线记录下来，然后通过对比内部的虚拟 DOM，将变化的部分替换到真实的 DOM 树中，这样以来你改变 1W 次，最后操作 DOM 树也就一次而已。如果你知道 document.createfragment()这个 API 应该知道，替换的消耗时间将会远远的少于你直接去一个一个修改节点内容。 你如果是纯展示页面，用 jQuery 没关系，但是你要是处理大量数据的话，使用 jQuery 就是找死了，别人花了 5、6 年时间开发的一个框架，难道还比不上你一个入门者的理解？ |
|
114
aokihu 2018-03-16 10:30:25 +08:00 1
@codehz VUE1 采用的是 Angular 的理念，因此我说了不要提 Angular 了，Angular 采用的是脏数据检查，将数据与 UI 显示同步，他解决的仅仅是数据的同步问题，因此性能上面并没有提升，你可以看看当年 angular+react 的实现，速度是纯 angular 的 100 倍，而 angular2+react 的速度简直就是火箭速度，因此 VUE2 后来改用虚拟 DOM 是很明智的举措，angular 能做的其实 jQuery 有个插件也能实现
|
 |
116
lizhenda 2018-03-16 10:38:00 +08:00
此贴反应各自的编程水平，真是赤裸裸啊，是骡子是马看你说的话大概就清除编程思维处于什么水平了
|
|
117
lizhenda 2018-03-16 10:39:23 +08:00
面向过程写多了会蠢的，天天写业务也会目空一切
|
 |
118
learnshare 2018-03-16 10:39:40 +08:00
@aokihu React 和 VUE 要解决的就是 DOM 速度慢的问题
这不是写着两个库的主要原因，甚至一开始考虑的根本不是性能问题 |
 |
119
shiye515 2018-03-16 10:41:56 +08:00
推荐楼主去关注 真阿当，你们算是臭味相投
|
 |
121
murmur 2018-03-16 10:46:40 +08:00
@aokihu DOM 速度慢？妈呀，如果真的优化到点子上会比虚拟 dom 慢
还是你想说那种 batch insert 一个一个创建节点要比 template 渲染完字符串一次插入刷新要快 你可以说现在浏览器牛逼 数据没到多的能看出差异 但是的却虚拟 dom 就是改善开发体验而不是改善性能体验的 |
 |
122
liuguangcuican 2018-03-16 11:02:28 +08:00
这贴有种'PHP 是最好的语言'的 影子:dog
|
 |
123
leekafai 2018-03-16 11:10:19 +08:00
真是……
这是各种 vm 不同于 jquery 的地方，不是“不如”。 想当初我都用的 jquery 肉搏页面，后来历史进程到了，只要用心去使用一次 vm 框架，就能体验到不去直接操作 dom 有什么好处的： 1. 状态统一。如果多个控件归属一个全局状态，用 jquery 的时候，很多人需要去肉搏样式修改，用 vm 就不需要了，这是代码上去帮你完成的事。 2.document 对象滥用。很多 jquery 使用者，产品性能低下的原因是滥用 document 对象，不习惯去使用常量保存数据，导致每次都要过一遍 document 对象。 3.无需直接操作 dom。这件事情有多重要，我想如果拥有一定量项目经验的开发者一定可以感受出来，页面变化是最大的，但是前端逻辑变化是很小的，逻辑操作数据，设置状态，再自动响应到页面中，可以写少超多代码。 |
 |
124
svenzhao 2018-03-16 11:13:42 +08:00
@feverzsj mvvm/ui 数据绑定 是客户端开发用了多少年的东西了 到你这就成了畸形产物了???????????????????
|
|
125
aokihu 2018-03-16 11:21:53 +08:00 via Android
楼主一看就是没有开发过 ie6，时代变了，以前的英雄居然现在被你认为是魔王
|
|
126
svenzhao 2018-03-16 11:24:08 +08:00
@aokihu
" React 和 VUE 都是采用了虚拟 DOM 来维护自己的内部状态，虽然为此要多消耗一部分内存，和处理时间，但是跟直接去操作 DOM 来说，快的不是一点点，至少 10 倍的速度是有的，如果你的项目非常大的话，那可能就是 100 倍甚至 1W 倍的差距了。 " 就这句话好意思来 教育别人?????dom 慢????? 所有直接操作 dom 的行为 一定是比虚拟 dom 快的 谁告诉你 vue1.0 是脏检测的??? 你分的清楚脏检测和虚拟 dom 吗 以后知识没学清楚 不要在网上乱科普 你这种半吊子吹水 单反差不多的公司面试都过不去 |
|
127
SilentDepth 2018-03-16 11:24:28 +08:00
@aokihu #114 Vue 1.0 解决的是精确依赖跟踪的问题，通过绑定 watcher 更新细粒度元素，但 watcher 过多会带来性能损失，所以 Vue 2.0 引入 VDOM 平衡一下。VDOM 是提高性能的手段，并不是目的（ React 是这样，Vue 更是）
|
|
128
SilentDepth 2018-03-16 11:26:50 +08:00
@svenzhao #126 直接操作 DOM 咋就比 VDOM 快了……如果直接操作 DOM 快的话 React 搞 VDOM 是图啥
|
 |
129
lscho 2018-03-16 11:29:36 +08:00
不是。。。我就想问一句，到底是你的颜色控制是否可用，还是数据控制是否可用？如果是颜色，难道设计给你一张图，上面画着灰色，就一直不可用吗？
既然是数据控制颜色，那 vue 为什么还要去操作 dom ？直接绑定就可以了啊，相当于给你省去操作 dom 的步骤了。 不要假设实际应用中不存在的情况好吗，实际应用中，你点个按钮不做任何判断就让他禁用？实际应用中，div 的颜色会无缘无辜的变化？按照你的设想就是纯 ui 特效啊，连 jq 都不用就行，原生 js 也是两行代码的事。 没有最好的技术，只有最适合的技术。一味的否定某种东西，只能证明自己没有接触到他的使用场景，只能证明自己的水平还没有达到理解这种技术的地步。 |
 |
130
WenJimmy 2018-03-16 11:33:54 +08:00
萌新瑟瑟发抖
|
|
131
svenzhao 2018-03-16 11:34:03 +08:00
@SilentDepth
首先 Vdom=>diff=>render 最后是不是还是使用浏览器 dom 的 api? 我的意思是 Vdom 目的是为了解放程序员在 diff 这一层的浪费的时间和代码量还有维护成本. Vdom 最终也无法避免操作 dom,它优化是 diff 过程.最后显示在浏览器上还是要使用普通的 api. //举例 有一个 10 行数据展示 然后通过 ajax 获取第一行数据 只修改第一行. 这一个非常明确需求下 直接 callback 之后操作第一行的文字内容改变 就少了 diff 的操作了 因为人你脑直接改了啊 |
|
132
SilentDepth 2018-03-16 11:37:55 +08:00
@svenzhao #131 也许是你表达得不具体。就是因为 DOM 操作慢（相对于 JS 的计算速度）但又无可避免，所以才要尽可能减少 DOM 操作，而 VDOM 就是实现这个目的的一种方案。你后面的举例太不普适了，哪有那么多只需要修改确定位置元素的需求
|
|
133
svenzhao 2018-03-16 11:38:33 +08:00
@SilentDepth 共勉
|
 |
134
MinonHeart 2018-03-16 12:53:25 +08:00 via iPhone
神特码 dom 慢，dom 是文档对象模型，慢个屁啊！慢的是渲染，渲染，渲染。
|
 |
135
DaraW 2018-03-16 13:06:07 +08:00 via iPhone
@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，我们比比谁写的性能更好？ |
 |
136
binux 2018-03-16 13:13:27 +08:00
@SilentDepth 这个场景并不罕见，手动维护 DOM 的时候，都是尽量手动优化，尽量少的修改 DOM。达到比 VDOM 好的性能并不奇怪。
|
 |
137
Ethan92 2018-03-16 13:13:57 +08:00
楼上大佬👆
|
|
138
SilentDepth 2018-03-16 13:25:26 +08:00
@binux #136 我说的「场景」是指那个「只修改第一行」来着。谈性能问题不能太理想化，毕竟所有需求都进行「底层优化式开发」是不现实的，也是没有（工程）意义的
|
Select Language