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