Putting the Brakes on SharePoint with jQuery – Or Not

6 minute read

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.


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).



  1. Great post, Marc. You hit the nail on the head – the point was to generate discussion and debate. I was very careful to point out that my tests were subjective and did not reflect a real-world scenario; I was simply trying to make a point regarding overuse of client-side technologies. Regardless of whether the processing happens on the client or server it *still* slows down the rendering of the page to the user and we should all be cognizant of the effect on user producivity and perception.

    I should point out that the example I used was one I came across at a client in a production scenario – this kind of thing is happening all the time. It’s not that there’s anything particularly wrong with it but the client never stopped to think about the ramifications of what they were attempting to do. I’m all for anything that improves the SharePoint interface and doesn’t require Yet Another Crappy Web Part but I think we can all agree that a little forethought is necessary before implementing any solution that might slow things down.

    Finally, I can state without reservation, having hammered on it since authoring my orignial post, that there is *something* wrong with the CEWP. It consistently takes way too long to render even with no content. I haven’t figured out the root cause yet but I’m working on it.

    I’ve added a link to your post to keep the discussion going.


    • Eric:

      Thanks for the follow up. It’s great that this set of topics is provoking some good thinking around the ideas. I’ll be interested to hear what comes of the CEWP research; it just sounds off to me.


  2. This really is a great topic and one that will certainly heat up as information workers and power users start to take advantage of what they have access to. When I gave my jQuery presentation at the Triangle SP User Group last July I heard many of these same arguments: Clent side is bad and CEWP should not hold scripts/code. I see this debate tied closely to the debate about SharePoint Designer since it involves opening up customization and possibly “development” to end users.

    I believe strongly that governance is key to a successful SharePoint implementation, but I also believe that there are no concrete rules that every org and all users should follow. In some implementations there is a need for more structure and more control over the tools. In others there is more room for experimenting and being creative. In some orgs there just are not enough IT resources to be able to accommodate “development” requests and these requests may be critical to the success of the platform. There are a lot of decision points. I say start slow and be adaptive.

  3. A very tactful, well-written response. Perhaps a little too tactful. There’s still a heavy server-side bias amongst most ASP.NET developers I talk to, and someone needs to set the record straight. It’s not just a question of a lack of access to the server that justifies jQuery. It’s using the most appropriate technique to solve a problem. (In this case, style the ms-alternating rows using CSS.)

  4. First of all. Thanks very much for your useful post.

    I just came across your blog and wanted to drop you a note telling you how impressed I was with the information you have posted here.

    Please let me introduce you some info related to this post and I hope that it is useful for community.

    There is a good Share Point resource site, Have alook


    Thanks again

  5. I do lots of jQuery stuff on Sharepoint, but mainly to work around Sharepoint issues at the presentation layer integrating stuff like jQuery Lightbox and anly seldom to do proper heavyweight processing (webservices)… I also did rewrite MOSS Variations using bits of jQuery
    IMHO, it’s excellent at the presentation level but for the back-end it’s not always appropriate …


Have a thought or opinion?