与仅使用JavaScript相比,仅使用Javascript有什么优势?

我对JavaScript和JQuery编码的经验有限。我已经在HTML页面中添加了每个代码的片段和片段,但是我主要使用其他语言对服务器端的东西进行了编码。我注意到虽然理论上您可以使用两种方法中的任何一种来做相同的事情(当然,您甚至可以在同一个项目中混合使用它们),但似乎总是有从一开始就始终使用JQuery的趋势。没什么,项目需求是什么。

所以我只是想知道,不使用仅JQuery而是仅使用普通的旧JavaScript有什么准时的好处吗?

我知道这看起来像是非常规的吗?问题,因为可以说“没有确定的答案”或“可以永远争论不休”,但我实际上希望准时回答,例如“您可以用一种方法做到这一点,而您不能这样做与另一个”。


根据scrwtp的评论,我并不是仅指DOM处理部分。我的问题是:JQuery是一个库。对于Javascript。与该库相对于其他语言的其他库相比,与该库相对,我感到奇怪的是,在JQyery的情况下,它似乎被设计为能够专门使用它,而无需直接接触Javascript。这与Hibernate和SQL相对,尽管库(或框架,在这种情况下,但我认为类推仍然适用)在很多方面都可以使用,但使用SQL时仍然可以使用SQL ,至少对于某些边缘情况。但是,在JQuery和Javascript情况下,您可以仅使用JQuery来处理Javascript(或者至少在我看来就是这样)。


根据Stargazer712的评论:是的,我同意你的意见,这里的问题是,正如你所说的那样,“仅取决于你将如何使用JavaScript”。那就是我真正想问的,但是我做了一些不好的表述。这是另一个比喻:Spring Expression Language。这是一个Java库。如果没有Java,就无法使用它,它基于Java,并且贯穿此,您仍然可以使用Java。但是实际上,您可以做的是将该库添加到Java项目中,然后使用Spring EL的表达式语言编写所有代码,这实际上使您的代码根本不类似于Java,甚至发生了范式转换(例如,您不再拥有使用此类型时强类型强制执行)。虽然我确实知道JQuery只是一个JS库,但在我看来,它实际上与Spring EL对于Java具有相同的效果,即您只能在整个项目中使用它的API,并避免使用JavaScript的API。而且我想知道这是否是一件好事,这可能是陷阱吗?


a。我的问题在某种程度上说都是荒谬的。

b。即使问题是完全准确的,对它的回答也将是“不,你不能只使用JQuery,时间)

评论

说“仅使用JQuery”是不正确的_ JQuery是JavaScript库。

没有for或while循环,没有变量,没有函数?都是JavaScript。

“普通的JavaScript”可能是指JavaScript DOM API。您可能需要检查一下并编辑问题以避免混淆。

跨浏览器兼容性还不够吗?

“它(jquery)似乎被设计为能够专门使用它,而无需直接接触Javascript”。那实际上是不正确的。 jQuery只是JavaScript函数的集合(尽管名称很奇怪,例如“ $”)。理解jQuery的重要部分之一就是这种实现。它只是处理DOM操作和循环的额外功能。

#1 楼

首先-仅使用jQuery是不可能的,jQuery所做的就是在全局范围内添加$对象,其中包含一堆方法。甚至更多的操作性库(例如prototype)也无法替代javascript,它们是解决常见问题的工具带。

将jQuery添加到工具带中的主要优点是:


浏览器兼容性-执行.attr()之类的操作比本机替代方法容易得多,并且不会在浏览器中中断。
通常复杂的操作的简化-如果您想看到一个精心编写的跨浏览器兼容版本的XHR方法,请查看$ .ajax的源代码-仅使用此方法,它几乎就值得jQ的开销。
DOM选择-诸如绑定事件和选择DOM元素之类的简单操作可能很复杂,并且每个浏览器都不同。如果没有很多知识,它们也可能很容易写得不好,从而降低了您的页面速度。
访问将来的功能-.indexOf和.bind之类的内容是本机javascript,但尚未被许多浏览器支持。但是,使用这些方法的jQuery版本将使您可以跨浏览器支持它们。

JavaScript不再仅仅是一种客户端语言,而且由于jQuery如此依赖DOM,因此它很可能成为JavaScript的候选者。移动到服务器。我强烈建议您花一些时间来理解为什么要使用jQuery(问这个问题是一个很好的第一步!),并在必要时进行评估。 jQuery可能很危险,主要危险包括:


代码质量-jQuery具有庞大的社区和较低的学习曲线。对于许多写得不好的开源插件来说,这是一个完美的风暴。
效率低下-jQuery易于低效编写。例如,不需要使用jQuery的each而不是for循环,并且在某些情况下可能会对性能产生影响。在JSPerf上有很多关于这些东西的好信息

膨胀-jQuery是一个巨大的库。很多时候,您将使用其功能的一小部分,并获取整个库。有一些很棒的替代方法可以为您提供功能的子集,例如zepto.js和underscore.js-根据您的情况,可以通过选择适合您需要的库来节省一些字节。

最终,如果使用得当,jQuery是一个非常有用的库。但是,它不是javascript的替代方法。它是一个库,就像zepto.js,YUI,Dojo,MooTools和Prototype一样,对于您当前的项目而言,其中一个可能是更好的选择。

JavaScript是一种被误解的语言,并且直到最近才被大多数人视为脚本语言以外的东西。我真的建议您多读一些,这里是一些不错的起点:

编辑07/2014-我注意到这篇文章仍然受到关注,因此我添加了很多链接。这些没有特别的顺序,但是应该会有所帮助。




Ben Alman的博客-这里有很多好的最佳实践。我不同意所有这些,但是我一直都在他的博客中学习新知识。

Code Academy-基本的javascript和jQuery培训。有时回到基础知识会有所帮助。

Javascript Garden-有关javascript更棘手或误解的功能的帖子。请不时阅读本文,直到一切都有意义为止。

Bocoup-这些是培训课程。如果您附近一个,去吧。

Paul Irish的博客-严格来说不是JS,但是这里写了很多最佳实践。他和Ben的twitter提要都非常值得关注。

道格拉斯·克罗克福德(Douglas Crockford)的这本书,通常被称为“ Javascript圣经”,是开始理解javascript的绝佳地方。 br />
Isaac Schlueter的博客-Isaac是npm的创建者,并且在节点核心上工作。他写了很多关于javascript社区的文章,而不是关于代码约定的文章,但是如果您真的喜欢js,那是一本不错的书。

道格拉斯·克罗克福德(Douglas Crockford)的Javascript-如果Brendan Eich是javascript的父亲,道格拉斯是javascript直言不讳的叔叔。他是JSON规范,JavaScript圣经的作者,以及有关javascript的怪癖和暴涨的许多精彩文章。

Brendan Eich的博客-Brendan是javascript的创建者-他撰写了各种文章博客上的东西很愚蠢,尽管他有一个人的过错,但他的JavaScript帖子仍然很有价值。

James Halliday(@substack)的博客-可以说Substack是最重要的node.js开发人员。社区-大约有400个npm模块(并且每天都在增长)和微型,类unix模块的指导思想,他编写的所有内容都值得一读。

Max Ogden的博客Max Ogden是另一个多产的节点。 js的作者,并且擅长撰写可以教您一些知识的博客文章。他也是猫的javascript的作者(我相信还有其他人)。

猫的javascript-这是一个简短的教程,从猫的角度带您了解javascript的基础知识。如果您是初学者,请通读此内容。它很有趣,并且可以在一小时内教多少本书需要花费几周的时间进行交流。

Nicholas Zakas的博客Nicholas是几本精妙的javascript书的作者:JavaScript中的面向对象编程,可维护的Javascript,专业的Javascript适用于Web开发人员和高性能Javascript。他主要专注于客户端,但是有大量的最佳实践和性能提示。

Guillermo Rauch的博客-Guillermo是另一个多产的node.js开发人员,主要以Socket.io和Mongoose闻名。他的博客(以及他的新书Smashing Node.js都是不错的资源。

我确定还有很多我不曾想或不知道的资源,其他回答者应该随时添加到该列表中。

评论


+1对JS的评论不再仅仅是一种客户端语言,而是JQuery如何适应所有这些。

– Shivan Dragon
2012年9月27日在7:49

请注意,所有函数都是对象,但是JavaScript中的所有内容也都如此。最好将$描述为固定在其上的“类级”属性的函数,例如($ .ajax)吐出dom元素的包装对象集,通过使其更加简洁,使方法在需要时自动循环遍历dom对象集而使DOM方法通常比PITA少得多。跨浏览器的通用,可预测的API(这是IE <= 8的问题)。

–埃里克·雷彭(Erik Reppen)
2013年11月15日23:38

这是一篇很棒的文章,但是我想谈一点-“巨大的库...使用Zepto / Undercore”-首先,Underscore是一种完全不同的库-主要用于处理数组/对象-还要使用LoDash相反,它更快。其次,Zepto较小,因为它没有涵盖jQuery的功能。这可能会导致jQuery将修复的错误。最后,jQuery不再是巨大的/单一的,一旦压缩,它的大小约为30Kb,您可以通过减少1张图像来保存它。对我而言,获得的开发效率值得那些字节。

– LocalPCGuy
2014-09-26 2:44



@LocalPCGuy绝对有一些优点。这篇文章(恰好是!)是2年前的,从那时起,js生态系统中的情况肯定发生了变化。例如,我个人使用browserify和小型模块,而不使用任何全局命名空间的库。但是,我认为基本前提仍然正确,那就是在很多(大多数)情况下,很少需要厨房水槽库。我已将其交给大多数开发人员,以确保他们在决定使用它之前适当地证明了库的大小成本,这仅仅是因为它比具体说明您的需求要容易。

–杰西
2014年9月26日19:58在

反应所有事情,对吗!?!?! / sarcasm-如何为工作@Andy选择合适的工具,而且它并不总是React。我认为React在做些好事,但不要假装这是JavaScript世界的全部治愈方法。

– LocalPCGuy
16 Jan 29'在2:47

#2 楼

有优点,但是否真正胜过缺点尚待商'。

主要优点是可以节省带宽并获得更快的响应。 jQuery在您的响应中又增加了约30kb。在某些网络(和某些国家)中,这可能意味着几毫秒。但是,另一方面,您可以使用Web服务器轻松地为其设置缓存(或者如Xion所说,可以从Google的网站上使用它,这样它就不会影响您自己的缓存,并且仍然可以缓存)。

第二件事是,您可能只需要一些非常简单的功能,并且仅下载和设置jQuery可能会比简单地实现所需的时间花费更多的时间。

最后,您可能想要推出自己的框架,这通常是一个坏主意,但是有些人有其原因。
如果您只是因为对学习曲线感到恐惧而放弃了jQuery,则应该重新考虑。特别是因为它相当温柔。

评论


同意,特别是关于带宽部分。 JQuery 1.8.2在最小化/混淆版本中具有92Kb。也同意这些不是使用JQuery的强烈理由。谢谢!

– Shivan Dragon
2012年9月26日上午11:11

@ ShivanDragon:你忘了gzip。这样就更小了。

– ThiefMaster
2012-09-26 11:41



@ThiefMaster:的确如此,感谢您指出这一点。

– Shivan Dragon
2012-09-26 11:43

如果您使用CDN(例如Google的CDN)中的jQuery,则很有可能用户会通过访问其他站点来对其进行预加载。因此,对您的平均(尽管不是最大)响应时间的影响会较小。

– Xion
2012-09-26 14:52

@Phil为什么还要使用它?!?! jQuery从未如此,也不再需要。这是纯粹的撒旦邪恶(连同其他恶魔团伙:ReactJS,Underscore,LoDash,Modernizr,CommonJS,Angular,Google Analytics(尤其是AMD等))。就个人而言,我从来没有包含过一个完整的库(尽管我很少从我的库中提取和优化所需的特定功能),我也从未包含过一个完整的库,几乎我创建的每个网页在拨号上网时加载的时间都少于11帧(1/59秒)。

–杰克·吉芬(Jack Giffin)
18 Mar 22 '18 at 20:20

#3 楼

据我所知,使用香草javascript与使用JQuery,MooTools等库相比,实际上只有两个优点。


库的有效载荷消耗带宽。但是正如人们已经在其他答案中指出的那样,您可以使用gzipping和缓存来限制它。如果只需要jQuery的子集,则可以使用SizzleJS和MooTools进行选择,您可以选择与Modernizr相同的方式选择所需的功能集。
图书馆很大,需要花费一些时间来学习。再说一遍,这是对开发人员的一次性投资...而且您的履历表很容易理解javascript库。
(奖金)库不是万能的,因此,如果您想重新发明轮子,那绝对是可行的方法。

值得指出为什么要使用javascript库,其中有很多功能:


您不需要编写自己的框架来支持您的开发。如果您对工作方式感到好奇,可以查看代码,因为它是开源的。
这些库解决了浏览器的兼容性。 DOM和javascript在浏览器之间都有一些差异。相信我,如果您必须自行修复,这是一个巨大的时间浪费。
使用javascript库是事实上的互联网标准,目前大多数文档已被很好地记录下来,而且大多数网络开发人员(知道javascript的人)都知道如何使用它们。
使用库时,您并没有真正放弃javascript。您仍然需要了解Javascript及其类型,对象,闭包的工作方式等。
大多数库都是模块化的,不需要花很长时间就可以编写插件或使用require和AMD模式。
CSS从DOM中选择元素是一个巨大的帮助。
(BONUS)您也可以将它们与CoffeeScript一起使用。

我曾经在一家坚持使用香草javascript的网上商店工作,因为jQuery又大又吓人。这个决定主要受一个单独的“ javascript开发人员”的影响,是许多浏览器错误和缓慢开发的根源,而尝试进入他的代码库则是一次令人毛骨悚然的经历。编写自己的框架似乎是一个好主意,但是如果您想雇用新的开发人员,那么他们将无法迅速介入并提供帮助。然后还有要考虑的公交因素问题。

正如我以前说的那样,我在那工作过……其他地方有更绿色的牧场。 :^)

#4 楼

我碰巧混合使用了很多。这样做的最大原因是,对于某些应用程序(例如chrome扩展程序),您不需要跨浏览器支持。这意味着我可以利用诸如css3之类的新优势,而诸如过渡之类的事物可以比使用jquery简化您的代码。

我也经常做一些定制的事情。一定要像其他人所说的那样,你不应该重新发明轮子。但是当您被要求做一些疯狂的功能时,我经常发现自己编写它要容易得多,然后尝试破解一些接近但并非完美匹配的jquery插件。

我还与开发人员合作,除了jQuery,什么都没有。而且我不得不说,他们在功能上的折衷程度要高得多,如果找不到找不到符合他们要求的jquery插件,就不会那么容易。

在Web开发中的某些时候,您会被要求做未预先包装在库中的内容。因此,此时最好确保您了解基本语言的真正功能。

所以TLDC:同时使用这两种方法,仅使用香草就处于劣势,如果不使用香草就处于劣势。了解内在和外在的香草,并坚持总是使用jquery。

评论


纯香草js是必经之路!

– marko
2012年9月27日上午11:59

Ryan几乎不知道jQuery在后台暗中滥用了document.querySelectorAll。

–杰克·吉芬(Jack Giffin)
18 Mar 23 '18 at 20:39

#5 楼

我唯一想到的就是如果没有JQuery,您将无法使用JQuery插件。即使这样,您也可以编写自己的JS库,该库将提供插件所需的一切。

这样子想吧:JQuery是一个用Javascript编写的开源Javascript库。您可以查看源代码,从而学习如何做。

不使用简单的旧Javascript就无法使用JQuery。您可能不会使用document.getElementById,但仍将以标准Javascript方式定义函数和变量;您甚至可以编写标准的for循环。

使用JQuery的主要好处与使用任何语言的任何其他3rd方库几乎相同:您无需编写太多代码即可实现特定于您的应用程序的逻辑。

不要让大小吓到您了。 CDN版本的下载量约为3.3k,点击第一页后将由用户的浏览器缓存。

#6 楼

如果您担心性能,则应尽可能使用vanilla js
。框架不仅增加带宽开销,而且增加处理开销。 jQuery还具有与相当老的浏览器兼容的浏览器。

如果您正在开发移动应用程序或游戏(或两者结合使用),则首先需要性能和资源效率。

jQuery和插件可能会加快您的开发速度,但是特别是如果您依赖第3方jquery插件,则应该知道它们在做什么。其中许多都是不好的代码质量和效率示例。

jQuery比本地JavaScript慢2至10倍。而且它很容易鼓励开发人员不正确地设计他们的界面,而过多地依赖jQuery选择器,这比本机要慢得多。

评论


+1,由于性能原因,我同意您制作游戏是放弃JQuery转向使用Vanilla JS的很好理由。对于大多数语言来说,与他们一起制作游戏几乎是正确的。例如,Google家伙在其Android文档中建议不仅在制作游戏时抛弃库(在Java中,对于Android),而且还抛弃一些良好的编码习惯以提高速度。

– Shivan Dragon
2012年9月27日在7:47

...如果您和编写jQuery的人一样了解有效的DOM操作,是的。

–埃里克·雷彭(Erik Reppen)
13年6月13日在4:53

@ErikReppen请实际调查“编写jQuery的人”的真实源代码。我在前23行中看到的恐怖使我失明了近一个月。

–杰克·吉芬(Jack Giffin)
18年3月22日在20:18

自2013年以来,JQ发生了很大变化。

–埃里克·雷彭(Erik Reppen)
18-3-23的21:00