December 17, 2015 at 13:53

Stop using jQuery, you can do better without it

    Introduction


    You've probably already heard comments of this kind, and most likely you feel quite comfortable using jQuery. Then you ask yourself why there are such lunatics in the world who so hate such a beautiful and fluffy library and what the hell should I stop using it. You will probably be surprised to know that the point here is not at all hatred. Let's look into the situation.



    Like many other developers, I started using jQuery in the late Bronze Age (2007), when the differences between browsers were just a splinter in the heel and the lack of common standards was so hateful. jQuery was, in a way, a source of inspiration and a ray of light in these dark times, it was revolutionary. I fell in love with jQuery as soon as I started using it. I wrote some bright and fluffy extensions for jQuery and I also wanted to share the good news with everyone and made a presentation about it a couple of times and even organized a little training to familiarize the teams with this product. But then, a few years ago, I changed my mind.

    Let's take a closer look at what's wrong with jQuery in modern web development and how we can fix it.

    Uniformizer


    One of the amazing killer features of JQuery was the ability to smooth and sometimes make up for differences in working with the DOM in different browsers and their versions. But let's face it, since then a lot of things have changed, a lot of modern standards have appeared. For the most part, jQuery at best redirects the call to the standard DOM APIs, and at worst uses its own implementation of one feature or another. In today's world, you can easily do without the use of selectors and jQuery utilities. You can easily replace the type selector:

    $('div, span, article');
$('#formId :invalid');

    on the:
    document.querySelectorAll('div, span, article');
document.querySelectorAll('#formId :invalid');

    Well, or an example of a utility like:
    $.isArray(array1);
$.each(array, function(i, v) {
  // do something here
});

    easily replaced by:
    Array.isArray(array1);
array1.forEach(function(v, i) {
  // do something here
}


    Personally, I prefer to always adhere to standards, jQuery is not a standard, it's just a library.

    Object wrapper


    As you probably know, jQuery, after almost all of its manipulations, returns you a special object in which a certain result or its absence is wrapped or not. For example * $ ('span') * will return such an object to you. Not only does the wrapper object have its own homegrown methods that are different from generally accepted standards, but it still does not guarantee you that inside the jQuery methods it will use only wrappers. Is this far from what * this * will be in the function of the event handler or what will be the first argument of such a function or the value of its special field * target *? A small example:

    $('button').bind('click', function(e){
  var el = this; // Is it jQuery "object" or not ? Let's see the doc
  var event = e; // Is it jQuery "object" ? No, it's a special event-wrapper object
  var target = event.target; // Is it jQuery "object" ? Sure not, it's a simple DOM element
});

    And so, sometimes a wrapper, sometimes not, and sometimes a special wrapper, what is it all about, why do we need to make our lives so complicated? But there is a crutch, you say, what about the convention when all jQuery “special objects” begin with a $ sign. Sort of:

    $('button').bind('click', function(e){
  var $el = $(this);
  var _event = e; // Let's use an another special convention for jQuery's events wrapper, prefix _
  var $event = e; // No, we should be coherent
  var target = $(event.target); // I'm sorry I forgot the dollar, because I'm just a human
  var target2 = $(target); // Oups, but I have to be sure that it's wrapped
  var var1 = someFunc(); // I forgot, this function should return $ or simple NodeList
  $(var1); // Nevermind ...
});


    JQuery as a benchmark for web development


    I have heard this opinion many times that jQuery is a kind of benchmark for web development, if you do this, you simply have to use jQuery to succeed, because it is good, it has eggs and it has a bunch of fluffy and lamp plug-ins. For me, this is all garbage, it was partly true about 5 years ago but not now. This is like saying that in order to develop modern Windows 8/10 applications, you need to use the Win32 API in its purest form.

    As I said above, jQuery is just a library, and by today's standards, a low-level library. And things of this kind are not suitable for writing modern web applications. Nothing prevents you from using jQuery or the pure DOM / API standard to implement a particular low-level task, but writing an entire application and then also supporting it is very difficult. I saw a bunch of big projects that turned into one big dish of spaghetti on the client side, where jQuery was not the root of evil, just people could not cope with the influx of code.

    How can this be avoided? Use solutions that are more suitable for this where they really are needed, be it MV * or something else.

    Testing


    This part is inextricably linked with the previous one. As we all know, a person is lazy in nature and good automation programmers are often lazy. Have you ever tested code using jQuery, because of call chains this is not a trivial task. And if you take into account the fact that often projects using jQuery are gaining weight so rapidly that developers do not have time, do not want or cannot reorganize their code. The result is disappointing, as you can talk about testing when even the author of the code is not able to understand what this code does.

    In the MV * approach, this is solved much easier.

    Total


    If this article convinced you and you want to try to live and work without jQuery, you can use the following links:


    Who cares there is an English version of this article .
    Tags:

    Also popular now: