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

我也不知道怎么表达了，总之，取一个 dom 的状态：比如边框形式、背景色......等属性。用 jquery 的话，直接从 dom 上取就行，用 vue 必须得在 json 数组元素里增加这些属性来记录边框形式、背景色等状态，然后再在代码逻辑里取这些属性。

dom 本身参与运算，这不是落后，却恰恰是先进的理念，最直观的表达数据的状态，这是我用 jquery 感觉最爽的地方。

点击过后，用 vue 给按钮一个 class，就可以了。

vue 里你依然可以用原始的 dom 操作 不要把锅甩给 vue
你就算不知道 vue 可以用$ref 给个 id 然后 getElementById 会吧
你如果把握不好 vue 的生命周期 setTimeout 会吧
拿到原始元素了 你想怎么玩怎么玩

vue 的设计思路跟 jquery 根本就不一样吧

视图是视图对象上的模型的反映，说到底是在操作数据.

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

那你两者一起用不就不好，虽然不怎么优雅，但又不是不能用
思路完全不同的两者有什么可比性？

你想的完全错了
MV* 的核心理念是数据模型，UI 只是呈现数据和接收点击、输入等操作的地方

你讲的按钮变成灰色，这个状态应该对应数据中某个按钮的数据变成 disabled = true
UI 上的一切东西都是在呈现数据模型的某个状态，一切数据操作都针对数据模型

UI ？可以当做一张静态图像，不存在也没问题（ server-side-render 就是这个概念）

const buttOns= [{
data: 100, // 按钮数值
disable: true //用来控制按钮是否可点击
},{
data: 200,
disable: false
}{
data: 300,
disable: true
}]

Vue 这类框架的好处就是数据驱动 UI，你并不需要太关心和操作 UI，数据变更自然会带动 UI 的变更

@cuqk 如果还需要判断哪个按钮有这个 class，哪个按钮没有 calss 呢？在 vue 里就得给生成这些按钮的数组元素加个属性，用来标记是否被点击。如果有 n 种状态，可能得加 n 种标记。而 jquery 是不需要这样的，直接从 dom 里取状态就行。

@SourceMan 对，我就是这个意思，vue 必须得在 json 数组里建模，而 jquery 直接在 dom 上建模了，在 dom 上建模是天然的数据可视化，这是优点不是缺点

jquery 直接操作 dom 是天然的数据可视化。

所以本质到底是颜色是灰色所以不能点击，还是状态是 disabled 所以不能点击？
你这么写代码，后人维护你代码看到一堆 if a 是蓝的 b 是红的，就 xxxx，if c 是黄的，ooooo。WTF ？

总感觉在争面向过程和面向对象哪个好

jquery 这种 ui 直接参与运算，不是缺点，恰恰是优点，把抽象的逻辑直接可视化了。让数据眼睛看得见、手摸的着，这不正是我们追求的吗？连思维导图都不用画了。

明天设计把灰色改成深灰，你要怎么办？

@binux 灰色还是深灰，直接写在样式表里定义 class，jquery 计算的时候判断有没有这个 class 就行了。

你这完全没有考虑性能和后期的维护，取 dom 判断颜色和从内存中取数据判断那个性能更好？后期颜色变了呢，需要修改多个地方的颜色值，用 vue.js 只需要修改一处

搞反了
按钮的 disabled 属性 决定它是不是灰色，也决定它能不能被操作；而不是因为它是灰色所以不能操作

jquery 怎么做单元测试？我不太懂？

@lmqdlr 见 19 楼，把颜色写在 css 里，jquery 只添加或判断 dom 是否有某个 class。至于性能，jquery 能保证只修改这一个 dom，vue 还得再虚拟 dom 里模拟一遍，还说不准谁比谁快呢。

@jeremaihloo 对 ui 操作部分做单元测试？你确定有比按键精灵更合适的吗？

@gs139 那后天设计不但要改颜色，还要将按钮设置为无效，并且在旁边加一行小字怎么办？

天然地可视化逻辑哈哈哈…… Vue 不就是给了你 data 做成天然可视化的功能吗

你熟悉 jquery，自己偏好操作 dom，所以觉得在这些方面 vue 不如 jquery。你说的那些 vue 都能做到而且并不复杂性能也许更好，你非要说不能操作 dom 所以它不好。人家设计思想本来就尽量不要操作 dom。

vue 要渲染，jquery 操作是渲染好的 ui，这没得比啊。只能说先后的问题。楼主你太认真了。哈哈。

我倒觉得这是优势，避免错误的使用是 feature，不是缺点。

都不了解 vue 的原理，还有 JQ 的分类，就好意思来这里说- - ！
vue 是作为 mvvm 的框架提供的，
jquery 只是一个插件提供了很多公用方法，而已，两者不一样好吗~

dom 的缺点就是改 dom 的时候，dom 是很有可能修改的，比如改需求。所以不能绑定在 dom 上，绑在 class 上更好。而 class 一般和 css 是有关系的，所以绑在自定义属性上更好。所以后面的这些框架都用属性来绑定数据的。

所以，我一直强调，除非重客户端，否则用这些框架就是人多太闲。

作为后端，比较烦得一件事。就是这些前端玩意（包括各类前端组件库），后端渲染居然不支持后端语言（ java、C#、python、PHP 等）

Java、C# 不如 纸带 的地方：机器码无法参与编辑，仅仅是用来执行。

数据的不同状态对应不同的样式，
而不是根据样式的状态来判断数据的状态，这是以前没有 mvvm 框架的时候不得不这么做。
数据是核心。
不用 mvvm 框架之前，是在修改数据的同时要修改 dom 的样式，而框架帮你省略了修改 dom 这个步骤。

你这数据源就不对，没理解 vue。当然，vue 能实现你想要的

@duan602728596 你以前用 jquery 的时候还用 Javascript 自己建一套模型？你这姿势不对啊大哥，用 jQuery 的时候，dom 既是数据，可以理解成可视化的数据库。你没有理解 jquery 的精髓。

建议先去了解下前端 mvvm 之类出现的原因再来说这个会比较好

就拿 parent().parent().parent() 来说。
如果是结构复杂而且经常要改，你就等着哭吧

@des “结构复杂，经常要改”，说的就跟 vue 可以一键重构似的。如果前端界面修改很大，不管用哪种框架，都很麻烦，麻烦到一定程度.......直接重写。

前端界犯的一个大错就是老是想模仿后端，前端跟后端不一样的，不管是从技术实现还是现实需求，前端不可能像后端那样一个项目有几年的积累。

前端就像卫生巾，用完了直接扔（就算你舍不得扔，老是一种操作方式用户也会厌烦，会以为你这个项目没人维护了）

后端就像内裤，用完了可以洗，洗干净了晒干了可以继续用

楼主，jQuery 方面，建议你再多熟悉下，
你这 jQuery 用的非常渣啊；
你是用 parent().parent().parent()；这么取的值，难道写的时候不觉得蛋疼么？？
建议 closest() 这个来替换，
否则 DOM 结构需要修改的话。或者层级变了，那你岂不是要蛋疼死了；

视图是数据的提现，操作数据 --> 变更视图。

@gs139 不是前端模仿后端，而是一个功能，以前前端不能做，现在前后端都可以做了，这就给系统架构带来更多选择，在多数情况下，把功能放在前端可以大大地降低服务器的压力，也就是大大地省钱。

在这里面，前端和后端不是对立的，前端和后端的区别根本不是重点，重点是降低成本。

前端确实是所谓的"老想模仿后端"，引入了越来越多的东西。

但是这些理念确实是正确的，最起码 逻辑清晰

@an168bang521 那只是打个比方，怎么那么多人咬住 parent().parent().parent()这个细节不放呢？说的好像跟我不会用 closest()似的。

我打这个比方只是要说明，jquery 寻找父元素、子元素很容易，这是 jquery 的强项。


[数据可视化，dom 既是数据，数据既是 dom]
[轻而易举的上溯父元素、查询子元素、查询前后同级元素]


特别是直接把 dom 作为数据，直接应用到 UI 的运算中，这是最大的优点啊！！！数据可视化不是编程界一直追求的吗？怎么把这么好的方案摆在你们面前，你们又去追寻所谓的 mvvm 了？

至于调样式、改风格，用 jquery 也是在 css 文件里改啊。如果界面到了大幅调整的程度，你确定 vue 不是重写？用 vue 重构的时间，jquery 都重写好几遍了。

怕是不懂 OO 吧

你说了这么多就是现在不会 VUE 也不想学会

楼主用过 canvas 吗？
canvas 其实就是将数据绘制到 canvas 标签里，根本没有操作 canvas 已经绘制的内容的 API。

楼主一直在说[数据可视化，dom 既是数据，数据既是 dom] ，但是楼主对 DOM 的概念停留在浏览器渲染出来的画面上，而不认为 DOM 是渲染前的数据，是观念上的问题。

DOM （ Document Object Model，文档对象模型），它根本就是一个对象。

vue 就是为了把展示层和数据层分开。如果逻辑很简单，不需要区分就别用嘛。就跟你去马路对面小卖部买个饮料，是不是非要开车呢？是不是得吐槽汽车启动慢还费油呢？

别扯淡了，只会 jquery 的前端，找个工作试试。

这么萌新的帖子你们回复的真起劲儿，直接忽略不就好了

@gs139 vue 没学好 jq 也没看出来水平多高


先不说中大型的 jquery 项目需要多高的约束条件 和对用人的能力要求.
(如果你觉得 jquery 是一个入门的人就能用好的 后面你也别看了.)


来个实际问题

100 行<li>元素 长轮询动态改变<li>中的视图的较好实践.

你用 jquery 裸写 diff 自己算算多少代码
你要是 js 模板引擎重新渲染算我没问

楼上这么多人还正儿八经地讨论。。。。。


要我说？


楼主再写两年前端就啥问题没有了，这个问题纯属技术不过关导致的。

坦白说吧，楼主你说的恰恰是 Vue 等框架的优点。

DOM 本质上也是一种 Model。跟 VUE 操作的 VNode 没啥区别，只是浏览器渲染 DOM 的时候帮你做好了大量的映射。

再说数据可视化什么的，跟 DOM 没半点关系，非要扯不如直接在 canvas 上画东西呀。或者用 SVG （另一种 DOM ）。

jQuery 本身只是一种 query api 而已，跟 vue 也没有什么可比性。vue 和 jQ 本来就可以一起用的，没必要分得一清二楚。

一个面向数据，一个面向 DOM。
而且明显面向数据简单的多，解放双手。

而且你这种 parent().parent().parent() 的用法，在 jquery 中也是个很不好的方式，代码可读性太差。

简而言之：JQuery 是万能的。

jQuery 就是不如 vue, 你打我啊....

其实..人家项目小,用 jQuery...速度快.好上线..何必强迫人家去学习新方法呢..

@moqiao dom 本身作为数据，没什么不好，可视化，随时看到所有数据模型的状态。没有什么不妥的地方。

也可以给 dom 专门加一个 class 用来给 jquery 作识别，这样页面改版的时候也不受影响

jQuery 不如原生的地方：页面还得多引用个 js 包

我觉得你给个 jq 方便好用具体的例子传到 jsfiddle 上，我们来评判一下是不是真的很好用。懂 vue 的同学可以根据你的例子用 vue 写一遍，你也来评判是不是好用。

@noe132 好，等我吃完饭就把相关的 Demo 传上去，切磋切磋，是骡子是马，牵出来溜溜

@noe132 你这么搞对框架不公平的…… 能够放到 jsfiddle 里面的例子，必然短小到用 jQuery 写也无妨的地步，体现不出框架和数据 /视图分离的重要性。框架只有到项目大到一定程度，各种组件化和达到一定规模的团队参与的时候，才有明显优势。

所以搞网页前端的对 MVVM 这类的玩意儿了解不能, 杯具

你对 jquery 和 vue 的理解还不透彻啊，你说的完全可以使用 click.capture 解决，建议多看一些文档再来

.parent().parent().parent()这种代码多了就是灾难

我就问问 你的 dom 怎么来的

以前我年轻气盛的时候，遇到题主这样的问题还会做些无意义的争论，现在的话我都是完全看开了。
正是有那么多不知天高地厚的菜逼，才能让那些虚心好学努力进取的孩子脱颖而出。

我算是知道为什么我上个星期面试的时候前端总工恨不得让我造飞机了

哎，算了算了，这恐怕是前端被黑的最惨的一次了，我还是回去写我的 react 去了……

哈哈哈，今天天气不错哦，可以穿 T 恤了~
你说这跟天气有什么关系？
那 Vue 跟 jQuery 又有什么关系？

民主制不如君主制的地方：不能一个人说了算

楼主写的 vue 是不是都是
```js
mounted () {
$().a().b().c()
}
```

楼主的问题挺好的

vue 也能直接判断 dom..
看你会不会用

@LancerComet 赞成，dom 上的操作也是为了数据，把数据整理好，做好绑定，非常喜欢这种方式。

过去我写代码的时候还真的是到处都是 parent().nextUntil().find().filter().last().children().not().siblings()，写起来特有成就感，觉得自己的空间思维特强大，不是么？结果维护起来简直持矢一样，各种业务逻辑跟各种数据模型跟 UI 混合起来，改个结构就要折腾半天到吐血。

直到 MV*出来了，告别各种 selector,不用费劲脑子去遍历 dom 结构，让数据驱动 UI,简直爽爆了。就算产品瞎几把乱改乱挪 UI，也不用担心哪个选择器又断了。

人家的框架目的本来就是为了不让 dom 参与运算，减少 UI 操作对编写业务逻辑的干扰。

emmmmm 用传统 DOM 思想写 MV* 应用就会出现楼主的问题
不是框架的问题，再多写一段时间就清醒了

“ jquery 能保证只修改这一个 dom，vue 还得再虚拟 dom 里模拟一遍，还说不准谁比谁快呢”

@learnshare
然而好多人用 vue 的原因因为他要操作 dom，之所以不用 ng，因为他觉得不方便，而 vue 有地方可以方便加 jquery 操作 dom。

@dong3580 用 Angular/React/Vue 都不影响操作 DOM，只是操作的时机需要把控好

使用 jQuery 或以上三种库 /框架的原因无外乎以下几种：
1. 使用者更熟悉；
2. 听说不错（盲目上）；
3. 追求模块化、组件化；
4. 追求开发效率和质量。

技术难分优劣，只有是否符合需求。

@DOLLOR 正解

你要觉得链式结构跟一大堆 parent 很方便那也可以啊，vue 父子组件通信了解一下

各有特色哈，vue 重点在数据 数据的绑定，jquery 重点在界面 各种 dom 的操作

本来就不是万能的东西，你要想大量操作 dom 用 jQuery 也并没有问题。

你要说 PHP 是 Service Side Render 那是一点异议都没有。
你说 jQuery 比 React 的效率高，那也是一点异议都没有....

这个小老板技术还是勉强，单论前端或许只是 jq 工程师吧，既然 jq 那么好，那就继续用下去吧。

看了半天，难道楼主的 dom 和 state tree 是不一致的？

一路看下来，居然没开到那个一把梭？？

vue 大型项目你会很高兴的。
小 demo jq 撸起也十分带感。

楼主说的对（

正喝着水呢，看到这句

> 直接根据这个按钮的颜色就可以判断是否再参与计算

瞬间喷了出来

@gs139 啥叫模仿后端，这世界从一开始就没有前端后端，你写 native apps 的时候有这么分的么。当年互联网刚发展浏览器之间有兼容性问题，就出了一个叫前端的岗位专门对付这些问题。归根结底不还是软件开发

不过 vue 到底解决了啥问题

楼主的思维：一个项目参不参与计算，是由它的颜色决定的。
Vue 的思维：一个项目的颜色，是由它参不参与计算决定的。

@gs139
>如果界面到了大幅调整的程度，你确定 vue 不是重写？用 vue 重构的时间，jquery 都重写好几遍了。

有时真的不是。。。如果还是那些数据的话，用 vue 只要把界面重写下就行了，操作数据的逻辑部分不需要改。
而你那种直接在 dom 里操作数据的方式就不仅是界面，逻辑部分也要跟着改了。

web 前端开发的思路确实比较奇怪，明明有 js 对象接口，一定要自己用 selector 去查找，而 vue 同样是畸形思路的产物

现在大多数项目还是 jquery+vue 混用的.

遇到重 UI 的,jQuery 确实不可少