For most of us jQuery has become nearly synonymous with JavaScript or ECMAscript (ES), even the thought of using native ES seems strange and outdated. Indeed for some of us who still remember the amazing effect jQuery had as it was first introduced the thought of returning to native ES seems nearly barbaric. Than why even discuss such a ludicrous idea one might ask? Lets take a look at some not so insignificant even if often disregarded disadvantages of jQuery:

1. Loading – “For everything else, be pragmatic. jQuery is a 270Kb generic library. You are unlikely to require all the functionality it provides and, even if you omit certain modules, it remains a sizeable quantity of code. You may load the 30Kb minified version from a CDN but the browser must halt processing and parse the code on every page before doing anything else.” (Craig Buckler, http://www.sitepoint.com/jquery-vs-raw-javascript-1-dom-forms/).

2. Compatibility – who of us hasn’t lost hours of frustrating, yelling at the console trying to figure out why a certain ES function stopped working only to realise we had the wrong jQuery version installed? as jQuery has been around a long time, and has many versions, one is always limited by the least advanced version of jQuery already present in his project. This often leads to complications in interacting with new plug-ins or reacting to ever changing code syntax and rules. Naturally this problem is not unique to jQuery, and may also apply to native ES but to a much much lesser degree.

3. Speed – this I must admit took me by surprise, not that nearly every function used by jQuery is slower than it ES 5.1 equivalent but how much slower! I will here only mention a one example relating to DOM manipulation (as these are of most importance to us at the POC team) -

Tested on Chrome on Mac OS X -

 GetElementById var $el = document.getElementById(‘hello’)  23,586,232 ops/sec ±0.41%
fastest (baseline)

JScript ID Selector document.querySelector(‘#hello’) 8,540,421 ops/sec ±0.53%
64% slower
jQuery ID Selector var $el = $(‘#hello’) 1,522,304 ops/sec ±0.43%
94% slower
Query Class Selector var $el = $(‘.bye’) 683,694 ops/sec ±0.87%
97% slower

 For more tests go to (https://jsperf.com/jquery-vs-javascript-performance-comparison/79)

So basically native ES is much much quicker than any jQuery even in the most basic of functions, i.e. selecting DOM elements.

4. Plug-Ins – the presence of jQuery tends to encourage the use of jQuery plug-ins for nearly all DOM manipulation tasks as well as other tasks (tool-tips, rating, animation….), each plug-in suffering to some extant from the same problems mentioned above concerning jQuery itself.

I hope I convinced you so far that there are problems with jQuery, but how can one manage without it?

Surprisingly in ES 5.1 there are extremely similar functions. Thus switching to Native ES can be done almost seamlessly. Here are two simple examples:

Selectors – a common argument in favour of jQuery is its ability to easily select DOM elements. However ES is just as powerful and much much quicker in this aspect. Obviously it still has its classic selectors, ByID, ByTagName, ByClassName, ByName and so on, but it also has querySelector and querySelectorAll that allow selection of elements within elements, of Id inside Class and so on – just like jQuery. For example $(‘#example .test li #cool’) = document.querySelector(‘#example .test li #cool’).

Bindings – again Js Native using addEventListener can duplicate the on() of jQuery with no effort and with better performance.

The list can go on and on .forEach instead of .each, element.classList.add() instead of $(element).addClass() etc…

There are many sites that list very clearly Native ES equivalents of jQuery (http://youmightnotneedjquery.com/).

In some cases indeed there seem to be missing functions which need to be added manually in order to achieve the same effect as an inbuilt jQuery function. This however can be seen rather as an opportunity than as a disadvantage. It allows for the construction of custom functions especially suited for a specific task at hand rather than using generic functions containing various unnecessary elements  and adding unnecessary overhead. Such functions can be easily created or found on the internet.

So in short, now that ES6 is already upon us (using babel but soon native as well) it is really about time we go native and take full advantage of ES5.

  • Zvika Naveh

    Great post! You emphasize the overhead we pay for each framework we use.
    Specially on JS it comes even more effective as it is used on mobile devices (think of old iphone 4 that is still widely used) and take your mobile site performance down.
    Also, going forward to more advaned code using ES6, you will have to understand native JS.
    So, as you Amir recommended, why wait? Go native.