Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Given how much simpler jQuery development is, when compared to native JavaScript, what makes people forgo libraries like jQuery altogether?

Is this because jQuery has limitations or it is slow? I mean, if jQuery is so easy compared to native javascript, what reasons do people have to still use pure javascript?

share|improve this question

migrated from stackoverflow.com Nov 29 '11 at 5:41

This question came from our site for professional and enthusiast programmers.

4  
Similar to Is jQuery always the answer? –  lurkit Nov 29 '11 at 5:41
1  
jQuery is just a library -- writing native JS that uses jQuery is still writing native JS. That's like asking, "What benefits are there to native C++ development?" when you're talking about "C++ development without Boost". –  Zach Mar 19 '12 at 18:20
    
vanilla-js.com –  Daniel Little Nov 14 '12 at 1:08
add comment

13 Answers

I would say the main issue is that more and more people (the vast majority?) do not know how to code in javascript anymore if jquery can't do something they can't do it. Its getting to the point that plain javascript examples are becoming hard to come by. Nothing against jquery its a great framework got a lot of good ideas from it, but people should learn javascript first then learn a framework. I personally find my own framework more flexible and better suits my needs, and yes I do reinvent the wheel sometimes but the total control and having control over bug fixes is a huge benifit provided your willing to put the work into learning javascript. Not only that knowing vanilla javascript makes it a lot more fun to play around and experiment with the newer features instead of waiting for a frame work based implementation. Also to I don't blame jquery for this as its mainly a dom library but it can be a pain to scale with large projects, other frameworks do a better job at this prototype comes to mind. In short its a great framework but not the be all end all people make it out to be.

share|improve this answer
    
Your answer would be stronger if it was less of a rant and focused more on specifics. –  GlenH7 Jul 7 '13 at 18:02
add comment

If you don't need DOM abstraction, cross-browser and legacy browser support - you can easily go without jQuery.

This is the case when you are developing browser extensions, greasemonkey scripts (sometimes), number-crunching stuff, developing for Node.js or other non-browser environments.

share|improve this answer
add comment

Let's talk about cars.

Oh wait, we already did - remember that time we met, a few weeks ago, over steak and drinks? That was a great stake. We talked about cars. In fact, you seemed to be quite the expert on cars. You were able to explain, in detail, all of what's right and wrong and exciting about the latest Formula 1 race. You knew by heart all of Lamborghini's models, including their price and availability, you even had thoughts of purchasing your own Ferrari 599 GTB Fiorano, and currently saving up for it (bet the steak dinner didn't help much.)

While explaining the faults of Toyota in a great, excited voice, you suddenly jumped from your chair and screamed into the air, waving your fists about: "Damn it all, I'm a magnificent expert on all things related to cars! I'm gonna be a car mechanic!"

So you were. You had an interview, the Boss Man was just as impressed as I with your knowledge, and you were hired. The first client came in. His clutch was broken. You inspected it, and didn't know what to do. As a matter of fact, you had absolutely no idea how to follow the advice the Boss Man gave you. You're fired.

But how could this be!? You know everything about cars! Except for...everything about cars. You can very well know your dream car has a V12 engine, but you don't know what that actually means.

So you're not a car mechanic, really - you're a car enthusiast. And until you learn how cars work, you will remain one.

Now let me ask you. How does $.fn.text work? And what about $.fn? What is that, really? How does $(something) return a gigantic thingy containing things, and what is this thingy exactly? Can you replicate their functionality, at least a bit, in theory even? Can you cope without jQuery?

Saying that "native js is hard" is just...false. First and foremost, because javascript as a language has nothing to do with the DOM, which is mainly what jQuery abstracts. Second because once you learn a bit about the DOM, you can already coarse through the most common cross-browser bugs. But just a little secret - everything is hard at first. Long division was a bitch in 5th grade.

As a second analogy for this answer: jQuery is to javascript-DOM (not javascript the language, just the DOM) like Array.prototype.forEach is to for. It works, for 99% of the cases. And it works well. But for that 1% which isn't covered, you need to know how to use the for loop, if only to be practical. This entire answer is based on the "purer" side of the question, and not even the technical side (the library's size, for example, and several other things as explained in Michael Dorrant's answer), because I love javascript, and when people seem to just throw it aside casually saying "pah, those silly javascriptians" and waving fancy white gloves, it gets down to morality.

If you can accept the fact that you'll always be a javascript enthusiast, then who am I to stop you? But if you want to be a javascript programmer, you first have to have the knowledge to at least choose between using jQuery (or any other library) and not using a library. Learn the DOM. Learn how to use it. Write your own small library or just some collection of helper functions. And if then, when you are knowledgeable in the DOM, you choose to use jQuery - godspeed. Laziness is awarded for those who worked hard.

share|improve this answer
9  
Long division is still hard! –  Raynos Jan 29 '12 at 13:28
11  
@anonymousDownvoter Pray explain. Is it because you're a vegetarian? I can change the steak into tofu-burger, but can't honestly say that there is such a thing as a "great tofu-burger" –  Zirak Jan 29 '12 at 14:19
5  
+1 "How does $(something) return a gigantic thingy containing things, and what is this thingy exactly?" Hah! –  ThinkingStiff Jun 29 '12 at 9:58
    
Is an adapted/decorated thingy with original thingy on the inside. It's thingy-oriented. –  Erik Reppen Mar 7 '13 at 21:26
1  
Also, @Mike it's criminal this never got an answered status because it's pure !@#$ing genius. –  Erik Reppen Mar 7 '13 at 23:00
show 1 more comment

I can add two more reasons that weren't mentioned:

  1. When I pick up brand new technology, a lot of times, I would start with a lower level constructs before going to higher-level ones. I'm primary C++/C# developer, but a while ago when I first started playing around with HTML/CSS/Javascript, I chose not to use any framework because I wanted to first get understanding of the technology (i.e. Javascript language itself) that those frameworks are built on top of.

    • Having said that, I've since discovered jQuery and would never want to go back to coding by hand what jQuery can do for you in 1-2 lines of code.
  2. I don't know how common this is, but to me it seems that there's a lot of people who when they see the next framework/technology/language, their first response is, "not another API for me to learn!" They don't care how easy jQuery is but simply see it as standing in the way between them and delivering work using their "true and tried" methods. This is the same category of people who refuse to use Boost Library or any of STL and continue to use malloc for just about everything. You asked why they pick pure Javascript over jQuery and in reality they never made the pick because most of the time they refused to evaluate jQuery in the first place and are perfectly happy with their current pace of development, no matter how slow it is.

share|improve this answer
    
People pick pure JavaScript over jQuery because jQuery is a horrible abstraction layer that isn't neccessary. –  Raynos Jan 28 '12 at 22:28
    
Of course it is, it hides away differences between browsers and that's a big thing by itself –  Kos Jan 28 '12 at 22:57
    
@Raynos: I'm not really a web technology expert and barely an amateur at that, so I can't really defend jQuery. But from what little I've seen it's been very good to me. jQuery adds another tool your toolbox. You can use it as much or as little as you want. It never stopped you from writing pure Javascript when needed. At the same time, there are things it can accomplish with few lines of code that will take you days to write, so if it works, use those 2 lines. If it doesn't, roll your own. To say the whole thing is horrible is like buying a screwdriver and then complaining that it is a... –  DXM Jan 28 '12 at 23:31
    
... horrible tool to hammer nails with because the handle doesn't have enough weight –  DXM Jan 28 '12 at 23:31
    
You don't need jQuery. Browsers have this API called the DOM that allows you to do everything you want. Cross browser problems can be solved using polyfills. jQuery is a mediocre library and a mediocre solution to legacy browser support. –  Raynos Jan 29 '12 at 0:23
add comment

Reasons I know:

  • when the need is extremely minimal, say 1 on-click.

  • when download speed is critical and the jquery library is too large AND you don't have to write much (custom) code to replace it.

  • when integrating with other technologies, sometimes raw js is better.

  • when working on a legacy system (aka 'production) already written in js with established patterns.

share|improve this answer
13  
I wonder how often #2 actually turns out to be true. You save a 92K, potentially cached download, but you end up writing lots more boilerplate JS code. –  Adam Rackis Nov 29 '11 at 5:45
3  
I don't know about that. You can keep the JS to what you need, rather than including the entire library for a subset of the functionality. –  Ryan Kinal Nov 29 '11 at 17:44
3  
@Ryan Kinal - Adam Rackis has a good point, and if you use Google's API for loading Jquery you can load it from the same place the user has likely already retrieved it from. –  Ben DeMott Dec 1 '11 at 8:37
    
I disagree with #4. If the legacy code is horrible and everyone in the team agrees and it's a good idea to add jQuery and use it in future code. –  ThiefMaster Jun 28 '12 at 18:54
add comment

In the browser environment you need a cross browser normalization tool. Such a tool comes in two flavours

  • wraps host objects with new objects which behave the same way across browsers
  • extend host objects to implement the DOM API.

Generally you can use these utilities in one of three ways

  • use small functions like addClass or setText throughout your code when and where you need them
  • write your own cross browser normalization library
  • use an existing one.

You need some mechanism of normalization otherwise you get zero cross browser support.

As for using an existing one, that's fine. I just wouldn't use jQuery. Personally I'm currently writing my own library (DOM-shim it fixes browsers without exposing a foreign propietory API. It turns your browsers into a single well behaved standardized browser).

share|improve this answer
add comment

I need to preface my answer with some open honesty. I love jQuery. It makes my life massively easier, and makes JavaScript code more declarative, which is the way I believe things should work.

jQuery does many things…

Yes you can add plugins
Yes you can extend selectors
Yes it simplifies animation

but jQuery doesn't do everything

Have you ever tried working in multiple window contexts with jQuery? jQuery sucks at dealing with different window contexts because it retains the original window and document context from the window in which it was called.

I've written some code here and there to make popouts*, and jQuery can simply get in the way of what I'm trying to accomplish. Adding a new reference to jQuery in the child window can often make things worse by making it more difficult to tell which jQuery context is being used.

* think of Gmail's popout for composing an email in a new window, not spammy advertising

Use it when it makes code simpler

The time to use jQuery is when you can make your code simpler, shorter, more readable, and faster.

The time to not use jQuery is when it wont make your code simpler, shorter, more readable, or faster. If you need to fine-tune load timings, you may not want to use jQuery because of the event overhead.

share|improve this answer
add comment

Along with the other answers here, especially Michael Durrant's, I would saw speed is a major reason for me occasionally choosing to use raw JavaScript.

Lately I have been working on a lot of animations or other CPU-intensive tasks and some times raw JavaScript is much, much faster than if I go through jQuery.

One example is where I wanted to change the opacity of a position: fixed element in relation to how far down on a page a user has scrolled. The effect was way too slow when I used jQuery for this, causing scrolling to be jerky and the fade effect was ruined. I switched to using straight JavaScript and everything was silky smooth in all but IE <= 8.

share|improve this answer
add comment

jQuery is a library written in and for JavaScript. The idea is it makes all the difficult / tedious JavaScript things simple, thus speeding up development time and making your scripts much more likely to work cross-browser.

What makes jQuery to use :

  • fast
  • lightweight JavaScript library
  • CSS3 compliant
  • supports many browsers.
  • The jQuery framework is extensible and handles DOM manipulations, CSS, AJAX, Events and Animations.

JavaScript is a language whereas jQuery is a library written using JavaScript.

Here are reasons that makes javascript to use rather than jquery:

  1. It every time load the whole jquery script library with the page. It is drawback for peed/ fast query processing website.
  2. Sometime jquery framework collapse/conflict with other.
  3. If you are writing simple code for just for select a element and show alter then native javascript is much better.
  4. If operations are small and performed within few line of code of javascript then it is not good to use jQuery

Due to there reason i like to use JavaScript to avoid jquery framework. It is much better to learn javascript rather depending on such library..

Even If you want to extend them you need to write code in JavaScript. which is also a big talk. Developers get dependent on these libraries, so to make control on projects JavaScript is better then using frameworks.

share|improve this answer
1  
"very nicely handles DOM manipulations" Lol WHAT? –  Incognito Nov 29 '11 at 14:57
    
thank @Incognito for let me know about this.. But is much better than other libraries. keyframesandcode.com/resources/javascript/deconstructed –  Niranjan Kala Nov 29 '11 at 16:35
    
The link is flatly wrong. jQuery supporting psudo-css selectors through sizzle has nothing to do with the DOM. –  Incognito Nov 29 '11 at 16:46
    
well it's ok.. even i have learned from you about this stuff.. can you give me any link or info about these stuff.. I have updated the answer.. –  Niranjan Kala Nov 29 '11 at 17:00
    
yuiblog.com/blog/2006/10/20/video-crockford-domtheory is a good start, then read the w3c spec on the DOM. –  Incognito Nov 29 '11 at 17:17
show 2 more comments

jQuery, as any library or framework, adds another layer of bugs. I love it, but I've also lost a day looking for a bug that turned out to be in jQuery core and not my code (a rare occasion, but not that rare).

Other than that I don't find any other reason not to use it:

  • The overhead is minimal, especially if you go with the hosted Google version,
  • It helps less experienced Javascript developers write cleaner and more efficient code,
  • It's mostly cross-platform, which can be life saving when you have to deal with older browsers,
  • The huge gallery of plugins help me write prototypes in very short times,
  • The DOM makes sense,
  • blah blah blah...

BUT it should be never be used as a substitute of Javascript knowledge. If you don't know how to do it in pure Javascript, you may get away with a library initially but in the long run you are going to pay for it.

And of course there are all of us who've been locked in mortal combat with IE6 for quite a few years, and won't easily let go of our old school tricks in favour of a shiny new toy.

share|improve this answer
2  
You use jQuery plugins? Aren't most of them horribly buggy and full of slow, bad code? –  Raynos Nov 29 '11 at 13:46
    
@Raynos The huge gallery of plugins help me write prototypes in very short times... Just prototypes, I avoid them on production code when possible. There are some plugins with excellent code of course, but you have to look very hard for them... –  Yannis Rizos Nov 29 '11 at 13:54
    
prototypes generally means "should have been a throwaway but is now production code". If you use them on throwaway prototypes then it's fine. –  Raynos Nov 29 '11 at 14:01
    
@Raynos Prototyping is not only about throwaway prototypes. Evolutionary prototyping is a core process of web development... - how's that, for a late response :P –  Yannis Rizos Jan 22 '12 at 17:48
    
"Evolutionary prototyping" is called "cut huge corners now and hope we gain more from doing so then the cost of all that code debt we are going to get". Which of course is only valid if cutting corners get's you in that magically window of time you need for your business to become a success. It's a loan. –  Raynos Jan 22 '12 at 17:57
add comment

As you will be aware jQuery is a general purpose framework which provides a lot of methods which many of us don't use in our projects. (Some of them I haven't used at all)

There are two main reasons for not using JQuery or any other well established frameworks.

1. The project is not big or complex enough to use such a framework: In this case, the coder takes a informed decision based on his experience and knowledge in JavaScript. This will help him to reduce the page weight and also more control on the code.

2. The coder develops his own framework I have seen a project in my company which has it's own js framework. Reason what they quote is that if they are using jQuery and there is any bug to fix in it, they have to wait till the next version. Moreover, if there is a feature to be added, they need to ask the jQuery team for it or add a plugin even though making it a plugin won't be a good idea (example which they gave was that they have been using .live similar thing in their framework even before it was officially added to JQuery). Having your own framework gives you more control to the code. The disadvantage is that you need to reinvent the wheel regarding browser compatibility issues etc. Moreover, if the development process is not good, your framework will bloat and will only increase the time to maintain it.

share|improve this answer
add comment

jQuery is simply a framework – a set of tools written in Javascript. By using that set of tools you are still using Javascript. Some people prefer to write Javascript using the tools jQuery provides, some choose not to, other choose other sets of tools.

Some reasons you might want to write "pure" Javascript without jQuery:

  • pages load faster without including extra jQuery files
  • some frameworks may be incompatible with jQuery
  • the code being written doesn't do anything that jQuery helps with
  • the code is being written for others to use, and requiring jQuery as a dependency would make sharing more difficult
  • the code author wants more control than jQuery provides
share|improve this answer
add comment

I think people use jQuery because it's simpler, easier, and more powerful, and because it helps them forget about IE. Besides, for customized functionalities people do use javascript. Try referring the DOC for more details

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.