Putting the Brakes on SharePoint with jQuery – Or Not

Eric Shupps posted what some folks have considered a provocative article yesterday to his blog entitled Putting the Brakes on SharePoint with JQuery.

First of all, I’m not going to trash Eric here or say that he is misguided or any of the other Internet flame-a-thon techniques.  Eric knows what he is talking about; I just want to offer my perspective on the thoughts he has shared.  Eric is a SharePoint MVP – I’m just a shlub out here doing what I can to rid the world of non-collaborative applications.

On many levels, I think Eric and I can agree.  Bad code is bad code is bad code.  There’s just no way around that.  (Patient: “Doctor, doctor, it hurts when I do this.”  Doctor: “Don’t do that”.)  However, there is more than one way to skin a cat (which is really a horrible analogy when you think of it: what can you do with a skinless cat?) and you should consider all of the tools at your disposal for any given task.

One of the new tools in our arsenal these days is jQuery.  Yes, I said “ONE of the new tools”.  I’m particularly enamored of it because I find that I can do things from what I call the “front parlor” or the “Middle Tier” that I didn’t have good ways to implement before.  In many cases, the powers that be have shut off access to the back end and there is not an option to deploy managed code to the server.  jQuery, specifically working with the Web Services as I do with my jQuery Library for SharePoint Web Services, allows us to – dare I say it — “get around” these constraints.

One of the benefits of client-side code that few people talk about is the ability to offload some of the processing to the largely dormant CPU sitting on the user side.  (I’m searching for aliens with SETI@Home as I type, and I see nary a flicker.)  With judicious use of client side code, we can actually reduce the load on the server and let it do more “serving” rather than calculating.

So, let’s get to brass tacks.  What specifically about Eric’s post has gotten me fired up to write this post?

Will It Scale?

Eric’s question of “Will it scale?” – Back to my point above about the supercomputers sitting on our desks (mine is a paltry old Dell laptop, by the way, with an Intel Core2 T5500 CPU running at 1.66GHz – about time for an upgrade).  The scaling in this case needs to happen on the client side.  We’re asking the client computer to do more, not the server in many cases.  Sure, using AJAX or RPC puts a load on the server which absolutely needs to be considered carefully, but again, we’re asking the relatively dormant user computer to do more, and asking the server to do less to provide a richer user experience.  (I hope the goal is a richer user experience and not just a bunch of spinning, flaming icons like circa 1996. Paul Daro – your demos live on in my memory!) So the key question here is what the *client* computers’ profiles are.  We’re not asking the server to do anything other than send a few more bytes per request down the wire.

Content Editor Web Part (CEWP) Bugaboo

I think that the CEWP taking 4 seconds is some sort of bugaboo.  If this was actually the case pervasively, we and/or Microsoft would have all figured a way around it by now.

Simple jQuery Test: Alternating Background

The test to change the background color of every other item in the list view is sort of a weird example, but let’s go with it.  In this example, as I see it, you have four implementation options:

1. Don’t do it – This is one option that we should always consider.  Regardless of what the client wants, should they actually do it?  Does this contribute to the user experience? Does it make the site better? (OK, I’m being a little bit boorish here, but consider it.)
2. Use CSS – A simple adjustment to the CSS would accomplish this task nicely.  For the record, this is what I would do in this example.
3. Use jQuery, as Eric does in his example – OK, so we decide to use jQuery.  Eric says that the page takes a second (or less) longer to load.  I’m wondering about this, because by using the $(document).ready function, the page ought to load and *then* the DOM manipulation should start.  The only discernable load different ought to be caused by the additional bytes being sent.  In most enterprise environments this should be negligible.
4. Write a custom, deployed Web Part – This might be the party line solution, though totally overkill for this example.

My point here is that there are four (and you may think of options 5 and 6 and…) options.  No one of them is the solution for every situation.  For this to be a fair test, we’d need to implement each of the four approaches and benchmark them against each other, taking into account many other variables, like network topology, geographic distribution of the users, target browser types, different client machine characteristics (CPU speed, monitor type, etc.), and on and on.  *Any* solution is going to add some processing time; nothing comes for free.

Concurrent User Test

In this test, Eric “configured a single-page web test in Visual Studio Team Test and dropped it into a load simulation of 100 concurrent users over a three minute period”.  To me, this is a highly unrealistic test.  Here’s why: jQuery is a client-side toolset.  The only way to test it realistically is to have 100 client machines available to you, humming along at a realistic load level that represents the actual user community.  No loading on a server is going to give you a realistic read.  So adding the 101st, 102nd, 103rd, user to this test would continue to degrade the performance.

Test, Test, Test

On this Eric and I agree, but I expect that my view is a bit different.  Yes, test, test, test, but there is no replacement for real world experience.  I admit it, I’m an old guy with grey hair.  I’ve worked with more programming languages than I could ever count on probably an equally mind-boggling number of hardware platforms.  There are some things which are good ideas and there are some things which are bad ideas.  You can test, test, test, but I would argue that there are whole categories of solutions that should never be built in the first place.  I’ve had the [good, bad] fortune to be asked to fix many of these over my career, and SharePoint is no different in that respect.  I’ve seen some just plain offensive things done with SharePoint by people who have all the credentials in the world (yes, even MVPs and Microsoft Gold Partners).

There’s no substituting youth and vigor for experience some of the time.  One of the great things about the SharePoint community is all of the bright young players it attracts, and I defer to that talent where it is merited.  Smarts is smarts, and I like to think I know how to recognize ’em.

So, yes I love what jQuery lets me do, but there are all sorts of things that I just wouldn’t want to try because they would be bad ideas.

Conclusion

Eric, if you wanted to start a debate or make people think with your post (and I hope you did), then you’ve accomplished your object.  That’s the wonderful thing about them there InterWebs: we all get to say what we want and anyone can decide on their own if they want to read and/or listen.  There have been some Twonversations about your post, and you’ve provoked me to write this one.  Maybe someday we’ll have the chance to work together and talk about the trade-offs of all of these approaches, and I’d relish that opportunity.

UPDATE 2009-12-29: If you’ve read this far, then you’ll probably be interested in my follow on post: Putting the Brakes on SharePoint with jQuery – Or Not (Some More).