Putting the Brakes on SharePoint with jQuery – Or Not (Some More)

 eshupps 10:01am, Dec 29 from TweetDeck “Sigh – Nobody listens. #jquery isn’t small or efficient. It’s still thousands of lines of javascript behind the scenes people!”

Actually, Eric, because I’m listening, I feel another need to respond! In my previous response (Putting the Brakes on SharePoint with jQuery – Or Not) to the views on jQuery you expressed in Putting the Brakes on SharePoint with JQuery, I tried to respond to your empirical testing of jQuery techniques with SharePoint.  However, with a tweet like to one above, I get a little ornery.  You’ve got a lot of people following you and probably listening to you and this type of absolute statement isn’t really useful.

jQuery is one of the shiny new pennies on the scene: no debate.  As I pointed out in my prior post, nothing comes for free.  The ease of implementation that jQuery provides requires overhead, and that overhead means some bytes down the wire.  I continue to say that the bytes down the wire are the only overhead imposed on the server itself. This *can* be a good thing, as certain processing can be distributed from the server to client machines.

The choice to use jQuery for any given task should be an informed one.  Yes, you will be sending “thousands” of lines of JavaScript (that’s 4376 un-minified, commented lines of JavaScript in jquery-1.3.2.js, or 19 minified, commented lines in the jquery-1.3.2.min.js version – what does number of lines mean, anyway?) to the client browser, just like SharePoint itself does with core.js and lots of other JavaScript files, as needed.

So what do words like “small” or “efficient” even mean, really?  In comparison to what? I started programming in 16kb.  Does that mean anything bigger is bad? No way, baby, I love having gigabytes of RAM available. But that doesn’t mean that I should use them all to add a fade in effect to some text.  As developers, we owe it to our clients to do things as efficiently as we can given the tools at our disposal.  This is always limited by things like time, money, skills, available software tools, requirements, etc.

 jthake 10:08am, Dec 29 from Tweetie “@eshupps jquery is going to still b used regardless of warnings compared 2 dev :-( mainly due to speed to implement & availability of devs”

“Warnings” is the wrong word here. “Knowledge” would be good.  We need to understand the tools that we use. Period. jQuery is useful if you want to improve the user experience on the client side in certain situations.  “Development” (I continue to get a kick out of the fact that anything other than Visual Studio-based code isn’t considered development.  Is this a Microsoft thing?) also has its time and place.

We’ve all seen bad code written in C# for SharePoint.  Whether it doesn’t dispose of objects properly, or it reads and writes directly into the SQL database or whatever, the same type of “warnings” are important.

The question is how we, and I mean each of us individually, not we collectively – there’s no one answer – can make good decisions when we try to solve specific business problems with the technology we have at our disposal.