不使用jQuery的一些经验技术原因是什么？

Question

上下文: 我对前端开发人员的数量感到震惊,他们整天都在破解HTML,Javascript和CSS,忽略 jQuery(或其他等效的帮助程序框架)之类的工具并拒绝使用它们.我不是在谈论JavaScript专家,我每天都在谈论战壕中的乔生产开发人员.我得到了许多更多的借口或个人观点的论据,我认为这些论点没有任何技术价值,我想确保我没有遗漏一些东西.

问题: 不使用jQuery有哪些经验技术原因？

我不是在寻找宗教或教条的论点或主观意见"就像其他一些框架更好",考虑jQuery是问题中所有可比框架的稻草人.

Answer 1

2015年更新:

在2011年的答案中,我谈论的是像jQuery,YUI或Prototype这样的库.今天在2015年,推理仍适用于Angular,React或Ember等框架.在这4年中,技术取得了巨大的进步,尽管我看到对React或Angular的偏见远远低于我对jQuery或YUI的看法,但同样的想法 - 尽管程度较小 - 仍然存在于今天.

2016年更新:

我强烈推荐几天前发表的一篇文章:

• 为什么选择jQuery？由Michael S. Mikowski中,作者单页Web应用程序的书

那篇文章基本上是对这个问题非常详细的回答.如果我在写下面的答案时可以使用它 - 我肯定会引用它.

原始答案:

我将回答关于jQuery的问题,但这些是我听过的反对使用YUI,Prototype,Dojo,Ext和其他几个人的论点.我听到的主要论点:

1. 文件大小,在jQuery 3.2.1的情况下实际上是84.6 KB - 可能比一般网站上的徽标小,并且可以从谷歌的CDN提供,这可能已经在大多数访问者的缓存中.由于使用jQuery总是意味着您自己的JavaScript文件的文件较小,它实际上意味着更小的下载,即使尚未在浏览器缓存中.

2. 速度 - 编写纯JavaScript可能会更快,但编写可移植 JavaScript似乎对大多数人来说是不可能的.一个速度更快但不适用于每个流行浏览器的网站在现实世界中毫无用处.除了jQuery使用一些非常重的优化实际上非常快,并且每次发布都会变得更快,所以除了琐碎的例子之外,用手写更快的代码实际上并不那么容易.(*)

3. "知识产权" - 一家公司害怕使用其他人的代码 - 而事实上jQuery是开源和自由软件,从你奶奶的博客到亚马逊,从Twitter到美国银行,从谷歌到微软都可以使用 - 如果可以的话使用它然后任何公司都可以使用它.

4. 我不记得听到任何其他认真使用的论点.

(*)这是一个简单的例子:getElementById('someid')与jQuery('#someid')

是否更快地使用getElementById？是.当然,当Blackberry 4.6返回不再存在于文档中的节点时,每个人总是检查parentNode,对吧？jQuery呢.每个人都处理IE和Opera按名称而不是ID返回项目的情况,对吧？jQuery呢.如果你不这样做,那么你的代码是不可移植的,并且你会引入一些很难找到的细微错误.getElementById是人们可能找到的最简单的例子 - 甚至不让我开始关注事件和AJAX以及DOM ......

更新:

实际上有第四个结果,询问为什么有人不想使用jQuery.我忘了把它放在这个清单上,因为它不是一个真正的答案,而是缺乏任何答案.我昨天得到的评论提醒了我.这不是添加到列表中的"技术原因",但可能是有趣的,实际上可能是最常见的反应.

我个人怀疑所有这些反应的主要根本原因是,我认为这是计算机科学取得进步的最大障碍:"我不想使用它,因为我从未这样做,因此它必须不那么重要."

它曾经是对优化汇编程序,编译器,结构化编程,更高级语言,垃圾收集,面向对象编程,闭包或几乎我们现在认为理所当然的所有事情的反应 - 现在它是AJAX库.也许有一天没有人会记得我们曾经在应用程序级别上手动与原始DOM API进行交互,就像现在没有人记得我们曾经曾经使用过原始的,未经修饰的,不可理解的十六进制数字来编写程序.

Answer 2

jQuery以DOM为中心的范例表达了所有内容,这可能会产生误导,并且不需要在应用程序模式中表达任何内容.

许多开发人员最终将这些以DOM为中心的模式编程到一个角落,并最终意识到他们没有创建任何可扩展或可重用的东西.

Rebecca Murphey对jQuery中自己切换到Dojo有很好的描述- 博客文章更多的是关于为什么不是 jQuery与Dojo的原因.

Answer 3

不使用框架的一个原因 - 这是一个极端的边缘案例 - 是在为另一个网站(例如横幅)编写可嵌入代码时.任意插入一些复杂的库或其他将污染命名空间并可能破坏其他人的网站.并不是说我不会把它放过一些广告商尝试,无论如何,池塘吮吸渣滓,但我离题...

当一个框架已经存在且同样有能力时,我不赞成添加框架.我经常看到它,这是我的宠物仇恨,我认为这是毫无根据的臃肿.这完全是另一个问题.

除此之外,我无法想到一个不合理的理由.

Answer 4

filesize - 但实际上,除此之外,它是跨平台javascript和浏览器差异的绝对神派.你必须有一些很好的理由不要在你的工具包中使用它(或者是一个原教旨主义的开发人员白痴).

Answer 5

• 他们无法证明文件大小的合理性(即使它可能比不使用提供的抽象的脚本少).
• 他们不想依赖第三方工具.
• 他们的业务不希望运行任何库(无论出于何种原因).
• 他们的业务不希望运行任何不是由员工编写的JavaScript代码.

Answer 6

• 学习:实际编码所有内容,并了解更多信息.(而不是使用预编码的东西)
• 大小: jQuery有很多你可能不需要的功能,为什么要让用户下载如此多的代码,如果它不会被使用？
• 替代方案:此时,还有数十个功能更强大,结构良好的Web框架.
• 灵活性:虽然jQuery非常灵活,但您可能需要它不提供的功能.