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".
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.).
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.
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.
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?
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?
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).
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!