Develop Reference

Reason for using jQuery over javascript besides less code? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I started using Javascript for HTML5 mobile development but noticed I can use the jQuery library as well. My question is, does jQuery do anything besides require you to write less code? Is Javascript faster in performance? Sorry for the newbie question but I couldn't find an answer and really interested in the difference. Thanks in advance

jQuery is a library built in JavaScript. The more you abstract the less performance you'll get. For example, just selecting an element with the native DOM methods is going to be way faster than doing the same with jQuery.
So the question is not quite "find out which one is faster", you already know jQuery is going to be slower. The question is more like "is the performance hit worth it?". And yes, most of the time it is because the time you save in writing code is much more valuable than the performance hit you get, which most of time is simply negligible.
Another factor is the quality of your vanilla JavaScript code. jQuery has been tested and maintained for years, and it shows.

Your question should not be "should I use jQuery or plain JavaScript" but rather "which library should I use?". No one should be starting a substantial project with zero code, they should have at least a good collection of robust, tested code that can easily be collated into a library or tool kit.
The problem with a general library is that it must provide general solutions, hence why jQuery has 4,000 lines of code that any one project might only really need a few hundred lines of. Some libraries have very many more lines of code. If you use someone else's library, you are often bound to their update schedule and may well end up using plugins that require different versions of the library.
If you have your own library, or one developed and maintained in your work area, you get the same reuse of code and can cut your cloth to suit the project. jQuery (and most general libraries) are monolithic: it's all or nothing, you can't include just one part or another (e.g. you might just want a good addListener function). Your own library can be modular, so you only include the code you need and can avoid many of the cross–browser issues that general libraries must deal with. David Mark's "MyLibrary" is one of the very few modular libraries.
Also, cross–browser differences are becoming less and less of an issue and the DOM API is becoming richer so there is less and less need to use a general library. E.g. no one accounts for document.all anymore, or bothers with browsers that don't support either addEventListener or attachEvent. Once support for IE 6 and 7 can be dropped (a few years yet) there will be very little reason to use a monolithic third party library, modularity will be the key. Everything will be a plugin, there will be no need for a base library, or the base library will be very small to provide a generic API for basic DOM functions.

What are some empirical technical reasons not to use jQuery? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Context:
I am astounded by the number of front end developers that hack at HTML, Javascript and CSS all day long and that ignore tools like jQuery ( or other equivalent helper frameworks ) and refuse to use them. I am not talking about JavaScript gurus, I am talking about in the trenches every day Joe production developers. I get a lot of arguments that are more like excuses or personal opinions that I don't think have any technical merit, I want to make sure I am not missing something.
Question:
What are some empirical technical reasons not to use jQuery?
I am not looking for religious or dogmatic arguments or subjective opinions "like some other framework is better", consider jQuery the straw man for all comparable frameworks in the question.

Update 2015:
In this answer from 2011 I'm talking about libraries like jQuery, YUI
or Prototype. Today in 2015 that reasoning is still applicable to
frameworks like Angular, React or Ember. In those 4 years the
technology progressed tremendously and even though I see considerably
less prejudice against React or Angular than I saw against jQuery or
YUI, the same kind of thinking - though to a lesser extent - is still present
today.
Update 2016:
I highly recommend an article published few days ago:
Why jQuery? by Michael S. Mikowski, author of the Single Page Web Applications book
That article is basically a very detailed answer to this very
question. Had it been available when I was writing the answer below - I would have definitely quoted it.
Original answer:
I'll answer about jQuery but those are the same arguments that I've heard against using YUI, Prototype, Dojo, Ext and few others. Main arguments that I've heard:
file size, which in fact is 84.6 KB in case of jQuery 3.2.1 - probably smaller than the logo on an average website and can be served from Google's CDN which is likely to be already in the cache of most of your visitors. As using jQuery always means smaller file size of your own JavaScript files, it can actually mean smaller download, even if not already in the browser cache.
speed - writing pure JavaScript may be faster, but writing portable JavaScript seems to be impossible for most of the people. A website that is faster but doesn't work on every popular browser is useless in the real world. Besides jQuery uses some pretty heavy optimizations to actually be pretty damn fast and keeps getting even faster with every release, so it's actually not so easy to write faster code by hand for anything other than trivial examples.(*)
"intellectual property" - a company is scared using someone else's code - while in fact jQuery is open source and free software that is used everywhere from your grandma's blog to Amazon, from Twitter to Bank of America, from Google to Microsoft - if they can use it then any company can use it.
I can't remember hearing any other argument being used seriously.
(*) Here's a trivial example: getElementById('someid') vs. jQuery('#someid')
Is using getElementById faster? Yes. And of course everyone always checks the parentNode to catch when Blackberry 4.6 returns nodes that are no longer in the document, right? jQuery does. And everyone handles the case where IE and Opera return items by name instead of ID, right? jQuery does. If you don't do it then your code is not portable and you introduce subtle bugs that can be very difficult to find. And getElementById is the most trivial example that one could possibly find - don't even get me started on events and AJAX and the DOM...
Update:
There is actually a fourth result of asking why someone doesn't want to use jQuery. I forgot to put it on this list because it is not really an answer but rather the lack of any answer. The comment I got yesterday reminded me about it. This is hardly a "technical reason" to be added to the list but may be interesting nonetheless and may actually be the most common reaction.
What I personally suspect to be the main underlying reason to all of those reactions, though, is what I believe to be the biggest obstacle to progress in computer science: "I don't want to use it because I never did, therefore it must not be that important."
It was once the reaction to optimizing assemblers, compilers, structured programming, higher level languages, garbage collection, object oriented programming, closures or pretty much everything that we now take for granted — and today it's AJAX libraries. Maybe some day no one will remember that we once used to manually interact with the raw DOM API on the application level like now no one remembers that we once used to write programs using raw, unadorned, inscrutable hexadecimal numbers.

jQuery expresses everything in a DOM-centric paradigm which can be misleading and doesn't require any need to express things in an application pattern.
Many developers wind up programming themselves into a corner with this DOM-centric pattern and eventually realize they haven't created anything extensible or reusable.
Rebecca Murphey has a great write-up of her own switch to Dojo from jQuery - the blog post is more about why not jQuery versus why Dojo.

One reason not to use a framework - and this is an extreme edge case - is when writing embeddable code for another website, such as a banner. Arbitrarily inserting some complicated library or another will be polluting the namespace and potentially breaking someone else's site. Not that I wouldn't put it past some advertisers to try anyway, the pond-sucking scum, but I digress...
I disapprove of adding a framework when one is already present and equally capable. I see it all too often and it's my pet hate, I see it as unwarranted bloat. That is another question entirely.
Other than that I cannot think of a justified reason not to.

filesize - but really, beyond that, it's an absolute god-send for cross-platform javascript and browser differences. You would have to have some very good reasons not to want it in your toolkit (or be a fundamentalist developer idiot).

They can't justify the filesize (even though it is probably less than script which doesn't utilise the abstractions provided).
They don't want to rely on third party tools.
Their business does not want to run any libraries (for whatever reasons).
Their business does not want to run any JavaScript code not written by their employees.

Learning: To actually code everything, and learn more. (Rather than using pre-coded stuff)
Size: jQuery has TONS of features you might not need, why make the user download so much code if it's not going to be used?
Alternatives: at this point, there are dozens of more powerful, well structured web frameworks out there.
Flexibility: Although jQuery is really flexible, you might need something it doesn't provide.

By all means, I like jQuery, but there are some reasons not to use jQuery:
Download size/bandwidth: jQuery 1.5 is now over 200K uncompressed, for some the size of the library is too much to justify the benefit.
Performance: Writing native JS will always be faster than abstracting it behind a library.
Added complexity: Many people will download the entire jQuery library when really they only need a few neat features from it.
Application Dependencies: Introducing dependencies always has its hang ups. If there is a bug in jQuery, you can debug and edit the file, but upgrading later introduces problems. You could leave the bug, but now you are dependent on jQuery's time table for a fix, not your own.

Because quite often it's just unnecessary.
if all I want to do is validate some input, or hilight some field then it's just as easy to write simple javascript / dom code. And jQuery doesn't really help in such simple cases, so the question should be why use it?
Clearly there are many cases where it is very useful, but sometimes people seem to use it for no real reason too.

I would prefer to use jquery for dom manipulation or traversing the dom , which is really easy with jquery . Moreover, attaching an event or event delegation are so easy using jquery or other framework otherwise you have to write custom event attachment for IE or non IE browsers etc.
But it has some performance penalty when you use $.each instead of vanilla JS for and array.push()...
other issues like if you bind an event and remove that without unbind it will have memory leak....
My conclusion is only use any framework for complex dom manipulation and rest use vanilla JS

Why not use jQuery?
I can't think of a good excuse to use vanilla JavaScript over jQuery (aside from the intimidation factor of learning something new), but some people prefer other JavaScript frameworks (like the excellent MooTools) due to the philosophical differences between them.
Some people simply don't like jQuery's DSL-ish syntax, but they recognize the importance of using a robust JavaScript framework.
Personally, I love jQuery, but I know people who use other frameworks and are no less productive.

What are pros and cons when choosing jquery as my primary javascript library? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have started a new web application and have decided to use jquery as my primary javascript library... But still i want to get some pros and cons tips from SO users who used jquery ...

Pro's
Eliminates a lot of cross browser javascript issues
Can perform complicated Javascript operations in little code
Can easily add Ajax functionality to app
Has built in UI and effects libraries
Con's
Overhead of adding extra javascript to page
Learning curve may not be short for some developers

All pros, no cons.
The only thing will be the execution time overhead that jQuery adds to load its files and execute its functions, but compared to the Pro of coding cross browser compatible JavaScript it is nothing.
Also compared to other JavaScript libraries jQuery is one of the fastest and smallest out there. Their community is huge and you can easily find support and good documentation.

Pros:
Large community
Useful for selecting and iterating over sets of DOM nodes
Eliminates some inconsistencies between browsers
Makes it easy for inexperienced JavaScript developers to do relatively complex scripting tasks
Cons:
Regular updates that change existing behaviour
Some confusing fundamental API methods (e.g. attr() method: what exactly does it do? It certainly blurs the line between attributes and properties)
Encourages "chaining", which leads to code that is difficult to debug: in a long chain of jQuery method calls, there's nowhere to put logging statements, so you need a full-on debugger
Short list of supported browsers
A general point about general purpose libraries: they encourage developers not to attempt to understand the underlying problems that the libraries try to solve, leading to a tendency to think of the library as being magical and to use it for absolutely everything
Adds 70K of JavaScript to every page where it's used when often a few bytes of non-jQuery code would do
Performance is generally much slower than the equivalent (well thought-through) non-jQuery code
Quality of plug-ins is very variable

You've made a good choice, don't worry. jQuery is a very well designed library - it is powerful, clean, well documented, and extremely popular. Learn it well, and it will be a powerful tool in your arsenal.
That said, I think that to be really aware of its pros and cons versus other frameworks, you should first learn it well. Only a deeper understanding of a tool enables you real comparison with other tools.

The only con I can think of is the occasional memory leaks. It is a great framework on top of javascript and is not restrictive.
That said, jQuery UI is terrible to my taste and if your application requires highly interactive UI try Ext JS.

The pros and cons are really relative to what your new web application will be doing. If it is going to be JavaScript/Ajax-rich and requires cross-browser support then jQuery is the way to go - no doubt. However, if you are only going to use JavaScript very sparingly, then it may be over-kill to include a large-ish framework, and it would be more efficient (in terms of performance and page size) to code the JavaScript directly.

Pros: Lightweight, easy to use, good documentation, gets rid of nearly all cross-browser issues and normalizes the event model.
Cons: jQuery UI doesn't have much to offer, and the plugins are hit or miss.
If you're doing a very JavaScript-heavy Rich Internet Application, go with YUI or ExtJS. jQuery is an excellent DOM manipulation library, and is the best for highly custom UI work. But if you need lots of stock UI and a robust data management system behind it, you need a bigger framework to tie it all together.

Are jQuery and its peers helping or hurting JavaScript Knowledge? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I noticed most questions related to client-side script on SO are jQuery related and that got me thinking. I'm wondering what the ease of these libraries is doing to actual KNOWLEDGE of JavaScript and the DOM.
So much is done for you that my fear is there is a growing number of web developers that actually know very little about JavaScript besides how to include the jQuery library and use the plug-ins they download. It's the "fast food" approach to software development and, based on nothing more than anecdotal evidence, I think a lot of web "developers" would be in the dark when it comes to client script if they were suddenly unable to use the jQuery library.
My question: are these libraries helping or hurting REAL knowledge of client-side scripting?

In my opinion jQuery is to DOM as the .NET Framework is to the Win32 API, or GTK+ is to X11 programming. It's another layer on top of the "raw" API. It makes things a lot easier to work with, at the "cost" of abstracting the lower level details. Usually this is OK, but sometimes these details are important. It can help at times to be familiar with the underlying API (I think moreso in the jQuery/DOM case than .NET/Win32), but I wouldn't worry overmuch if someone has to hit a reference site or two before coding a pure DOM solution.
It's also important to recognize the difference between "JavaScript" and "the DOM". The DOM is not part of the JavaScript language; it is merely an API exposed by to the JavaScript engines in the major browsers. So while using jQuery might hinder one's knowledge of the DOM, it won't hurt their knowledge of the JavaScript language itself.

This is common question in programming.
Libraries and high levels of abstractions, in general, make things that were once difficult, much simpler. This tends to make the number of people who understand low-level internals smaller, but also increases the overall productivity of the industry.

jQuery have hurt my knowledge of DOM: I forget this **** DOM as a nightmare.
jQuery will never hurt my knowledge of JavaScript. You can't forget JavaScript after Crockford's texts

I started by learning Javascript as a child - HTML + Javascript was the easiest thing to deploy without having to actually know much about how computers worked. Since then, I feel that I know more about Javascript than I ever would have to.
However, there are very few projects now for which I use Javascript without jQuery. In fact, before I knew about jQuery, I made my own libraries. They weren't great, but they worked, and saved me loads of time and repeated code.
I guess my point is that the Javascript pros would have produced great libraries for themselves, no matter how many n00bs ended up grabbing onto them. Even if we're hurting beginners' knowledge of Javascript (an assertion which I'm not even going to make), jQuery is still definitely a good thing. What it does to beginners is a question of the learning process we offer beginners, rather than the tool itself.

I think that jQuery and its peers are probably greatly increasing general knowledge of Javascript. When I discovered jQuery I went from disliking Javascript and using it as little as possible to thinking it was a wonderful and beautiful language. Indeed, it might now be my favourite language in which to program, and I've learned an awful lot by reading the source code of the jQuery library. I can't believe that my experience is in any way unusual.

Why do you care about the "real" knowledge? The end result is all that matters.
If a developer can make a website that loads really fast with a great interface and layout, then he or she is a successful developer. How (s)he did it is irrelevant.

What cross-browser JavaScript libraries exist? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm gearing up to do some Ajax style client-side JavaScript code in the near future, and I've heard rave reviews of jQuery when it comes to this realm. What I'm wondering is:
What are all the cross-browser JavaScript libraries out there?
What is the experience using them?

An excellent resource is Jeff Atwood's post on JavaScript libraries.
He lists:
Prototype and Script.aculo.us
jQuery
Yahoo UI Library
Ext JS
Dojo
MooTools

ALL the cross browser JavaScript libraries out there? You do realize that there are
well over 100 libraries out there, so you should narrow this down a little, IMO.
A good place to start is with Wikipedia's Comparison of JavaScript frameworks, which covers Dojo, Ext JS, jQuery, midori, MochiKit, MooTools, Prototype & script.aculo.us, qooxdoo, YUI, and SweetDEV RIA.

Prototype FTW.
I do like jQuery, but Prototype serves my needs most of the time. It may just be because I'm more familiar with it, but I seem to get stuff done faster in Prototype than in jQuery.

I want to report this almost unknown library entitled: "BBC Glow".
Other libraries are praised for bells and whistles, but Glow is about cross-browser support. The project has a clear statement about its goals, and there is also a browsers support table.
It is a solid starting point.

Most of the existing answers are either gateways to slimy marketing or libraries long past their due date.
What is conveyed as "cross-browser" is most often "multi-browser", meaning a small umbrella of browsers. Libraries such as Dojo Toolkit and Ext JS (anything by Sencha, really) are guilty of this behavior. jQuery used to behave similarly before some loud calls for sane code arose (the project still has a giant mountain to climb yet). "Cross-browser" most often refers to abstractions for the DOM and a few other APIs.
I've recently completed an HTML DOM library that covers a very wide range of browsers, which I think may interest the community here. The current list is:
Internet Explorer 5-9;
Firefox 1-13;
Opera 5-12;
Safari 3.1-5;
Chrome 1-4 (presumed to work on all Chrome builds, but Chrome versions remain difficult to test independently); which is the second-widest coverage I've encountered, just trailing another, which I will mention in the next paragraph. The library I've created is entitled: "Matt's DOM Utils" (Utils) and can be accessed via GitHub[[0]] or my own site[1]. It's fully modular and focuses specifically on DOM traversal while providing other utilities such as an Element::classList module.
However, the most comprehensive DOM library on the Internet is David Mark's "My Library". The library contains a giant pile of utilities, with coverage for nearly all browsers beyond Netscape 4. It has a pseudo-modular build stage, and can be very minimal if desired. It can be accessed via GitHub[2] or David's site[3]. I suggest to anyone reading this thread to give that API a thorough glance. I have learned immensely from both the author and the code itself.

If you want to jump on the same bandwagon everyone else does, jQuery is the end-all, be-all. You don't have to think, just listen to everyone else. :P
Personally, I use and love MochiKit. It seems to do everything jQuery does, but the philosophy is a bit different and the community is by far smaller. There are not tons of additional plugins, but there are some. It was designed with a lot of Pythonic style and functional programming constructs, so if that sounds interesting to you, you might want to take a look.

jQuery.
(Added so as to have an entry for voting.)

Loads!
jQuery, Prototype, Ext JS, Dojo, MooTools, YUI, Mochikit, the list goes on!
jQuery is very popular, and an excellent choice. However, some frameworks are better for some things, and others better for others. If you could give us a better idea of what you want to do, or how you will be using it (or even which other languages you use) we'd be able to give you a nudge towards one or the other.

The list that Dori posted is pretty comprehensive, and I don't think that it's possible to list all the libraries out there since there might be one being written even as I type (it seems to be a passion for some people).
I feel that going with jQuery and/or Prototype will probably get you off the ground and building neat stuff pretty quickly, and chances are that you will fall in love with them as so many of us have.
Gucci had Thomas Fuchs (the creator of script.aculo.us) create their website without using Flash, but check it out, it looks amazing for being JavaScript / CSS only.
A post about it is Gucci Relaunches on Script.aculo.us.
These libraries are so powerful and versatile (with some nice plugins) that you won't "hit the wall" and start looking to other libraries anytime soon.
I have also seen people do some nice stuff with Dojo and Ext JS, but I have never worked with them myself.

I like jQuery. Prototype is very similar. There are several others but I highly recommend you evaluate them yourself.

I prefer Mootools because it is lightweight and is based on Prototype, but like Jay said you should check them out for yourself.

Do have a closer look at MooTools.

I can't think of doing any JavaScript development without using jQuery (also take a deep look to jQuery UI).

jQuery is a good choice. It leans towards the 'skinny and speedy' side, and allows for some fantastic DOM manipulation.

Of the popular ones are jQuery, Dojo Toolkit, Prototype (with Script.aculo.us) and MooTools. I'd encourage you to test out MooTools unless you're on ASP.NET in which case I'd encourage you to check out the project I am working on (Ra-Ajax) which is a fully server-side binded Ajax Framework for ASP.NET...