SharePoint Development: Server Side Vs. Client Side

Traditionally SharePoint customization was preferred through Server side code as community was more in-tuned towards .NET framework solutions. As SharePoint evolved over past few years, now we see a trend of Client side development that can meet customizations need more often than not.

In my previous article, I explained how SharePoint evolved over past decade or so. Now as Microsoft  is embracing open source and other technologies, their very popular product – SharePoint has also undergone critical changes in development framework which manifested itself in SharePoint being less reliant on server side coding and its increasing adoption of client side development.

Before we delve into these two approaches, let’s understand what are Server-side and Client-side:

Server-side programming is writing code that runs on the server, using languages supported by the server such as C#, VB.NET.

On the other hand Client-side programming is writing code that will run on the client (user’s browser), and is done in languages that can be executed by the browser, such as JavaScript.

Here is the break-down of Server-side and Client-side approaches. I have organized it under different categories as area of concern. Please note that this is not an exhaustive list but it should give you a flavor of key differences.

Area of concern Server-side Client-side
Overview Server-side customizations in SharePoint is done using ASP.NET server side code. The code uses .NET Framework and references SharePoint server object model to access data and build business logic . It is written in languages like C#, VB.NET etc…

 

In contrast to server-side code, client-side scripts are embedded on the client’s web page and processed on the client’s internet browser. Client-side scripts are written in some type of scripting language like JavaScript and interact directly with the page’s HTML elements like text boxes, buttons, list-boxes and tables. HTML and CSS (cascading style sheets) are also used in the client.

 

 

General Advantage Languages like C# and VB.NET sit on top of the .NET framework and have all the benefits of object oriented architectures like inheritance, implementing interfaces and polymorphism. There are many advantages to client-side scripting including faster response times, a more interactive application, and less overhead on the web server. Client-side code is ideal for when the page elements need to be changed without the need to contact the database. A good example would be to dynamically show and hide elements based on user inputs.
Disadvantage The disadvantage of server-side processing is the page post back. It can introduce processing overhead that can decrease performance and force the user to wait for the page to be processed and recreated. Once the page is posted back to the server, the client must wait for the server to process the request and send the page back to the client.

 

Disadvantages of client-side scripting are that scripting languages require more time and effort, while the client’s browser must support that scripting language. Older versions of SharePoint (2007 or earlier) don’t support client-side object model (However there are SPServices and Other webservice (.asmx) that can aid client side manipulation to some extent). Client object model was introduced in SharePoint 2010 but it really got a complete overhaul in SharePoint 2013.
Development tool Server-side development can be done only using Visual Studio and you have to ensure that SharePoint DLLs are available to access SharePoint objects. An ideal environment is development virtual machine where SharePoint is installed on top of .NET framework. It can be done in a notepad or code editor of your choice (including Visual Studio).
Accessing objects (data, resources) You need to reference SharePoint object model DLLs in your code and use object oriented approach to access it. Client or JavaScript (CSOM or JSOM) is Microsoft generated collection of libraries that acts as a proxy to Server-side object model. Various standard protocols like REST, OData provide ways to connect to SharePoint data
Deployment Visual studio solution packages are deployed directly on the server. DLLs get copied to bin directory or global assembly cache JavaScript filed can be uploaded to document library and referenced on SharePoint page through content editor, SharePoint designer or on the page directly.
Debugging Need to attach worker process and debug using Visual studio. Debugging in Visual studio is very well integrated and you can get to the actual cause pretty fast. Modern browsers (IE, Chrome, Firefox) provide browser debugging tool as browser add-on. Generally error messages are a little cryptic and you need to do some extra research to get to the actual cause.
Integration In most cases require third party components installed on the server. Also, third party API need to be available in order to write integration code. Since, almost all third party components and application support JavaScript, integrating them to SharePoint is more technically feasible. However, it requires more effort and maintenance for complex integrations.
Authentication/Authorization Authentication and Authorization are handled as per default SharePoint authentication and authorization. You can also impersonate user which is done by plain old ASP.NET impersonation mechanism. Client side code runs under user context and there is no elevated permissions or impersonation possible directly. In SharePoint 2013 and higher versions, you can provide permissions at App level

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Close Menu