jQuery: the SharePoint Band Aid

Ok, so now I’ve got your attention you eager beaver SharePoint End Users…Power Users…etc. I thought I’d just put a few things out there from the other side of the fence!

So there’s lots of hype around jQuery and SharePoint on various resources such as EndUserSharePoint.com and some of my other personal SharePoint Developer heroes: Joel Oleson, Jan Tielens, Waldek Mastykarz, Nick Swan, Paul Grenier (aka AutoSponge) and David Kitchen. There is a great summary post on jQuery here by Vedant Kulshreshtha.

To summarise, jQuery is mainly used to make SharePoint User Interface "useable" as Mark Miller put it in Joel’s comments. He does put a caveat in terms of "it having its place".

The Cons

Avoiding Development

jQuery is a serious band aid in terms of avoiding modifying the User Interface via the correct Microsoft supported approach: Solution Packges, Features, Master Pages, Page Layouts and CSS properly. If you click on a lot of the links above you’ll notice most is to tweak how SharePoint renders the out of the box page elements. This can all be done by development approach as well with a lot more control around it (versioning, deployment, performance, extensibility etc.).

Upgrade Path

The benefit of modifying the User Interface via the development approach is that you are extending SharePoint’s User Interface control elements rather than adding an extra layer between SharePoint’s rendering and the User viewing seeing it rendered. By adding this extra layer using jQuery to hack at what would be rendered you are introducing dependencies in terms of what you expect SharePoint to render. This will become an issue when you run any service packs on the SharePoint farm because there is no guarantee that things will stay the same between version!

Losing Control – "all or nothing"

This brings me on to my next point. Most of the examples displayed encourage users to place jQuery into Content Editor Web Parts within Web Part Zones. This basically means that anyone with access to a Page can add this web part, paste in the jQuery code and save it.
In short, controlling who can and cannot add jQuery is going to be a problem. SharePoint does not have the ability out of the box to block certain code blocks such as <script> from being used within Content Editor Web Parts or any Rich Text Editor element on a page for that matter.

Breaking stuff

It is also worth pointing out that if "power users" write crap code and don’t test it properly, that they will break the JavaScript for that page which could stop other scripts from loading up properly. This could cause even more useability problems. Even worse, imagine if they write recursive methods or massive loops or worse still find some code that calls the web services and puts huge load on SharePoint servers. The worst case scenarios here are endless!

Enforcing Branding

jQuery basically gives "power users" the ability to break the branding that SharePoint is meant to put back into the control of the corporation. It’s one of the selling points of the Platform, and now we’re encouraging them to hack around the efforts of consistency with Master Pages and Page Layouts.

Maintenance

As a scenario, imagine two years down the line when there has been multiple "power users" who have dabbled with jQuery and cut and paste stuff from all these resources out there to make their SharePoint User Interface "useable". It’ll be an absolute nightmare!

The other issue with this is that the scripts are being put straight into the Content Editor Web Part. There is no versioning in these web parts and I can’t see anybody trying to enforce that jQuery scripts be put in source control first by Power Users before being deployed to Production as it’ll be deemed as content.

Business Logic locked in client side

I’ve also seen jQuery being used for Business Logic, for example, domain validation of List Item columns in forms. This again can lead to business logic being locked into client side code with no versioning or unit testing! The best way forward with regards to this is calling off to Web Services…but that would require Development. So why not do it in development in the first place?

Testability

jQuery is a client side script that is executed in the browser. The only real way to test this would be to record User Interface scripts and re-run them each time. Again, this is a huge overhead…even more so if this is done manually. To put this into perspective…how would you test it’s all operational when you’ve completed the next SharePoint update where the user interface has changed?

Debugging

I’m actually quite shocked how jQuery has entered the mainstream like this. It wasn’t that long ago that JavaScript was the devil and that it was just all so hard to debug! There are some great tools around to help you these days with this, but just bear in mind that sometimes it is a nightmare to see what is going on. So if developers aren’t that happy with it (in general) how are "power users" going to cope?

Accessibility

Browsers have come along way with regards to JavaScript support and jQuery as a framework has done a great job of getting coverage across most JavaScript engines. Most Power Users who are playing with jQuery are in an Intranet environment which is typically controlled by a SOE that includes the latest update of Internet Explorer 7.0.
It is worth highlighting, for those not in this scenario to be aware that it is not going to be a reality if they have JavaScript disabled. This is especially so for Internet facing web sites where you can’t control the end users browser.

The Pros

Open Source

As a framework, you can’t go wrong with jQuery. It’s becoming the mainstream JavaScript framework of choice across many solutions these days. I appreciate that there is a lot of buzz across the whole IT world around jQuery for numerous reasons such as Microsoft taking it up for SharePoint 14 even though its an open source  project originally created by John Resig (who currently works at Mozilla).

Easy to Use

The jQuery framework is a lot easier to read and understand compared to other frameworks out there. It is also extremely light-weight and easy to snap into a page (almost too easy).

Community

The jQuery community (see Joel’s post) is growing at a huge rate because of the uptake by major platforms and also because the open source community just knows how to create buzz around products.

Web Services calls to avoid postbacks

Everyone hates ASP.NET/SharePoint Postbacks with a vengeance, the ability to refresh sections of the page without refreshing the entire screen is a godsend from a usability point of view.

 

Ok, so I’m off my soap box. But I feel that it is my duty as a member of the SharePoint community to point out the risks of jQuery in SharePoint implementations! Giving this much control to "power users" scares the sh*t out of me or as my Perth metal lover Paul Culmsee would say "leads to a wicked problem".
I’m all for "power users" to control content within the platform…I just don’t see writing jQuery as something they should control!

16 thoughts on “jQuery: the SharePoint Band Aid”

  1. You had me at hello!

    When I see a JQuery tutorial its the only time I’m happy that my place doesn’t really have any Sharepoint Power Users (yet!).

  2. Jeremy: as you know, my site offers multiple client side scripts – jQuery or not.
    Your analysis is based on the statement that “This can all be done by development approach”. In practice, for many jQuery supporters it is just not the case, for various reasons (hosted environment or strict company policies for example).

  3. Hmm…

    While I agree with many of the cons, I think that SharePoint brings jQuery on itself seeing as how its really easy to just drop scripts in a CEWP and SharePoint designer SUCKS so hard.

  4. I think that it is not black or white whether to use jQuery or not. Like everything in SharePoint: when used properly it allows you to build great stuff but when misused can lead a total disaster.

    Power users can write crappy code: but so can developers. As far as I’m concerned it shouldn’t be a reason not to go with jQuery.

    Upgrade path: I’d suppose that’s one of the most issues with using client-side programming with a non-semantic markup. If SharePoint’s markup was semantic it wouldn’t matter whether you’re on SPS, MOSS or vNext. Most of the markup would be the same and there would be some minor changes. Unfortunately the WSS team has chosen to do different. Right now we have to deal with really poor markup and building any solution on top if gives you no guarantee that it will work tomorrow when the next update shows up.

    Accessibility: that one has to do with JavaScript in general, not only with jQuery. The main idea is that you should never provide functionality based on an optional technology like JavaScript. You should always provide a working alternative in case that technology is disabled. jQuery or not: as long as you’re using JavaScript in an accessible web application, you have to test it with JavaScript disabled. The biggest problem is, that SharePoint relies way too much on JavaScript. So if you disable it, your custom jQuery modifications will be the least of your worries ;)

    One of the most important reason to use jQuery above Plain-Old-JavaScript is the cross-browser support. There are some differences in how different browsers parse JavaScript. Unless you work with JavaScript a lot and have experience with how it all works in different browsers, you will spend hours on trying to find out why some things work in IE and don’t in FF. jQuery provides you an abstraction layer: one and the same for every browser.

    To wrap it up: jQuery is great for client-side development. It makes it easier and better maintainable. As with any client-side technology: you should always consider that there might be machines where it’s not available and you should provide an alternative.

  5. /soapbox-on/ If governance groups handle permissions properly, jQuery should have no unforeseen impact on the implementation.

    Personal views of pages, web services security, and IIS can handle anything we throw at it.

    If someone has access to public views, you should EXPECT them to apply their own code to it–that’s what it’s there for. If you’re afraid of that possibility, you need to train that user and validate their understanding of the implementation before you authorize those permission levels. You don’t give a 16yo the keys to your car until they take their driver’s test (and even then you only let them drive a junky car for a long time till you’re comfortable with their experience and competence level).

    The same thing goes for SPD, web services, and anything else you think has a risk factor for your site collection.

    Plan your permissions properly and you have nothing to worry about. Educate your users and you can make them partners. Listen to your partners and respond to their needs and you can have happy users who respect you (without fearing you). /soapbox-off/

  6. Hi Jeremy. I enjoyed reading this unique perspective of jQuery. One thing you might want to correct in your post, though: jQuery is not a Google project. Its creator and lead developer is John Resig, who is currently an employee of Mozilla and never worked for Google. In fact, nobody on the jQuery project team works for Google.

    Thanks

  7. Thanks for correcting the post. Unfortunately, since you didn’t also note the update, my comment (err, comments — sorry about that double post)

  8. Actually, I could also add that some of the client side stuff I do cannot be done on the server side.
    The model I have described in this post is a real life scenario:
    http://pathtosharepoint.wordpress.com/2009/02/15/a-content-editor-web-part-for-every-home/
    I often find myself in situations where teams from different origins become partner on a project. They have their respective SharePoint environment, that they temporarily share. A CEWP will allow me to apply branding and navigation across servers for the duration of the project.

  9. Great reading, good to see some best practice thoughts on this subject. I would argue that any user with design permissions has more than enough power to break your site regardless of an embeded jQuery link. Also, many of the tried and tested SharePoint functionality already requires javascript to be enabled.

    Sadly not all organisations have proper staging/testing environments in place, yet wish to utilise sharepoints front end to leverage line of business data. Improving the client front and utilising frameworks such as jQuery is really helping achieve this.

  10. The details upstairs are really sensiblelouis vuitton outlet you remind us that anybody who gotta succeeed should make extensive social intercourseLouis vuitton bags,optimistic is a vital personality anybody gonna have!Another,it is important to keep calm when you encounter difficulty,and think out the method to solve problem! air jordan 7 You should try you best to make more friends and good friends are the bridge to help you lead to success!

  11. I had seen some post about SharePoint blu-tack and band Aid.i dont have an idea about it.what it tghe difference between them.you post is give me nice information about JQuery- band Aid.

  12. Most of the illustrations shown motivate customers to place jQuery into Content Manager Web Areas within Web Aspect Areas. This generally means that anyone with accessibility a Page can add this web part, insert in the jQuery value and save it.

Leave a Reply