为什么 2019 年了我还在用 jQuery

阅读数:12086 2019 年 6 月 1 日 14:59

为什么2019年了我还在用jQuery

很多人提倡“只使用纯 JavaScript,根本不需要 jQuery”。好吧,很多东西确实是我不需要的,尽管它们可能都很好。我可能也不需要 jQuery,但它确实也很好。

有些文章试图告诉我们:去掉 jQuery 其实是很容易的。但这篇文章在开头却举了一个使用 jQuery 很好的理由:一行简单的 jQuery 代码取代 10 行 vanilla JS(纯原生 JavaScript)代码!

使用 jQuery 的优势

JavaScript API(特别是 DOM API)的很多东西都与我的审美观相去甚远,我这么说算客气的。el.insertAdjacentElement(‘afterend’, other) 固然没有问题,但如果写成 (el).after(other)() 函数,但它再怎样都比 DOM 提供的函数要好得多。

通常你是怎么获取一个元素的兄弟元素的?是 nextSibling 还是 nextElementSibling?它们有什么不一样吗?哪些浏览器支持它们?又或者不支持?为了记住这些,你需要记住或者去查阅 MDN,但如果使用了 jQuery,只需要调用 next() 或者 prev() 方法。

JavaScript API 提供的很多标准操作都很奇怪,我本来可以列出很多,不过上面提到的那篇文章已经列出了一大部分了。

你可能还需要一些辅助函数来完成一些常见的任务,同样,上述的文章也列出了很多这样的函数。而 jQuery 就包含了这些东西,省得你到处拷贝粘贴这类代码。

虽然现在浏览器兼容性问题不像以前那么严重,但仍然是个问题,特别是如果你无法接受“只要 85% 的用户能够使用就可以了”。另请参阅:为什么 Hello CSS 不使用 CSS 变量

是否必须选择 jQuery

那么你要一直使用 jQuery 吗?当然不是了。在项目里添加依赖意味着更大的复杂性和更大的文件体积。不过,jQuery 本身并不大。经过压缩的默认大小为 30K,如果不包含 AJAX 和其他不常用的东西大小只有 23K,如果使用 querySelector 替代 SizzleJS 就只剩下 17K。对于我来说,30K 或者经过优化的 17K 的 jQuery 已经能够满足大部分用途。

从 Bootstrap 移除 jQuery 的案例可以看出,使用纯 JavaScript 的代价是很大的:他们重写了辅助函数,去掉了对 IE 的支持(因为太难了),让 API 变得不兼容,总共花了一年半的时间。从结果来看,我不觉得它比之前好多少。

我明白他们为什么要那么做。人们希望将 Bootstrap 和 Vue.js 放在一起使用,而把 jQuery 和 Vue.js 放在一起又显得很奇怪。我也很赞成我们要避免“Web 膨胀”,但至少也要务实些。在项目里包含 17K 的 jQuery 真的有那么糟糕吗?相比 Medium 或纽约时报这些动不动就要加载上兆 JavaScript 的网站,一个 17K 的 jQuery 就那么让你难以承受吗?

当然,我们也有一些不使用 jQuery 的理由:比如你想要写一些会被别人重用的代码或者小函数。但即使是这样,也不至于要拼了老命避免使用 jQuery。什么东西都用 jQuery 来写不是个好主意,但完全不使用 jQuery 也不是。

我并没有只与 jQuery 为伍,但它的一些优点确实弥补了 JavaScript API 的不足。之前的那篇文章建议使用 bonzo $dom ,以及其他一些与 AJAX 有关的包,但它们当中大部分似乎已经停止维护了。另外,既然所有人都会使用 jQuery,那么除非非常有必要,否则为什么要用其他东西来替代它?

总结

一些读者可能会想:“那么其他框架呢,比如 Vue.js、React”?其实这篇文章的目的在于比较纯 JavaScript 和 jQuery,而不是要和读者讨论什么前端开发大法。

总的来说,使用纯 JavaScript 也是有理由的,比如我想要开发一个非常快的网站,使用最简单的代码,可以让尽可能多的人访问到。在我看来,服务器端生成的带有“渐进式增强”风格的 JavaScript 通常是最好的方式。这种开发方式速度快,而且容易,bug 更少。

那这是不是意味着 Web 框架就不是好东西了呢?当然不是了。没有什么东西是非黑即白的,它们一般都存在一系列的权衡(jQuery 当然也是)。

我认为,Web 是主要是用来浏览 document 的,而不是一个操作系统。尽管对于很多 Web APP 来说,使用 document 方式也可以很好的进行一些操作。

英文原文: https://arp242.net/jquery.html

网友热议

sgift: 面对只向用户展示文字的需求,我认为使用现代 js 框架的理由是:感觉使用 html 显示页面文本的方式太老土了,他们将文本打包在服务器上的中(它通常以 html 兼容的形式存在),然后他们将 JS 推送到浏览器,之后浏览器不得不解释 JS 之后才能得到 html,最后,我才看到了页面的文本信息。而且因为这种方式很慢,我们创造了“服务器端渲染”等技术。当我第一次阅读有关服务器端渲染的内容时,我不明白它是什么,是在服务器上生成了 html,并将其发送给客户端吗?新部分是什么?为什么人们将这种作为方式作为 web 的下一个救星? 这简直太疯狂了,我想知道什么时候会停止。

candu:这是在这些讨论中经常被遗忘的部分:它不应该是“SPA(Single Page App,单页应用)为所有东西”也不是“vanilla HTML / CSS / JS for everything”;相反,我们应该使用最合适的工具集。我曾经工作中做过静态网站,为此我通常更多地依赖于 vanilla HTML / CSS,并在此处推荐使用 JS。我还致力于重型应用,这种方法的局限性很快就会变得明显;在这些情况下,我使用可交互的组件框架,如 Vue 和 React。但也有介于两者之间的方法!对于中型复杂的站点或 APPs,我使用了 vanilla HTML / CSS / JS,以及一些额外的 Python / Makefile 管道来生成更多重复的部分。我还使用了混合方法,其中 vanilla HTML / CSS / JS 用于站点的更多静态部分,Vue 用于更动态的部分。您可以在完全 SPA 模式下使用 Vue 和“服务器端渲染”…但您也可以像以前一样在服务端生成 HTML,然后使用 Vue / jQuery / 渐进地增强它的一部分的功能。我之前也使用过像 Spring 这样的“不合时宜”的框架,仅仅因为是客户硬性要求。作为开发人员,我们有责任退后一步,评估手头的任务 / 团队 / 环境,并相应地选择工具。

andrei:AT&T 的网站帐户页面仅提供静态 HTML。 但它们是由 js 渲染的,我必须等待每次点击后查看加载情况。这是为什么?为什么这么多静态网站和博客都在其所有网页上使用 SPA 技术? 人们疯了吗? 如何花费 10 倍的钱和努力以获得更糟糕的结果?

Carpetsmoker:目前正在处理 SPA 应用程序无法与 FB 共享一起使用的情况,因为它会使用一组 META / Open Graph 标记。 所以现在我们回到渲染服务器上的一部分 HTML 来支持这一点。 在 JIRA 中,如果我在错误的字段中输入,它会向某个地方发布一个帖子并返回一个奇怪的 xml 页面而我丢失了我的工作。因此,当作者说顶部带有 js 的经典 HTML“更容易开发”时,我傻笑。如果是这样的话,开发人员就不会大量涌向 SPA 等。这些正是现在的趋势,因为它们更容易开发和维护。让我这样说吧,无论是作为 SPA 的开发者还是用户,我早就观察到 SPA 往往需要加载更多的资源,更加困难,更难使用。我不认为这是令人惊讶的,因为“维持状态”是伟大的,但也意味着一旦这种状态横向移动,你的应用程序也会横向移动。这是否描述了每个 SPA?不,这是否意味着每个模板应用程序都更好?不是。但平均 SPA 应用程序是否比普通模板应用程序更差?根据我的经验(虽然我缺乏经验数据)。我不认为流行度是一个很好的评判标准。 jQuery 显然不是开发 web 应用程序的最佳方式 - 这篇文章从来没有打算如此争论,只是为了争辩说它比我最近提倡过的很多 vanilla JS 更好 - 所以人们去“替代”缺乏 jQuery 问题的解决方案,但这并不意味着这些解决方案本身不会产生其他问题。我不知道开发 web apps 的最佳方式是什么,但我知道肯定不是当前的 SPA 框架。可能某种混合方法,或者尚未发明的完全不同的方法,同时,基于模板的方法更容易理解(可能出错率更小),并且可能是许多网站的最佳方法。

为什么2019年了我还在用jQuery

评论

发布
用户头像
看到这样的文章我忍不住感叹,来我们公司吧,比你在国内轻松赚威我66631280401
2019 年 06 月 02 日 11:48
回复
没有更多了