A lot of JavaScript developers out there, myself included, love jQuery. And rightly so! Like any great tool, it makes our lives easier. When building something with a large amount of front-end code, like a robust site or application, jQuery is a powerful ally.
However, if you’re building a small- to medium-sized library, you should seriously consider using vanilla JavaScript. Sometimes it makes sense to put down the power screwdriver and use some good old-fashioned elbow grease.
You Might Not Need jQuery is a fantastic resource that is sure to come in handy in these situations. It matches up snippets of the jQuery code you know and love with their vanilla JavaScript counterparts. It’s a straightforward way to see exactly what jQuery is doing for you.
Seeing the code side by side is useful for both ends of this conversation (notice it’s called You Might Not Need jQuery, not You Don’t Need jQuery). The difference between selecting elements in jQuery and in vanilla JavaScript is not as large as the difference between animation code. If you’re heavily reliant on element selectors, you might opt to go with vanilla JavaScript. But if you’re making heavy use of animation, jQuery may be your choice.
Historically, jQuery has been a great tool because it handles all cross-browser issues itself. To that end, the makers of You Might Not Need jQuery explain:
Some developers believe that jQuery is protecting us from a great demon of browser incompatibility when, in truth, post-IE8, browsers are pretty easy to deal with on their own.
If you don’t use jQuery, you have a choice to make: either write the code to solve browser compatibility issues yourself, or build a progressively enhanced experience. After all, JavaScript shouldn’t be required to use what you build. Weigh the benefits of writing vanilla JavaScript (fewer requests with less data to load by not including jQuery, among others) against the fact that certain browsers won’t get the full experience. Like everything in our line of work, choose the route that’s right for you, your team, and what you’re building.
I think it’s also important to realize the number (and type) of browser bug workarounds you’re walking away from by going vanilla.
You can take the time to link to jQuery, but you can’t link to Vanilla JS in your article? Come on man….
http://vanilla-js.com/
Or the fact that there are not many users who not have an current jQuery version already in the cache.
@Sean: That’s true, and like I said, you have to decide if those things are deal breakers for you and your project. If they are, then by all means, use jQuery!
@Alex: I’m actually talking about vanilla JavaScript in the sense of “JavaScript how it’s shipped in browsers,” not the library Vanilla JS. Confusing but important difference.
Honestly, I really wish there were more people that can write Vanilla JS (I like how we’re now using the term like it’s a library — what, no version number?). There are far too many people out there that can ONLY write things using jQuery. The number of HTML5 polyfills I have seen that require jQuery is just plain sad. If I’m including a polyfill I want something light that just does the job. I don’t want to have to include jQuery as well just to get the job done.
Aside from weight, what are the other negatives of using jQuery over raw JS?
Haha, Anthony, it’s a bit sad I have to point this out.. the link that Alex suggested is a joke. The way you include the VanillaJS library is by removing the library script tag. Hence the joke.
@Michael: Trolls be trollin’ (and totally got me).
@ Eli, There are many reasons to not use any library at all. Ironically the more complex and advanced you code base gets the less you want to use a third party library. There is a sweet spot where libraries make sense and that is great for “most” sites.
A general list of some reasons :
File Size, Libraries are huge. Much larger than you application code will be (if you are in the sweet spot).
Performance, Libraries usually include code to reduce bottlenecks that some OO design patterns run into. That being said the nature of avoiding those performance obstacles can create new ones and limits the OO patterns that you can use with that library. They also limit your control over re-flow issues.
Abstraction, Libraries like jQuery force you to write your code in a jQuery way to get the best performance and stability with the library. This limits the abstraction of the code base that you and your team are able to implement.
Learning, You have spent thousands of hours learning the ins and outs of javaScript only to throw much of that knowledge out and learn new “native” objects, methods, properties and patterns. Is it worth the time to get good at any particular library instead of javaScript? especially when you consider the vast number of libraries that exist. You may not have control over the project abstraction and someone may choose a library you do not know. Forcing you to spend much time learning it.
* I use jQuery when I have to and rely on THREE.js for webgl.
@Chris, I would say exactly the opposite — the more complex and advanced your codebase gets, the more you want to use a third-party library, and for precisely the reasons you mentioned.
File size
The simpler your application, the larger a third-party library will be relative to it. The minified and gzipped jQuery clocks in at around 30kb. Say you have 10kb of your own JavaScript—including jQuery will inflate the size of your site by 300%! If you have 100kb of your own JavaScript, though, the will library inflate your site by a mere 30%. Relatively speaking, including a third-party library will bulk up your site much more if it’s smaller.
Performance
Yes, abstractions can be slower than native code. But if the library is popular, your own code is probably slower (and buggier). jQuery has hundreds of contributors constantly running tests, benchmarks, and tweaking the library to squeeze out the best possible performance in the most situations. You, meanwhile, only have a finite amount of time, and you’re probably not spending it thoroughly searching for possible optimizations.
Abstraction
A well-designed abstraction actually allows you to be more flexible. Think about how chaining methods in jQuery makes formerly-arduous tasks easy, or how difficult an application like Trello would be to write without the structure Backbone allows you, or how much of a nightmare it would be to manage dependencies without a tool like RequireJS.
Learning
True, you spend plenty of time learning native JavaScript properties, methods, etc, but using a library doesn’t mean you throw that knowledge out! Au contraire: if something goes wrong with the library, if you ever need to patch it or fix it, you’ll be much better equipped to deal with it. As much as I advocate that developers use libraries such as Backbone and jQuery as often as possible, you should know how they work on the native level, and how to work without them as well. In order to use a tool effectively, you need to understand it inside and out—and that means knowing vanilla JavaScript as well as the tools built with it. Otherwise, it’s just magic.
Of course, everything should be evaluated on a case-by-case basis; sometimes libraries will be appropriate, and sometimes you want to work at a lower level. That said, in 99.99% of projects I’ve seen, using a library (or libraries!) is the right choice.
@gake The problem with performance can vary a lot. Depending on what you want to do, you may want to rely on something much simpler – and much faster – than $.
And if you need to support just the most modern browsers, maybe you don’t need jQuery at all, because with the exception of some rare bug fixes everything else can be reproduced with standard methods.
On the other hand, other libraries can be useful instead, like Three.js or RequireJS or whatever.
jQuery is a wonderful framework – but sometimes, it leads developers to abuse chaining and forget what’s under the hood.
@gake personally, when considering to not use a library for a project I find abstraction and performance to be the crittical issues. In your response you mentioned chaining. The library forces this pattern on you, therefore it is not a part of “your” abstraction. It may not be consistent with your code base and it may not be the best way to compose your application’s objects. Also I find you end up doing a lot of deep lookups that add up to a performance cost. Constantly returning “this” can also add up in a simulation if it is not necessary. As a side note changing is not library exclusive, you can do it in JavaScript simply by returning this (or that). I am not saying that it is a bad pattern like all patterns it is a tool that is great in some situations and bad in others.
I will reiterate that it usually make sense to use a library, especially if everyone already knows it. Personally I prefer to use the smaller libraries. Most of jQ isn’t new and it, last time I checked, used the Sizzle library for the query selector which in turn uses or is based on the PrototypePrototype library.
I think that in the near future much of the best parts of libraries will become native like compatibility, query selector (already here) and simplified common process like ajax.
JavaScript shouldn’t be required?
Also CSS shouldn’t be required!
I think javascript and css may be recuired for some websites.
There are more things you recuired, e.g. a mouse or keyboard and a screen size between x and x, etc.
A couple of things that I don’t agree:
Well, Good that we don’t have to deal anymore with IE6. BUT there are a lot of browsers inconsistencies still, but this time is about webkit and Mobile browsers like Android browser, still more difficult to debug and test than before. jQuery *still* is really useful.
This is a list of all the bugs that jQuery fixes, so you don’t have to:
https://twitter.com/jeresig/status/431592839827304448
I don’t agree on that, jQuery animation still relies on setTimeout. You should be using CSS3 or specialized animation libraries if you are planning to use heavy animations.
Places where I wouldn’t use jQuery: node.js libraries, Chrome extensions, etc. For everything else, I would use jQuery, IMHO.
The statement that gets me is
Some developers believe that jQuery is protecting us from a great demon of browser incompatibility when, in truth, post-IE8, browsers are pretty easy to deal with on their own.
It is now less than 2 years ago that I had to support IE6. I will still have to support IE8 for a long while. In real life with real users and not just techies, jQuery can be a lifesaver for things like Event handling, Ajax and some CSS manipulation. I use jQuery 1.1x extensively but can code vanilla whenever I feel the need. I will not drop vanilla JS for any framework/library, but for now jQuery is my #1 tool.
I really like this article, although I’m exposed to a different type of reality. Most of the developers I work or collaborate with love to use frameworks. I happen to be working with a developer who has been pitching the idea of using Angular.js in one of our applications, even when it is not a single page app. The industry is reaching a point where developers want to use a framework or library for the sake of using a framework or library.
A few weeks ago I was helping a friend with small app she was developing. She was using a third party library to handle a tab-like interface. She had a second library to implement image carousels. Because the first library was changing the visibility of some items, the second library was producing some unexpected behaviors. The interaction she wanted in her component was so simple that there was no real justification for the use of first library. It ended costing us hours of debugging. At least we were able to provide suggestions to the developer of the component.
Some libraries make it very easy to move fast at the beginning of a project but eventually there will be the need for customization. The client will want a behavior not included in the library and the work around to make that happen can end up in ugly code. I agree, some times you just don’t need a library.
I love Vanilla javascript. However, I have my own very small lib containing several supporting methods and utilities that are recurring code snippets. This lib is at about 3k just now, and I call it “sprinkles.js”. You know, the small multi- color sprinkles for topping off a vanilla cone in the summer.
I’m confused, but thank you 🙂
Thanks for the input! I’ve recently started writing JS without the help of jQuery and was surprised how easy it is today.
A few of us have therefore joined and created plainJS.com – a repository for vanilla JavaScript tools. It’s supposed to provide the most important snippets and plugins for building great websites without using jQuery.
It gives ready-to-drop-in solutions and helper functions for all the important jQuery methods, like Ajax or DOM manipulations.
I’d definitely appreciate your feedback on this new project 🙂