views:

240

answers:

9

Maybe someone more familiar with the topic can help me to simplify or write the question correctly. We are looking for metrics on JQuery or even other JS Frameworks in comparison with the use of straight javascript. I don't beleive in the lines of code metric, never have, but I cannot think on anything else to measure it.

Function Points (jquery) = Jquery-LOC
Function Points (JS) = JS-LOC
+1  A: 

The 'time saved' metric is as good as any.

Using jQuery, you write less, (I mean it's in jQuery's motto even!), but LOC is a ridiculous measurement.

The reason I use jQuery is for the browser compatibility. If I don't have to write that myself, obviously I save time.

Noon Silk
+1  A: 

How about how productive the developer is? How easy is it to find someone to support the code base.

JBrooks
Yes. Perhaps measure the number of job applicants who are familiar with jQuery vs those familiar with your in-house equivalent code. :)
Nathan Long
+2  A: 

It depends on what you're writing. Want more precision? Exactly 12 lines.

Andy Gaskell
Not 42?
nilamo
_Maybe_ 42 if you minify.
Andy Gaskell
+3  A: 

You are right to doubt the lines of code metric, although, assuming you discount jquery itself, it will save substantial new lines of code.

FAR more importantly, it will reduce the amount of the DOM-soup code you have to write and test by hand across 5 browsers or so. It is a massive time saver, and a massive bug reducer.

Triptych
A: 

I don't think LOC is a very applicable metric, either, but being able to write things like $('#my_id') vs document.getElementById('my_id') makes an enormous difference in the long run—even in the short run for that matter.

theIV
+10  A: 

To attach a click handler using standard javascript, you might try something like this:

var myelement = document.getElementById("clickme");
function myClickHandler (evt) {
  var evt = evt || event; // ie uses a global instead of
                          // passing an object as a param
  (evt.target || evt.srcElement).style.width="110px";

}
if (myelement.addEventListener) {
   myelement.addEventListener("click", myClickHandler, false);
} else if(myelement.attachEvent) {
   myelement.attachEvent("onclick", myClickHandler);
} else if(typeof myelement.onclick === "function") {
    (function () {
      var oldfunc = myelement.onclick; 
      myelement.onclick = function (evt) {
          var evt = evt || event;
          oldfunc(evt);
          myClickHandler(evt);
      }
    })()
} else {
   myelement.onclick = myClickHandler;
}

or try to do something similar using jquery

jQuery("#clickme").click(function(evt){ jQuery(evt.target).css("width",110); });

You could argue that the first example code is a stupid thing to write every time you want to assign a click handler. Why not refactor that out into its own standard function, and reuse that? then you have a central function you can debug without having to rewrite every single instance once you've found something wrong.

This would be a very good argument, and that's exactly the point of a library like jquery. You save time by not writing this verbose boilerplate that's absolutely necessary if you want your code to work cross browser. You save time by not having to debug it. You save time by- if you do have to debug it, you just have to patch one function in jquery and file a bug report for the next version. If there's something wrong with the event binding code, then it's just one guy that has to change one bit of code, rather than thousands of people that need to change millions of bits of code. And when someone points out that you should test addEventListener first, the point becomes moot, because jQuery already does the established "correct" thing. And if it doesn't, it will in the next version.

jQuery won't help you on the really difficult domain specific problems, but for grinding through every day dom manipulations, it's better to use a library function than trying to wing it "close to the metal". There's too many cross browser splinters sticking out, and too many dumb verbose dom APIS, and it's too stupid to solve problems that have already been solved, over and over again.

You need SOME kind of library (not necessarily jquery) just to stay sane.

Now how much time and effort do you save, exactly? Who knows? it's immeasurable. How many times do you have to bind an event handler? How many times do you have to do any of the other things that jQuery provides in a simple function? One is strongly dependent on the other.

If you ever find a way to measure programmer productivity, do let us know, though. I think we'd all be very interested. In any case, we know from these objective facts, and our own personal subjective experiences that it's probably quite a substantial amount of time.

Breton
Standard `addEventListener` is usually tested **before** proprietary (and rather deficient) `attachEvent`. This ensures that browsers like Opera, that copied some of IE's methods (`attachEvent` in this case) end up using a more efficient implementation. On a side note, your third branch can be easily removed, since browsers not supporting addEventListener/attachEvent are considered ancient nowadays. In fact, jQuery doesn't account for such scenario, which makes your comparison a bit unfair ;)
kangax
You are of course right, but it kind of helps proves my point, doesn't it? My example isn't about the lines of code. It's about the pointlessness of trying to solve a problem that someone else has already figured out better than me, and the wasted effort involved in such attempts.
Breton
I added some stuff anyway, to respond to your criticism.
Breton
+1  A: 

Using JQuery or other JavaScript libraries, your application will have many more function points and have many more lines of code. Why? Because you will be doing things easily that you hadn't thought possible or feasible before you started using these libraries. This will encourage you to write more features, rather than punish you for trying, as programming it from scratch does.

They're that good.

Steven Huwig
A: 

The question is basically meaningless without context.

If you use jQuery to do something in four lines that would have otherwise have taken 20 lines, you fail by having added (on version 1.3.2) 4376 lines of jQuery to save 16 lines of your own code.

On the other hand, if you save writing 9000 lines of code by using jQuery then you have a net gain.

It may even be that the 4376 lines to save 16 lines are worth it if it would take you three months to learn what's necessary to write those 16 lines. Alternatively, it may be that it's worth taking the three months to learn enough to avoid writing 9000 lines where 20 would do.

I think you need a more complex metric.

NickFitz
Then again, in terms of browser load time, if you point to Google's hosted jQuery file, your user may download 0 lines (if they already have that file) instead of the additional 16 lines of your code.
Nathan Long
+1  A: 

It's a comparable amount to that of a length of string.

Rich Bradshaw