这是一个创建于 588 天前的主题，其中的信息可能已经有所发展或是发生改变。
关于 JQuery 和 Vue 代表的 MVVM 框架。
我本人是比较喜欢 JQuery ，感觉 Vue 让一切变得特别的复杂难操作，是我自己的问题，还是也有和我一样的想法。
如果你深度的使用过 JQuery ，和深度的使用过 Vue ，希望你能分享一下感受。
第 1 条附言 · 2023-04-13 22:24:15 +08:00
写一下我自己的看法
Vue 并不是 JQuery 的替代品，他们是两种完全不同的东西。
他们会一直同时存在。Vue 可以说是让前端更简单，更适合团队作战，因为 Vue 的本质就是一个后端的数据渲染器。把后端的数据映射到前端，把用户的数据映射到后端，但也只是渲染数据方便，仅此而已。
如果我们用 Vue 做一个 taobao.com ，那会发现，有很多效果有 Vue 太复杂了。Vue 总感觉就适合那种 后端 Admin 界面。
我最近做了一个系统 Admin 用回了 JQuery ，我感觉太自由了，我在数据列表界面做各种自定义交互工作，一下就好，没有任何限制，又看了目前主流的 PC 站点，都没有使用 MVVM 。所以怀疑前端科技树是不是被带歪了。
以上是我的偏见，我本人不是前端。
Vue 并不是 JQuery 的替代品，他们是两种完全不同的东西。
他们会一直同时存在。Vue 可以说是让前端更简单，更适合团队作战，因为 Vue 的本质就是一个后端的数据渲染器。把后端的数据映射到前端，把用户的数据映射到后端，但也只是渲染数据方便，仅此而已。
如果我们用 Vue 做一个 taobao.com ，那会发现，有很多效果有 Vue 太复杂了。Vue 总感觉就适合那种 后端 Admin 界面。
我最近做了一个系统 Admin 用回了 JQuery ，我感觉太自由了，我在数据列表界面做各种自定义交互工作，一下就好，没有任何限制，又看了目前主流的 PC 站点，都没有使用 MVVM 。所以怀疑前端科技树是不是被带歪了。
以上是我的偏见，我本人不是前端。
 |
1
leeraya 2023-04-13 17:30:53 +08:00
jq 操作 dom 方便，适合小团队 梭哈。
vue 组件化方便做工程 |
 |
2
euronx 2023-04-13 17:33:56 +08:00
页面复杂了之后 vue 就香多了
|
 |
3
poorAshenOne 2023-04-13 17:36:47 +08:00
一个较为复杂的表单.
用 jq 来写 和 用 mv* lib 来写,完全是 2 种体验~ |
 |
4
kujio 2023-04-13 17:38:25 +08:00
vue 引入了一套自己东西，新手只需要照着模板写就行不需要太多理解，
但对于熟系开发的人来说，这套东西增加了理解负担，在定制化程度高的业务中反而束手束脚。 |
 |
5
LeegoYih 2023-04-13 17:39:42 +08:00  1
用过 Next.js + React 后你会发现 Vue 其实还挺简单的，用 UI 框架复制粘贴就完事了
|
 |
6
ae86 2023-04-13 17:40:32 +08:00
我比较喜欢 react
|
 |
7
renmu 2023-04-13 17:42:12 +08:00 via Android
其实是你的思维没转过来，这两个的开发思路差别很大
|
 |
8
kop1989smurf 2023-04-13 17:42:25 +08:00 1
优势方向不同。
操作 DOM： 简单，直接，轻量化，自由度高。 代价就是逻辑与 UI 状态分不开，要自己维护 UI 的状态。 而每个人的编码水平不同，导致维护 UI 状态的逻辑不同，下限极低。新手容易有很多突破下限的操作。 双向绑定 /单项绑定： 规矩严格，通用性好，下限高，开发者不需要在逻辑中顾及 UI 。 代价是繁杂，庞大。 总体而言，其实 MVVM 库就是为了束缚前端人员的自由度用的，就像个老妈。 你小的时候，老妈可以帮你做很多你本没能力做的事情，但同时，你也受到老妈的束缚和抑制。 |
 |
9
tool2d 2023-04-13 17:42:29 +08:00
jq 有一种写代码的感觉。
vue 是魔改 html 语法，用最简洁的语法，做更多扩展的感觉。 我个人是偏好改代码的，但是大部分人，还是会喜欢改改 html 。 |
 |
10
makelove 2023-04-13 17:48:16 +08:00 9
就问一句：你写过复杂动态 app 吗？ 没有没什么好说的，别说 jquery 了，直接 vanilla js 都一样
如果写过，你用 jquery 怎样管理海量状态并动态反映到 DOM 上？ |
 |
11
zhengwenk 2023-04-13 17:48:59 +08:00
一旦页面交互的复杂度上去了，jq 就很难受
|
|
12
kop1989smurf 2023-04-13 17:50:08 +08:00
@makelove #10 能不能举个“界面复杂到必须用 MVVM 才能解决”的例子？市面上有的产品就行。
以我工作的经验来看，我还没遇到过说操作 DOM 完全捋不清的情况。 |
 |
13
vinsony 2023-04-13 17:50:12 +08:00
你多搞点复杂的需求就不会这么说了
|
|
14
makelove 2023-04-13 17:51:48 +08:00
另外，jquery 连真正的组件机制都没有，怎么写大型应用
|
 |
15
lete 2023-04-13 17:52:01 +08:00
(我因该没资格来回答楼主的问题，在这里分享一下自己的看法吧)
几年前简单的学过 jquery 的使用，大多时间因该是用 $.ajax 吧，vue 的话也缺了点，用 vue 写过小项目 我个人其实是很少使用框架或者库的，基本上自己需要什么功能就自己写一个(主打的就是一个轻量化)，实在是自己写不出来，或者是写这个很费时间(弊大于利)我就会选择使用框架或者库 首先，用 jquery 还不如用原生 js ，jQuery 能做的原生原生 js 也能行，jquery 主要的特点就是浏览器兼容性比较好，其它没啥好的，反正现在有很多工具可以把 js 或 css 转换成支持低浏览器的代码 vue 的话，我觉得最大的优势是，提升了开发体验，其它的没啥了 举个例子：比如以前需要绑定个点击事件 传统: 先获取 dom 原生，然后写监听事件，然后写监听事件的回调函数 vue: 直接在 dom 上写 @click 给个方法名就可以了(虽然传统 js 也可以写 onclikc) vue 的一些缺点: 需要花时间来学习，如果 vue 更新了可能还会有一些变动还得重新学，就像 vue2 和 vue3 ，v-if 和 v-for 的优先级，v-for 必须给个 key 什么的，不懂的可能还要花时间去看为什么需要 key ，然后就 diff 算法 总之学习成本还是比较高的吧，还有周边生态框架什么 router 这些，那以后要是用 react 的话又得新学一个框架，那我干嘛一开始不提升自己写原生 js 的能里，打牢基础呢？毕竟这些框架本来也是用原生 js 写的，基础好了，看源码都很轻松 以上是个人的一些观点，不代表所有人 |
|
16
lete 2023-04-13 17:55:53 +08:00 1
其实把，我觉得 vue 、react 就像是现代版的 php ，jsx 真的几乎 php 了我觉得，现在还出来了 SSR 更像 php 了有没有(手动滑稽)
|
 |
17
dw2693734d 2023-04-13 17:56:45 +08:00
react 好用点
|
 |
18
westoy 2023-04-13 17:58:47 +08:00
看场景的， 就算 jq 时代， 不也有用 backbone.js + 模板库的么
|
|
19
kop1989smurf 2023-04-13 18:00:19 +08:00 1
@lete #15 "用 jquery 还不如用原生 js" 这个主要是有个历史背景原因。
JQuery 活跃的年代是 200x 年，那时候 JS 的标准是 1999 年制定的。下一个 JS 版本诞生在 2009 年。相对好用的 ES5 更是一个 2015 年才诞生的标准。 所以你可以理解为 JS 原生的一些语法糖，是从 JQuery 中吸纳而来。 |
 |
20
wunonglin 2023-04-13 18:00:23 +08:00
完全不是一个能比较的东西拿来比？
|
 |
21
zenxds 2023-04-13 18:00:29 +08:00 2
我为啥感觉应该七八年前讨论这个问题才对
|
|
22
kop1989smurf 2023-04-13 18:03:26 +08:00
@wunonglin #20 为何不能比，操作 DOM 和 MVVM 是两种独立的设计模式，是竞争关系。
|
 |
23
bojackhorseman 2023-04-13 18:04:13 +08:00
here you come again, 这种帖子还真是长盛不衰啊🤣
|
|
24
lete 2023-04-13 18:04:56 +08:00
@kop1989smurf #19 学习了
|
 |
25
u823tg 2023-04-13 18:19:53 +08:00 2
个人以为还是 react 好点，vue 没有一次是不用去翻文档的，要记得东西太多
|
 |
26
huijiewei 2023-04-13 18:45:31 +08:00
|
 |
27
cloudzhou 2023-04-13 18:51:53 +08:00
这两个技术代差太大了，很难比较了，就像比较 Jsp 和 Spring Boot 哪个好一个
这是学习成本以及应对复杂度的问题，就像，是要手写 SQL 还是用 ORM |
|
28
kop1989smurf 2023-04-13 18:52:26 +08:00
@huijiewei #26 光扣帽子对讨论没有任何价值。
|
 |
29
superedlimited 2023-04-13 18:58:57 +08:00 via iPhone
@makelove 人家是“深入”写过 jq 的噢，一个一个赋值就好了😂
|
|
30
superedlimited 2023-04-13 19:02:20 +08:00 via iPhone
@cloudzhou 这还真不是 sql 和 orm 的关系，sql 至少还是 declarative🥲
|
|
31
wunonglin 2023-04-13 19:11:27 +08:00
@kop1989smurf #22 解决的问题都不一样。何来比较？
|
 |
32
cmdOptionKana 2023-04-13 19:15:36 +08:00 via Android
具体问题具体分析，比如 V 站的前端，与 jq 相比，用 vue 之类的没有明显优势。
|
 |
34
snoopyhai 2023-04-13 19:22:58 +08:00
从 jquery 到 vue ，需要转换思路，等思路转变过来后，才会发现一切都是那么的舒服。
当思路从关注 dom 变成关注 data 后，你也可以把这种思路用在 jquery 上。 |
 |
35
l4ever 2023-04-13 19:25:06 +08:00
jQuery 开发人员岗位名称: JQ api 调用工程师
|
 |
36
Jxnujason 2023-04-13 19:29:10 +08:00 via Android
等你见到三万行的 jq 代码你就不会这么说了，改吐血了
|
 |
37
danhua 2023-04-13 19:29:42 +08:00
简单的 jq ，上了复杂度后 vue 好点。
|
|
38
u823tg 2023-04-13 19:32:22 +08:00
@jqtmviyu #33 我写后端的，偶尔写下，单纯比的是那两个框架 ， 不太了解前端，rtkq 是啥由这两两个框架引申出去的一系列工具集插件之类的东西？
|
 |
39
giter 2023-04-13 19:37:31 +08:00
> 感觉 Vue 让一切变得特别的复杂难操作
楼主的问题。 |
|
40
cmdOptionKana 2023-04-13 19:43:59 +08:00
> 感觉 Vue 让一切变得特别的复杂难操作
脱离实际场景, 这句话只能争论不休. 有的场景适合数据驱动, 有的场景比较简单, 小刀与砍骨刀, 各有不同的适用场景. |
|
41
superedlimited 2023-04-13 19:50:16 +08:00 via iPhone 2
建议 op 去推特上和 youyuxi 吵一架，🦑很喜欢在推特上 battle 的。
|
 |
42
ruoxie 2023-04-13 19:56:49 +08:00 via iPhone
19 年之前用了 4 年 JQ ，包括大学的话应该有 6 年。现在不上 ts 的项目我都不想碰
|
 |
43
Huelse 2023-04-13 20:03:33 +08:00 1
一般提出这种问题的要么是刚接触 vue/react ，要么是水贴🤔
|
 |
45
putaozhenhaochi 2023-04-13 20:30:34 +08:00 via Android
Vue 和 React 说好的就是 UI 库呢咋搞那么多概念出来。
|
|
46
huijiewei 2023-04-13 20:44:27 +08:00
@kop1989smurf 大言不惭才是，亮出你 jquery 代码。2023 年了。还吹 jquery 有什么意思，我还说 jquery 没意义，我都是刻硬盘的，SSD 不好刻。我现在改用纸带打孔了
|
 |
47
lybcyd 2023-04-13 20:52:40 +08:00
@kop1989smurf 完全捋不清倒不至于，但是比较依赖 js 数据驱动的动态页面，vue 的开发体验要强很多。jquery 需要自己手动做的操作太多了。
|
 |
48
tulongtou 2023-04-13 21:07:09 +08:00
10 年前开始用 jq ，5 年前开始用 vue 。jq 和 dom 绑定太深了，vue 可以专注于数据和逻辑。
|
 |
49
charlie21 2023-04-13 21:40:59 +08:00 via Android
两个框架对问题的抽象方式是不同的
未来可能有新的框架，伴随着新的问题抽象方式，到时候 jquery vue react 全得扔。仅此而已 |
 |
50
awolf 2023-04-13 22:13:20 +08:00
vue 转小程序方便。jquery 可转不了
|
 |
51
wdssmq 2023-04-13 22:13:26 +08:00
Alpine.js
https://alpinejs.dev/ |
 |
52
dingyaguang117 2023-04-13 22:16:25 +08:00
VUE 写组件比 jQuery 可简单多了
|
 |
53
webcape233 2023-04-13 22:24:03 +08:00 via iPhone
不是一个层面东西啊
|
 |
54
ZuiShuaiDe 2023-04-13 22:25:32 +08:00
如果是切图的前端 jquery 就够了，在 15 年的时候用 jq 写过类似 angularjs 的框架
|
 |
55
HugoChao 2023-04-13 22:38:45 +08:00
最大的区别是，随着时代的变迁，前端已经不怎么需要操纵 Dom 了，所以 jq 逐渐没什么团队用了
不过如果穿梭回十年前，你一定会觉得 jq 的语法特别爽，特别简洁好用的感觉 |
 |
56
jiayouzl 2023-04-13 22:50:11 +08:00
我刚写了个项目,我一个人做的,一个简单的在线商城,想起要前后端分离我就不太想做,写 vue3 我觉得还行,主要还是调试接口太麻烦了,后来还是决定用前后端不分离做开发周期短了很多.主要也不复杂分不分离都一样.特别很多项目我一个人能完成前后端还是首选开发周期短的方法.
|
 |
57
kingjpa 2023-04-13 22:59:07 +08:00
这种东西很容易先入为主。
你先接触 jquery 并熟练使用， 那肯定会觉得 vue 用起来很不顺手 你先接触 vue ,那会觉得 jquery 反人类啰里啰唆。 这个东西也并不存在谁就一定比谁好，也不存在哪个项目必须用 vue 或 jquery 才能实现，如果是个人做项目，一定是 jquery 效率更高，团队协作上，工程化组件化就是必不可少的东西了 |
 |
58
DOLLOR 2023-04-13 23:01:49 +08:00 2
我眼里的 jq 项目：
$().before().after().parents().children().find().eq().filter().append(a+'\''+b+'\''+c) 每次维护的时候都想骂人：你特么到底 append 了啥玩意到哪里？ |
 |
59
shui14 2023-04-13 23:03:55 +08:00 2
jquery 同样可以做一层抽象的，以前有 backbone/ember ，就是 zepto 加传统 mvc ，高度自定义。
vue 其实很尴尬，它的 mvvm ，让两头别扭，无法完全像 react 一样纯函数式，注意我说的是编程范式，不是指写的像函数式。react 因为铁了心走这条路，既不愿意加上 vue 这种双向绑定也不愿意向语言特性妥协，现如今只能在语言机制上造轮子，比如当下的服务端组件 /并发模式，这些本应该是基础工具是浏览器和 js 解释器及应用服务器直接提供的；上古问题，因为它自己解决不了局部副作用，就搞出一个状态管理，然后这个状态管理这几年随着应用场景变化，一次又一次解决不了问题，就推出一个又一个新轮子，好在社区创意十足都能圆过来，什么时候玩脱了，也不知道。react 优势人才多可控。 为什么，ng 可以不要状态管理？好像没有人问过这个问题。 vue 原本是个轻量版的 ng ，它的最大优势就是，可以写着 vue 的代码，用 ng 的思想来体现架构。对，我想说的就是，把 ng 的 ioc 那一套，ng 太重，zone/rx 等等这些理念单拿出来一个语言都非常复杂，而硬要用 js 这种半残废语言来实现它们，又强加于架构之上；它们可以在 vue 这里作为可选项，提供一种选择，复杂应用也可以无缝接入，但它自己把自己玩瘸了， 后面浏览器迭代越来越靠近 cs 的老路，回头看现在，就跟十年前看 flash 一样笑话，as 至少还能秒杀 canvas ，webgl 也是残废，还有苹果 es300 直接不支持，今年的 webgpu 本该在好几年前就该妥协达成一致的。 |
 |
60
Imindzzz 2023-04-13 23:09:20 +08:00
声明式 ui 和 命令式 ui 可以了解一下
|
 |
61
Leviathann 2023-04-13 23:09:47 +08:00
主流的 PC 站点，都没有使用 MVVM
不清楚 react 算不算 反正 fb twitter ig 都用的 react ， office 的网页端、飞书也用了 react |
 |
62
QlanQ 2023-04-13 23:24:24 +08:00
能说出这样话的人，估计水贴，或者就没写过几行代码吧
|
|
63
QlanQ 2023-04-13 23:27:56 +08:00
jquery 直接操作 dom ，你切换一个按钮，你需要写多少行 jquery ，你要记录状态，根据状态切换不同 dom 的显示隐藏
列表按钮多了，给 dom 的 id 命名都要带好多信息才行 |
 |
64
vruzo 2023-04-13 23:30:55 +08:00
所识所见，亦是所束所缚
|
 |
65
DrakeXiang 2023-04-13 23:46:25 +08:00
16 年转行后第一份工作写了一年 jq ，当时比较菜，spa 刚刚兴起，但是小作坊还在用 jq ，而且都不会模块化，设计和老板说的效果还是 spa 的类型，各种同页面切换状态和表格动态编辑，最后一个页面有 3k+行，里面大量的字符串拼接，然后各种切换隐藏显示的逻辑和更新数据的方法遍布各处，现在想起来都觉得不寒而栗。
从 17 年到现在我再没写过一行 jq ，甚至碰到代码里面有可能需要用到 ref 的方式都本能地反感，因为我总觉得“数据驱动”就不应该再去手动更新 dom ，当然如果要做定制动效那可能还是得碰 dom ，不过我碰到的动效都不太复杂，基本就是 css 或者 js 循环更新数据就 ok 了，甚至动画库都没用过。 你说的 admin 在我看来正是 vue/react 这类框架的 sweet spot：大量数据规律渲染，格式相对统一，没有多少动效，业务逻辑可能比较复杂，这些都是“数据驱动”占优势的方面，我完全看不到 jq 能有什么“自由”的地方，正如我之前提到的，显示、隐藏，响应式数据更新或者双向绑定，数据渲染，这些你用 jq 做起来体验能好？除非你做了高度封装，但要么最后使用还是需要显式调用或者封装成和 vue/react 一样的自动更新，那还跟 jq 有什么关系。。 |
 |
66
ashong 2023-04-13 23:59:58 +08:00 via iPhone
jquery 的优点缺点都是灵活，后期维护拓展不方便
|
 |
67
lujiaosama 2023-04-14 00:08:32 +08:00
看来是没参与过什么大型复杂的工程. 比如一个大型复杂动态表单,根据配置动态生成,复杂到需要拆分成 N 个表单,表单项之间的联动校验非常复杂, 拆分之后还需要跨组件通信. 用 VUE 硬干单文件都几千行了, 用 JQ 手工拧麻花是准备写多少?拉屎倒是爽, 维护火葬场?
|
 |
68
pocarisweat 2023-04-14 00:34:01 +08:00
这楼里好像又没有提到 Stimulus.js 的。
我的评价是，jQuery 的流行有其历史背景，它有些 API 很方便，但更重要的原因是它磨平了很多兼容性问题。但今天 Web 的兼容性难度已经远远没有那么高了，需要的场合用原生 DOM API 就可以搞定。 如果需要一些复杂的绑定关系，但仍不想脱离 DOM ，可以用 Stimulus ，这个库有些冷门，但我认为很好地填补了原生 JS 和 React/Vue/Angular 这类稍重的前端框架之间的空缺。 只有当你需要更复杂的对应关系，以至于 DOM 对你而言是负担，或者项目达到单页应用这样的规模时，才应该考虑 Vue/React/Angular. |
 |
69
icyalala 2023-04-14 00:49:29 +08:00
 老夫写代码就是一把梭 /拿起键盘就是干 感觉已经是历史了 |
 |
70
stabc 2023-04-14 00:58:24 +08:00 1
|
|
71
stabc 2023-04-14 01:04:04 +08:00
个人感觉，如果是团队协作的话，首推 vue/react 。因为天然模块化，非常适合分工。
个人项目，感觉还是 jquery 爽，用 jquery 真的就像说话一样，不需要考虑太多，需要什么写什么。而 react 总要“迁就”它的一些限制、规则、局限等等。 至于说“用 jquery 不如直接用 js”，你把 jquery 当做 js 的语法糖不就好了。 |
 |
72
tairan2006 2023-04-14 08:49:23 +08:00
jquery 连个双向映射都没有，你写大点的项目就累死
|
 |
73
ikaros 2023-04-14 09:16:46 +08:00
我现在还是 jQuery 一把梭，不过仅限于个人娱乐项目 =。=
|
 |
74
JKeita 2023-04-14 09:18:39 +08:00
两个没啥可比性吧，一个偏工具，一个偏框架
|
 |
75
magichacker 2023-04-14 09:21:31 +08:00
@kop1989smurf web 版 PS ，web 版 Adobe 各种全家桶，各种 web 版图形化编辑系统。
|
 |
76
Felldeadbird 2023-04-14 09:27:18 +08:00 3
反正两个不是同一个东西。
JQ 属于上一个前端版本的开发思想，后端大包大揽。 VUE 则是 API 时代的分工工具。 写 JQ 时，会渴望拥有类似 VUE 的做法，因为不用担心意大利面条 。写 VUE 时，却希望可以做到 JQ 那种随用随爽。。 |
 |
77
Seanfuck 2023-04-14 09:30:54 +08:00
数据复杂点层级多点，vue 自动渲染就不行了要手动强制渲染，不知道改进了没
|
 |
79
yunyuyuan 2023-04-14 09:38:39 +08:00
经典流量密码贴。
首先你说"Vue 的本质就是一个后端的数据渲染器"了，可以看出你没怎么用过 vue ，对自己不熟悉的领域下定论，真有你的！ 我的建议：用 jq 挺好的，jq 发展这么多年，稳定性和兼容性不用担心，建议继续用下去，专门学习 vue 成本太高不值得。 |
|
80
Seanfuck 2023-04-14 09:45:52 +08:00
@tairan2006 这个双向映射，用 vue 渲染一个列表，用 jq 删掉一行，vue 会自动删除数据里对应的行吗，不熟
|
 |
81
vivipure 2023-04-14 09:46:24 +08:00
使用 Jquery 手动更改 DOM, 维护时麻烦的要死。现代 Web 应用复杂度也越来越高,程序既要管理应用状态，又要维护 DOM 的状态，开发和维护的成本和效率是很重要的。Jq 能做，但是数据驱动的框架可以做的更好
|
 |
82
wangtian2020 2023-04-14 09:57:26 +08:00
为什么要操作 dom 呢，操作数据可太简单了
|
 |
83
qianyeyixi 2023-04-14 09:58:26 +08:00
感觉有点像是钓鱼的味道，不同时代人们对于开发模式的追求不一样。 远古时代 jq 就是神 ，现在已经没有前端需要处理 ie 系列的兼容性问题了， 应该去了解一下处理兼容性问题多麻烦。vue 是新时代 需求的产物 ， 都是希望前端能做更多的事情，越来越复杂的。
|
 |
84
wangxin13g 2023-04-14 10:04:50 +08:00
工程化 工程化 工程化
重要的问题说三遍 老头乐不是不能开，但是不会有人想开老头乐上高速吧？ |
|
85
cmdOptionKana 2023-04-14 10:07:20 +08:00
@qianyeyixi 其实楼主说的有一定道理, vue 虽然好, 但大多数网站的复杂度根本体现不出 vue 的优势, 用 jq 或 vue 差别并不大, 比如 V 站就是一个例子.
|
|
86
cmdOptionKana 2023-04-14 10:10:00 +08:00
@wangxin13g 不会有人想开老头乐上高速, 但大多数网站都不是高速路, 比如你正在使用的这个网站, 就是开的老头乐(jq 或原生)
|
 |
87
kylebing 2023-04-14 10:11:04 +08:00
工程量的区别。
- jQuary 适合量小的，但无法统筹管理内容。 - Vue 大小都适用，好管理。大了用 npm 项目模式，小了可以直接引入 vue.js 使用 |
|
88
kylebing 2023-04-14 10:16:25 +08:00
可以这么说，vue 的项目主干更稳固，添加东西比较方便。
我有个项目最初是 jQuery + vue.js 的，最后改成了 Vue3 的，管理更方便。 html: https://github.com/KyleBing/diary-html vue3: https://github.com/KyleBing/diary |
 |
89
aogu555 2023-04-14 10:16:59 +08:00 8
后端仔总是喜欢在一知半解的情况下对着前端大放厥词，并且坚定认为前端应该一成不变且必须让后端仔能看懂(─.─||)
|
|
90
wangxin13g 2023-04-14 10:26:14 +08:00
@cmdOptionKana 如果 v2e 有朝一日要扩大规模到 50 人的团队 你觉得还会坚持用 jq 么
|
 |
91
YasinChan 2023-04-14 10:33:04 +08:00
其实可以认为就是“框架”与“库”的区别，vue 作为框架，其开发者已经将基础结构和规则制定好，我们在使用的时候根据规则使用，可以显著的减少心智负担和提高开发效率和代码可重用性。jQuery 作为一个库，其实就是原生 js 的语法糖，优点是可以更轻松的使用 js API ，当然自由度更高些，但如果要开发较复杂的业务，工程性的东西就需要自己一点点的配置，成本反而会更高了。我所理解的现在 vue react 等框架用的越来越多，正是因为现在的前端业务越来越复杂，这类框架可以显著的提高工作效率，一个团队在框架的制约下代码质量也能更加统一，更方便的团队管理。
|
 |
92
libook 2023-04-14 10:33:20 +08:00
首先，都是工具，工具是为需求服务的，杀鸡就用杀鸡刀，杀牛就用杀牛刀，拧螺丝就用螺丝刀；任何不匹配需求的工具，最终都会让工作变困难。
jQuery 的设计目标主要是方便进行 DOM 操作，只开发一个呈现内容并具备简单交互的页面，搞定 Mvvm 框架代码结构的时间都够用 jQuery 写完页面了。 Vue 的设计目标主要是让开发者仅描述业务，不用亲自操作 DOM ，涉及到大量数据相关的交互，并需要组件化重用的，拿 jQuery 来写，重复性工作就会很多。 另外，我真心建议通篇读一下 MDN 上 DOM API 的文档，最终你会发现，十年间新出的 DOM API 已经几乎可以替代 jQuery 的 99%的功能了，用原生代码写一个页面，也可以像使用 jQuery 一样方便了。 |
|
93
cmdOptionKana 2023-04-14 10:33:47 +08:00
@wangxin13g 还用 jq, 50 人的团队没必要全部用在一个地方, 就 V 站这个前端, 两三人完全够了, 其他人干别的事情去.
|
|
95
kop1989smurf 2023-04-14 10:46:44 +08:00
@wangxin13g #90 如果有明确的代码审核以及设计指引，其实是可以的。只不过没必要。
比如最简单的，保证每个事件都是解耦的 function ，不要用全局变量等等。 其实框架是通过既定语法与封装强迫你做了这件事而已。你不这么做“编译”不过。 而且框架其实也是需要程序设计指引的，否则一个 js/jsx 梭一整个应用，框架用与不用效果也差不多。 btw：真的会有 50 人团队的、高耦合度的前端项目么？ |
 |
96
aikilan 2023-04-14 10:52:14 +08:00
月经贴了，一个搞技术的应该能够分辨自己在什么场景下应该选用什么技术栈，老扯来扯去的无聊的紧。行了了，鱼你有了
|
 |
97
xiaojun1994 2023-04-14 11:17:21 +08:00
你说的对
|
 |
98
zjsxwc 2023-04-14 11:19:57 +08:00
搞对 dom 操作要求高的项目还是得用 jquery ，
比如这个用 jquery 1000 行不到的代码就实现了富文本编辑器。 https://www.jqueryscript.net/demo/Rich-Text-Editor-jQuery-RichText/ https://www.jqueryscript.net/demo/Rich-Text-Editor-jQuery-RichText/jquery.richtext.js |
 |
99
theohateonion 2023-04-14 11:54:29 +08:00
UI 最适合的描述方式永远是类 MVVM ，以组件的方式去描述。jQuery 做大项目一个是组件抽象不好做，不方便团队管理。一个是 dom 修改太混乱，dom 修改和实际的 dom 结构分开，几轮 feature 迭代，改到后面你可能自己都写晕了。
小产品或者小 project ，那无所谓啦，怎样都能实现。 |
 |
100
Rrrrrr 2023-04-14 11:55:20 +08:00
react vue 也能操作 dom ，这并不是比较的点。只能说 Jq 只是工具库而已
|
Select Language