jQuery is one of the most well-known JavaScript libraries and one of the most highly criticized. Why that is? Well, the reason is that jQuery acquired enormous popularity and drew attention very quickly from its release date. And this glory was deserved. jQuery did AJAX, animation, and had great simplicity thanks to Sizzle selector engine. And the last, but not least – jQuery hid some incompatibilities between different browsers’ JavaScript implementations. But, if it is so amazing and useful, why we made this decision?

Why?

Well, the time has changed since jQuery’s time of glory. jQuery allowed programmers didn’t go crazy during the browser wartime IE vs Netscape’s Navigator when browsers can’t agree on things and developers had to deal with specificities of them both. Today Google is full of articles like “you don’t need jQuery at all” – just try to google it. The most persistent readers might discover articles dating back to the 2015 year. They all are roughly the same and have identical reasons we fully agree with, so we are not going to waste time looking into all the details. We just highlighted the main reason for us to abandon this legendary library. And it is simple – all unique functionality that jQuery has been providing can be simply implemented with plain JavaScript. Here is the list of our key points:

Cross-browser compatibility is not a sore spot now

This issue is not a problem now since in 2019 browser support for JavaScript is more consistent than ever with new APIs. So what once was very complicated and painful is quite simple now without jQuery implementation. jQuery still stays a necessity when you deal with Internet Explorer 9 or earlier versions. The number of IE users is less than 10 percent of all Internet users. If we remember the Pareto principle where 80% of the effects come from 20% of the causes, the choice not to use a whole JS library just to get 10% of the effect seems very rational.

Speed

jQuery provides useful functions to manipulate the DOM and the core of it is the selector engine called Sizzle, which contains 2000 + lines of code. So jQuery need to wrap up a bunch of operation to accomplish any manipulations with DOM, and if you know how to do that in plain JavaScript what is the point in adding extra steps? Furthermore, jQuery brings extra dependencies (which is extra for sure) in code, adds complexity and file size. Okay, you may say that it’s not that large: the default compressed build is about 73 KB, minified compressed is about 30, but it will make a difference for web app loading speed!

Good code is easily manageable code

That was the vital point why we decided to get rid of jQuery in our products. First of all, we make admin dashboard templates for you, we seek ways to improve the quality of our code to make it more friendly and easily understandable. We maintain up-to-date documentation, provide support and are looking at ways not only to make our products better, but also easier to use. So we need to build maintainable code, while with jQuery sometimes it’s less painful to rebuild code than change it. jQuery is not the best option to use if your code is supposed to be reused by others.

And again… Why?

jQuery uses its way to avoid extending native objects. In the past extending native objects was considered a huge minus, and this has played a significant role in jQuery development. Calling $ (div) returns us not a link to a DOM element or the list of nodes, but some jQuery object. Nevertheless, jQuery can’t entirely avoid links to native DOM elements. You also often use libraries from different sources, some of them need jQuery, some not. This brings an unexpected consequence: we get a mix of native DOM elements, lists of nodes and jQuery objects at the end.

And even if you stick to jQuery naming convention for jQuery objects (adding $ before a variable name) and simple variables that contain links to native elements, you face a bunch of mistakes when you forgot to use $() for non-jQuery objects. To avoid embarrassment it’s often ended with the use of $() for almost everything (just in case). And this “just in case” situation can be implemented several times for the same variable. Looks weird? But there was more.

Even if you strictly abide by the variable naming convention, sometimes you need to call a native method for a DOM-element or run a function from code that is not dependent on jQuery, so your code gets a lot of transfers of objects from jQuery to native and vice versa.

It leads us to the problem of complicated code refactoring to make it jQuery-free, adding new features and at least figure out what the hell is going on in the code that is written by another programmer.

Alternative libraries

We are sure that you might have heard about Angular, Vue and React. We touched them all in our products (Angular, Vue, React) and can say that we like them, especially one of them (don’t throw stones at us for bias, we were impartial judges and we ensure you that it was a fair competition). The number one is React for its ability to create a dynamic responsive and very friendly user interface. React JS library is very lightweight, fast, modern, and it brings us a very powerful platform for creating mobile apps – React Native. React brought in our world’s such apps like Facebook, Instagram, Netflix, Khan Academy and much more. We used React Native to develop an innovative product React Native Starter, an awesome mobile starter kit that allows you to make your mobile app for both iOS and Android at once, provides you with any UI components you possibly need, and saves up to 20 000$ in development.

Does jQuery have the future?

Developers upgrade it constantly (the last update was on May 1st, 2019), its loved and respected library, and furthermore jQuery can offer you tons of plugins for all tasted and any needs. Do you look for a carousel? jQuery has a special plugin for you! ( You want responsive and draggable grid layouts? Get one! Does your app need photos recognition and face detector? No problems, jQuery can pick up a solution! For every your requirement jQuery presents a dozen of plugins to solve the problem. Almost every JS programmer made a jQuery plugin at least once in his life. And that is nice, but doesn’t solve the core issue: jQuery needs a rebuild. jQuery made a unique offer to programmers once and we were happy to accept it, but that time has passed and the web has changed, whereas jQuery has not. None update helps jQuery – it, all the same, will lose the younger, better-looking cousins (React, Vue, Angular) that have already got recognition and a significant portion of developers who call web community to abandon jQuery. And this trend is driving…

We believe that jQuery needs to develop a new product, jQuery version new or jQuery – with all the respect from dev community to this library we sure everyone will give new jQuery a chance, but in the current version we don’t think that jQuery will survive.

The last word from our team

Our conclusion is simple – we strive for the absence of redundant code and extra-dependencies. We don’t encourage you to get rid of jQuery in all your projects. jQuery is still updated, has a long history, a large number of adherents. Almost all 5+ years old web sites are based on this library. Also, there are a lot of useful plugins for any supposed function and a huge number of developers. So we don’t consider that jQuery is going to be forgotten coming years – it needs time. In the end, it took years of recoding for Github to transfer its platform to plain JavaScript.

You might also like these articles:

Originally published at flatlogic.com — React, Angular, Vue, Bootstrap & React Native templates and themes.

Text source: jQuery vs JavaScript. Why we Removed jQuery From Our Templates?