Straight JavaScript Performance Benefits
Well…shit.
The thing that stood out the most to me in Addy Osmani’s slideshow was their performance analysis of Wikipedia’s visual editor. It has some pretty serious performance issues, and it was cool seeing how they were tracked down via Chrome’s dev tools.
I can count the number of client-side projects I have done that didn’t involve jQuery on a hand missing several digits. jQuery makes things easier. A lot easier. There are no free lunches however. You are abstracting away some of the ugliness of JavaScript and the various browser engines, and abstraction comes at a cost. If you don’t believe me, go look at an abstract painting for a minute. Ha! Good luck getting that minute back.
But I didn’t realize how much that convenience can cost. Depending on how you use it, it could cost you a lot. And unless you are supporting WWII era versions of IE, plan old JavaScript isn’t all that bad.
1 | $('#elem').addClass('class'); |
1 | document.querySelector('#elem').classList.add('class'); |
Plain JS is 21x faster.
1 | $elem.show(); |
1 | $elem[0].style.display = "block" |
Plain JS is 51x faster.
You can find lots of examples like this.
The point isn’t that jQuery is bad. Not at all. jQuery has, over and over again, prevented my life from turning into a furious ball of nothing. jQuery is awesome. On many projects the performance difference isn’t going to matter.
The point is to be mindful of what you are doing. If something can be done just as easily, or even slightly less easy, in plain JavaScript, that isn’t a problem you need to abstract. Do it in plain JavaScript. For other things, jQuery may be the best way to go. But make sure what you are using is a choice and not a reflex.