jQuery vs. JavaScript
JavaScript
Before we compare jQuery vs JavaScript, let’s recall the basics. What is JavaScript used for? JavaScript allows websites to perform actions such as refreshing specific parts of a page without reloading the entire website, displaying pop-up messages, or introducing animations into 2D or 3D graphics. Overall, the main impact is on client-side development, but JavaScript can do server-side actions with Node.js. Node.js is a framework for running JavaScript code on the server.
Using jQuery saves JavaScript developers time because they don’t have to write code themselves. Plus, raw JavaScript is heavier than jQuery. Remember, the jQuery library only provides code for front-end development. If the site is complex, then jQuery will not be suitable for working on it in a large team, developing and maintaining it. For a landing page, only the stubborn will use pure js, and when working with a framework or in large projects, of course, jQuery will not work.
Sometimes large applications are written in jQuery, but they are difficult and expensive to maintain. You need to immerse yourself in the code and always be in the context of this library, otherwise, after a month it will be difficult to understand.
In full-fledged frameworks (for example, Vue.js or Angular.js), the possibilities for normal operation are already out of the box. This is, first of all, a component-based approach to building interfaces and abstraction from the DOM. And anyone who comes to the team with knowledge of the framework will be able to understand the code – at least because there are common project structures, documentation, community, and StackOverflow.
jQuery has a large community and has also documentation, but it seems to us that everyone there writes code for themselves. It is a question of choosing a convenient tool for a specific task. A simple page with a simple form can also be written in jQuery. And most of the things jQuery did great are now part of vanilla JavaScript and without any libraries.
jQuery
jQuery is one of the most well-known JavaScript libraries and one of the most highly criticized. 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 the Sizzle selector engine. And last, but not least – jQuery hid some incompatibilities between different browsers’ JavaScript implementations. But, if it is so amazing and useful, why did we make this decision?
Why?
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 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 have 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 Options
jQuery provides useful functions to manipulate the DOM and the core of it is the selector engine 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 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 the Code That‘s Easy ta Manage
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 constantly searching for ways to make our products better and 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 you want others to reuse your code.
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. 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 the 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 often ends 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 figuring out what the hell is going on in another progremmer’s code.
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 friendly user interface.
React JS library is very lightweight, fast, and 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. This awesome mobile starter kit allows you to make your mobile app for both iOS and Android at once. It provides you with any UI components you possibly need, and saves up to 20 000$ in development.
Does jQuery have some future?
Developers upgrade it constantly and furthermore, jQuery can offer you tons of plugins for all tasted and any needs. Are you looking for a carousel? jQuery has a special plugin for you! Do you want responsive and draggable grid layouts? Get one! Does your app need photos recognition and a face detector? No problems, jQuery can pick up a solution! For every 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 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. No update helps jQuery. It keeps losing to the younger, better-looking cousins (React, Vue, Angular) that have already got recognition and a significant portion of developers who call the 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.
Conclusion
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 still receives updates, has a long history, a large number of adherents. Almost all 5+ years old websites are based on this library, and it took years of recording for Github to transfer its platform to plain JavaScript.
