随着各种前端 MVVM， MVC 框架的流行， jQuery， zepto.js 等传统 JS 库是否有走向边缘的趋势？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 2999 天前的主题，其中的信息可能已经有所发展或是发生改变。

前端时间不是有一篇文章叫做《在 2016 年学 JavaScript 是一种什么样的体验？》，虽然这篇文章更多的是从娱乐的角度描写，部分细节过于夸张，但是也确实有很多人说过：用 jQuery 来实现 webapp 容易导致代码量增大，且不优雅，页面的内容，状态控制很麻烦，性能低下， html 和 jq 代码耦合性变大。所以，随着各种前端 MVVM ， MVC 框架的流行， jQuery 等传统 JS 库是否有走向边缘的趋势？（这里所指的走向边缘，也可以理解为一些非常简单的网页功能或者特效用 jq ，稍微大一点的仍然会选择前端 MVVM 或者前端 MVC 框架）

25 条回复 • 2016-10-11 12:51:20 +08:00

murmur

2016-10-11 07:57:38 +08:00

jQuery 是非常优秀的库，有些简单的需求就是 jQuery 最方便，不是所有网站都是单页面程序，不是所有的人都做移动开发，那种信息展示类的，一个模板套内容再来点动画交互要什么 MVVM

举个最简单的例子，一个选项卡，用 jQ 代码几行在纸上都能写出来，如果你用 reactive 的风格怎么写？要求很简单，实现选项卡切换逻辑，选项卡每个样式可以自定，选项卡的内容自定，需要组件(工具)化

checkout

2016-10-11 07:58:19 +08:00

webapp 不适合 jq ， webpage 普通交互还是 jq 简单

murmur

2016-10-11 07:59:51 +08:00

用 jQuery 来实现 webapp 容易导致代码量增大
这句话是我见过最不要脸了， jq minify 了才多少字节，还附送一个超牛逼的 ajax ，你用的 fetch 和 axios 哪个不比这个大，而且大家推崇的新 fetch 还在开倒车，都不允许 json params ，必须自己拼成 url
然后再看看你 ng2 ， react 打出来的 bundle 多大一个，也就 vue1 有一点发言权，而且 jQ 兼容了 ie6-8 ，你不需要兼容 IE 再考虑这些新鲜玩意
ps:ng2 居然是 ie7 兼容？他所有的双向绑定都是编译实现么

zlawliet

2016-10-11 08:07:54 +08:00 via iPhone

我觉得没有 jquery 我就没法写前端，我估计很多人也已经习惯了，而且， mvvm 跟 jquery 有啥关系？ mvc 就是集成的它啊

old9

2016-10-11 08:16:35 +08:00

ng2 不是 IE9+ 么？

murmur

2016-10-11 08:22:54 +08:00

@old9 看错了，那个表的 win7 我看成 ie7 了

readonly

2016-10-11 08:38:30 +08:00 via iPhone

@murmur 代码量增大，指的是业务代码。 webapp 之所以代码多，都是用户体验和人性化搞的，光是一个刷新逻辑都得费脑: 没有更多了~ 真的没有更多了~ 我保证没有更多了

murmur

2016-10-11 08:43:19 +08:00

@readonly 业务代码多比的上企业应用逻辑多么，企业应用这种大量表单填写、取值赋值、交互计算，才是上 mvvm 的好地方，问题是很多企业应用要兼容 IE8-，这就很蛋疼了
互联网应用？用户体验？人性化？呵呵，举个例子(带有胡吹的)，我只想要一个天气预报，这本来应该是浏览器导航页或者 widget 里的小功能，结果你给了我一个天气预报+跑步社区+今日头条+app 推广，业务逻辑能不多么

tonghuashuai

2016-10-11 08:53:04 +08:00 via iPhone

jQuery 和 MVVM 不是一类东西啊，没多少竞争关系

Xrong

2016-10-11 09:20:56 +08:00

简单的页面 jq 就好了，接手起来也方便

ChefIsAwesome

2016-10-11 09:24:17 +08:00

有个毛关系，问这种问题简直莫名其妙。 high chart 很流行， jquery 是不是因为它走向边缘了？ react 很流行， high chart 是不是走向边缘了？

clino

2016-10-11 09:29:22 +08:00

两个配合一起用啊

ianva

2016-10-11 10:41:04 +08:00

是两种选择，是重业务逻辑还是页面效果，
jQuery 就是 DOM 接口的改良版，如果单了页面的效果自然 jQuery 更合适，一旦涉及了业务逻辑，就会面临着业务逻辑与 DOM 操作的逻辑混合，随着规模的变大就越来越难维护

而对于需要大量修改页面效果的需求来说， MVVM 或者 react 之类都需要考虑框架自身对于组件生命周期的设计，需要操作 DOM 的地方会变的别扭起来，比如 angular 需要考虑 compile 和 link 两个阶段， react 要考虑一系列的生命周期，还有虚拟 DOM 的处理，所以相对来说复杂度会提升

当然除了上面两个问题外我们还要考虑到项目的其他因素比如项目的规模

如果项目够规模，我们还要考虑到一个问题就是模块化和组件化的能力，还要考虑到业务逻辑的需求变更，这个时候 mvvm 或 react 比 jQuery 会更合适，组件化复用能力和维护性上的提升是无可比拟的。

如果只是简单的页面，自然不需要牛刀了，但这样的项目确实让人提不起胃口

cheetah

2016-10-11 10:54:13 +08:00

我认为 jQuery 走向边缘化是必然的，
一方面， jQuery 从根本上只是提供了跨浏览器的 DOM 、事件、 Ajax 等的封装，而随着浏览器对标准的支持越来越好，这些都可以直接用原生的 `document.querySelectorAll` `addEventListener` `fetch` 等代替
另一方面，在 React 这种提倡声明式(declarative)库中，是希望避免直接的 DOM 操作的（命令式），写下来你会发现真的没有需要用到 jQuery 的地方

murmur

2016-10-11 10:56:08 +08:00

@cheetah ie8 不死 jq 不倒源生还没有 remove 吧只有 parentNode.removeChild