i$ jQuery mAking u$ lAzy?

Recently, I had a discussion with some developers whether originalEvent was actually a native property of mouse events in JavaScript. If you’re reading this and wondering the same thing, this is the problem.

It seems jQuery has made so much of what we do on a regular basis so simple, that people have forgotten how to do it natively. I’d be curious to know what percentage of developers still remember how to use native JavaScript to set up common event listeners, how to get a reference to a DOM element, or how to modify the content or properties of these elements, let alone to do these things in a cross-browser manner. Most of these things take only a line or two of code that hasn’t changed in probably the better part of a decade, but the majority of developers would likely have to Google how to do these things without the use of jQuery.

Don’t get me wrong, the convenience is great, the problem is, as wonderful as it is to be able to focus on the logic of whatever you’re building and leave the nuances of cross-browser/cross-platform support to the frameworks, somewhere along the way we have stopped focusing on the nuances of the logic and simple good programming practices as well. And yet, we argue about semicolons;

Implementing bad practices is simply too convenient. Architecture doesn’t even get a second thought, if it even gets a first one. It’s all too simple to create a function on DOM ready, use anonymous functions and simply get references to everything in real time via selectors. The fact that most jQuery functions return a jQuery object adds to the problem as completely valid code can be constructed to look like an english major writing a bad example of a run-on sentence on a computer missing the spacebar. The old adage applies heavily here… “Just because you can doesn’t mean that you should”.

In what other programming language community is code that looks like this acceptable?

$(function(){{$(‘xyz’).attr(‘a’,'b’).removeClass(‘xyz’).addClass(’123′).on(‘click’,function(){alert(‘holy crap i’m dizzy’)})});

Thoughts?

Posted in Blog, JavaScript, Web Development
6 Comments » for i$ jQuery mAking u$ lAzy?
  1. Sasha Sklar says:

    In what other programming language community is code that looks like this acceptable?

    Perl maybe?

    I don’t see knowing the minutia of the JavaScript browser API as a sign of intelligence or skill. jQuery saved us from a nightmare of browser incompatibilities and anti-developer APIs and enabled us to focus on shipping code.

    That being said I’m looking forward to the day when the last of the crap IEs (7 and 8) fade into the sunset and we can write tight little web apps with pure JS or maybe a couple micro-frameworks.

    The bit at the end is definitely a concern but one I feel has being widely acknowledged. Alex Sexton’s classic jQuery’s Best Friends describes the problem very well and points us to solutions:

    * Script and module loaders like RequireJS and LABjs to help us write modular code that still performant.
    * Client-side MVC frameworks like Backbone and template frameworks like Mustache to give bigger applications some structure and organization.
    * PubSub for decoupling components.

    JavaScript as written used to be terrible and difficult to write cross-browser and now at least it’s only one of those things.

  2. John Reading says:

    I just don’t think it’s fair to scapegoat jQuery as being responsible for bad architecture in Javascript. In my mind, there are only two real architectures that matter 99% of the time: MVC and Module. I don’t think jQuery impedes these at all (jQuery 1.7 is AMD compliant).

    I do agree that most devs have become spoiled by jQuery, but having said that a lot of the stuff in jQuery is making it’s way into newer versions on ECMA Script and some of the Sizzle stuff is in the new selectors api; that’s in your browser now! So we own jQuery credit for that and these junior devs are using stepping stones now (even if they don’t know it). $.animate will be obsolete soon, then what? Are devs going to pack up and leave or will they just move to css3 (if they haven’t already)? The problem I have with jQuery is the monolithic nature and all the regressive cruft ($.animate) not the parts that actually help. The alternative to jQuery is a lame jQuery-like micro framework, either custom or open-sourced. Why not take advantage of years of engineering?

    My advice to devs worried about this:

    Take a jQuery plugin that you either wrote or use a lot and rewrite it without jQuery. Use some of the newer methods that are available in modern browser implementations of ES5, like the Selectors API Level 2. Take it as a challenge even if you have to write your own utility functions. I guarantee you will learn three things: you can get a lot farther than you thought with less effort than you thought, you don’t need jQuery as much as you think you do, and what jQuery actually does to make JavaScript development easier.

    As for that example, I can’t imagine ever seeing that. Why would someone change attributes on domready? and add and remove a class?

    I think it should look like this:

    $(document).ready(function(){
    $(‘#xyz’).addClass(’animate′).on(‘click’,function(e){
    console.log(‘wow, that was easy.’);
    });
    });

  3. Todd Driscoll says:

    The article isn’t saying jQuery is responsible for bad architecture nor is it saying it impedes it, it is saying jQuery (unintentionally) enables and allows developers to get lazy which is in turn allowing the importance of architecture to be ignored. It’s not the tool’s fault, it’s misuse of it that’s the problem.

    As for the example, it’s made up obviously but really, you’ve never seen code like that? I’m pretty sure we’ve looked at code like that together when reviewing other sites. Ok, maybe you won’t add and remove the classes on DOM ready, so move those into the click handler and that’s just as valid an example. The point isn’t the order of the jQuery helper functions, it’s the endless examples of run-on chains like this in the wild.

    So what happens when you do your module with your $(document).ready and I do a module with with mine and Sasha does one in his module all without an application architecture in place?.. And what about this on a real site with 10 developers and 10 or 20 modules? Economy of scale?… Just wait until one page requires a difference sequence of dependencies than another just because one new developer makes one new module.

    Again, the point is the importance of architecture, how you achieve it (MVC, MVP, MVVM, MVBS, MV*, LVD, modules, events, signals, dispatchers, broadcasters, pub/sub, commands, delegates, non-blocking and dependency managing script loaders, etc…) is irrelevant as long as it’s there.

    I do wholly agree with the suggestion for developers to “Take a jQuery plugin that you either wrote or use a lot and rewrite it without jQuery.” I believe that’s the bigger message here, remind yourself what you can do and how so you don’t ignore those lessons when using the wonderful tools out there that do – without a doubt – make our lives easier.

  4. mm says:

    Great post!

    Unfortunately jQuery has become a necessary evil. I’ld much rather see inexperienced front-end developers leverage a tool like jQuery than witness the horror that would result in its absence.

    I totally agree with John Reading. jQuery is not the real issue, rather its a symptom of a much bigger problem. There are too many designers turned front-end developers out there that are completely clueless when it comes to software engineering fundamentals. Architecture and Detail design, or lack there of, is the real problem. Which is why I completely agree with the sentiment of the original author. Dig in, understand why it works to better be able to come up with the right solution.

    As to Sasha’s comment about solving bad coding practices by becoming dependent on more libraries: how does that make any sense? Let’s make it less complex by adding more complexity?? I’m not saying that using those libraries are a bad thing, rather you should be using them for a reason – not just because a blog article says its a ‘best practice’. They need to be there to address a particular part of your architecture, if your architecture doesn’t need them they shouldn’t be present.

    Additionally, just because your code is now modular and sits inside a framework doesn’t mean that your crap code isn’t crap anymore. Javascript makes it way too easy to write ugly, crap code. The only way you can really solve that is to learn your fundamentals, write self documenting code, and learn to code through a language rather than in a language.

    Kudos to the original poster for having the guts to question what has become the conventional wisdom of front-end development. Personally I feel jQuery is making us more than lazy, its enabling some developers to become highly successful, when they really should be sticking with Photoshop or Visio.

    As for a code example that is worse, how about some c. Any clue what it does?


    #include "stdio.h"
    #define e 3
    #define g (e/e)
    #define h ((g+e)/2)
    #define f (e-g-h)
    #define j (e*e-g)
    #define k (j-h)
    #define l(x) tab2[x]/h
    #define m(n,a) ((n&(a))==(a))

    long tab1[]={ 989L,5L,26L,0L,88319L,123L,0L,9367L };
    int tab2[]={ 4,6,10,14,22,26,34,38,46,58,62,74,82,86 };

    main(m1,s) char *s; {
    int a,b,c,d,o[k],n=(int)s;
    if(m1==1){ char b[2*j+f-g]; main(l(h+e)+h+e,b); printf(b); }
    else switch(m1-=h){
    case f:
    a=(b=(c=(d=g)<<g)<<g)<<g;
    return(m(n,a|c)|m(n,b)|m(n,a|d)|m(n,c|d));
    case h:
    for(a=f;a<j;++a)if(tab1[a]&&!(tab1[a]%((long)l(n))))return(a);
    case g:
    if(n<h)return(g);
    if(n=e)for(b=g<<g;b<n;++b)o[b]=o[b-h]+o[b-g]+c;
    return(o[b-g]%n+k-h);
    default:
    if(m1-=e) main(m1-g+e+h,s+g); else *(s+g)=f;
    for(*s=a=f;a<e;) *s=(*s<<e)|main(h+a++,(char *)m1);
    }
    }

  5. Sasha Sklar says:

    mm I’m not sure I should reply to your post when it contains such obvious flamebait as “Personally I feel jQuery is making us more than lazy, its enabling some developers to become highly successful, when they really should be sticking with Photoshop or Visio.” but here we go…

    “As to Sasha’s comment about solving bad coding practices by becoming dependent on more libraries: how does that make any sense? Let’s make it less complex by adding more complexity??”
    The complexity is already there, we are left with the necessity of managing it.

    “I’m not saying that using those libraries are a bad thing, rather you should be using them for a reason – not just because a blog article says its a ‘best practice’. They need to be there to address a particular part of your architecture, if your architecture doesn’t need them they shouldn’t be present.”
    For every library or class of tool I listed, I also gave a specific purpose for using it. Look to the right of each item listed and you’ll find it.

  6. John Reading says:

    Seems like there are two debates happening:

    1. The importance understanding how to write native Javascript over jQuery.
    2. The importance of architecture in Javascript applications.

    I definitely feel that the first item is very crucial for developers. Especially, as new stuff comes out in ES6. Nobody should be just a jQuery coder. That’s just bad…

    As for the second, again it’s important but I don’t think Javascript or jQuery is to blame for bad architectures. Javascript (and jQuery), like most languages (if not all) is architecture agnostic and it should be! Conversely, the use of a Module pattern or MVC does not guarantee avoiding bad coding practices.

    Like I stated before, jQuery is so engrained in the js development community that many things (that are some of the things that have spoiled us) are making their way into native. And like Sasha said, it did rescue us from browser hell (document.all, anyone?) and for that I’m grateful.

    Even if I forget which properties are which sometimes, it was worth it.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>