SharePoint Development without JQuery

Why SharePoint developers love JQuery

Today many businesses are moving their IT infrastructures to the cloud. Looking at the reduced cost of licenses, less overhead of server maintenance, high level of security, awesome integration of corporate tools like Exchange, Lync, yammer and guaranteed uptime for almost 99.99%, most of the companies are moving to the cloud platform of SharePoint.
Full length rear view of brunette woman in formal clothes who is looking at the business flowchart on the black chalk board. The concept of business ideas development.

But you have to play with this kid with his own rules. Certain technologies are not deployable to SharePoint online. In other words, we cannot deploy the code solutions in central administration like the way we used to do in on premises environment of SharePoint. Also, Microsoft has recently announced that server based sandbox codes are not allowed on SharePoint online. These are the technologies that SharePoint developers use them for many years.

Looking at these limitations, most of the modern developers are moving towards the client based solutions for SharePoint development. But most of the developers are from the trend of ASP.NET based solution development like web parts, timer jobs, event receivers, custom workflows. They feel a bit difficult to learn technologies like JavaScript. So, the simplified approach they take is to start using jQuery framework, the vanilla JS!

JQuery hell!

Using these plugins are good but in most of the real life scenarios, it becomes overhead to maintain pages created on top of these plugins. For example, if you are using 10-12 web parts on a page, all are using their own version of jQuery. An average jQuery file is approximately 60kb, adding lots of redundant data and unwanted heaviness on the page. Also, there might be chance of conflict between plugins. Assuming, we can neglect these issues for some time and focus on good things about jQuery.

The real power of jQuery comes handy when we can load the data from lists/ libraries without the burden of page load. The real power lies in AJAX calls of jQuery. AJAX is the most widely used techniques to retrieve data and do CRUD operations in SharePoint. So, this makes jQuery, a very reliable tool to have on the page. Still, the question of page performance remains a major concern, unwanted issues due to multiple jQuery files on the page is another problem that sometimes cannot be solved on real life scenarios.

JQuery alternative in SharePoint

So, finally its developers call whether to go with or without jQuery. Going without jQuery might lose the chance of doing CRUD operations in SharePoint online. But this is not completely true. After doing some research, I did come to know that, we can do AJAX operations without jQuery as well. It drastically improves page performance and avoids conflict with other codes. The size of the code get reduced to just 1-2kb and no multiple add on’s needed. It can be done with the help of XHTTP requests.

Her name is XMLHttpRequest!

All modern browsers support the XMLHttpRequest object. The XMLHttpRequest object is used to exchange data with a server behind the scenes. This means that it is possible to update parts of a web page, without reloading the whole page. All modern browsers (Chrome, IE7+, Firefox, Safari, and Opera) have a built-in XMLHttpRequest object. I have wrapped the core JavaScript based functions to perform CRUD operations in SharePoint. Refer below:


How to use XMLHttpRequest













Final word

I’m not against using JQuery on SharePoint projects and I used it on many SharePoint development projects as well. but because SharePoint is an end user driven platform, you have no idea in which page your code will eventually landed. I see many problems with commercial SharePoint plugins from different vendors that when you place them on the same page, you face various unseen problems.

So I prefer to not use JQuery on my SharePoint project and back to basic old school JavaScript (is it old school : – ) in order to do my job. It takes more time, more effort to drive the project, but it worth the effort! You will have more robust application


View all posts by

Leave a Reply