Apps and other SharePoint client-side development(6 min read)

An expanded client-side development model, which includes Apps as well as techniques such as remote provisioning, was released with SharePoint 2013. SharePoint Online does not support server-side development, apart from limited sandbox solutions, so client-side development must be used, whereas for stand alone SharePoint both the new client-side model as well as the original server-side model are available.

I have used several of the different alternatives for client-side development, and thought I would provide my overview of when each is suitable and my current preferred approaches.

Advantages and disadvantages of SharePoint client-side development

First, an overview of the advantages and disadvantages of the SharePoint client-side development model, both online and on-premises.

The main advantages of this model are:

• Components are compatible with SharePoint Online. The online service only supports client-side development (plus some limited support for sandbox solutions); using the same model for on-premises gives consistency between the environments.

• Development environment is not dependent on SharePoint. Normally setting up a development environment for SharePoint is complex, and requires a high specification machine (the requirements for a full SharePoint 2013 development machine include 24 GB RAM). In contrast, client-side development can be done on any machine with Visual Studio 2012 or above installed.

• Future upgrade is easier, as all customisations are in the content databases and there are no server-side dependencies. A frequent cause of difficulty during upgrade is installing all the server-side components and customisations.

Some of the disadvantages of this model are:

• There is no tool support for SharePoint-specific components. Visual Studio includes several design tools that help with server-side development (both sandbox and full trust solution packages), but currently provides no support for client-side development. (On the other hand, general tools are easier to use due to the reduced dependency on SharePoint, for example unit testing, continuous deployment, ASP.NET MVC support, third party frameworks, and Nuget packages.)

• Developers generally have many more years experience with server-side development, and there is both less personal experience and general knowledge available on the Internet. This means development is slower, and hiring experienced people is more difficult.

There are two type of Apps that can be created, SharePoint-hosted Apps and Provider-hosted Apps, as well as simple individual scripts with remote provisioning. The following table contrasts the methods and provides of guide of when each is suitable.

SharePoint client-side development alternatives

Individual scripts with remote provisioning	For most solutions it is sufficient to use individually deployed scripts. These use basic ECMA Script (JavaScript), leveraging associated frameworks (such as jQuery); and the JSOM and REST interfaces are used to move data to and from SharePoint. Remote provisioning (either PowerShell or a C# application) can be used for automatic deployment of scripts into both test and production environments. Adding components to pages can be conditional based on URL or done with a single DIV placeholder in a Script Editor web part (although this can also be automated).
SharePoint-hosted Apps	Use when a scripted solution needs to be packaged up together and repeatedly deployed, especially by end users. This has the same capabilities as a scripted solution (above) but is in a reusable package. Examples could be a branding package that includes multiple files and configuration and needs to be used across multiple sides, or a widget that multiple individual sites will want to deploy copies of. If a solution only needs to be used once then the complexity of an App package may not be needed and remote provisioning of individual scripts (above) is sufficient.
Provider-hosted Apps	Use when capabilities not available in a browser are required, such as server-side libraries and code. For example if a particular .NET library needs to be used such as Word document generation, PDF generation or a graphics package, or where connection is required to third party data sources or services. One specific case is where access is required to the SharePoint tenant administration API, such as for site collection creation, which is not available from browsers. Security for on-premises high trust Provider-hosted Apps requires specific certificate configuration and a separate App Host server (with standard IIS) is required. (It is also possible to use ACS authorisation with on-premises Provider-hosted Apps, but the requirements can be more complex.)

Note that while Apps are required for SharePoint Online, for an on-premises installation, the full range of older server-side solutions is still available and provide the same capabilities as Provider-hosted Apps, although without the isolation and upgrade benefits.

Recommendations

Simple scripting should be a sufficient solution for most cases, with SharePoint hosted apps used where packaging and reusability is required. The complexity of Provider-hosted Apps is only required where one of the specific cases needs to be addressed, such as use of a third party data source or service.

For remote provisioning, the PowerShell extensions from the Office Dev Patterns and Practices library, https://github.com/OfficeDev/PnP, can be used.

Examples

Individual scripts

Add a Script Content web part with a snippet similar to the following, with any parameters passed as data attributes:

<div id="xyz-widget1" data-list-name="Announcements" />

The element can then be tested for and used in a global script, xyz.js:

(function (XYZ, $, undefined) {
  function populateWidget1() {
    var widgetDiv = $("#xyz-widget1");
    var listName = widgetDiv.data("listName");
    // ...
  }
  $(document).ready(function() {
    if ($("#xyz-widget1").length > 0) {
      populateWidget1();
    }
  });
})(window.XYZ = window.XYZ || {}, jQuery);

Provisioning

Example of simple commands to provision a script from your local machine to SharePoint, using the OfficeDev PnP PowerShell extensions (given appropriate values for $Url and $SourceFolder; also note that credentials can be stored as generic credentials in the Windows Credential Store for a fully automated script):

$credentials = Get-Credential
Connect-SPOnline –Url $Url –Credentials $credentials

Add-SPOFolder -Name "Scripts" -Folder "_catalogs/masterpage"
Add-SPOFile -Path (Join-Path $SourceFolder "Scripts\xyz.js") `
  -Folder "_catalogs/masterpage/Scripts" -UseWebDav `
  -CheckOut -Publish -PublishComment "Published by script"

The scripts can then be loaded as a ScriptLink custom action, as discussed in Ways to load jQuery in SharePoint.

To set the ScriptLink using remote provisioning:

$credentials = Get-Credential
Connect-SPOnline –Url $Url –Credentials $credentials

$existing = Get-SPOCustomAction -Scope "Site" | ? { $_.Description -eq "ScriptLink XYZ" }
if ($existing) { $existing.DeleteObject(); Execute-SPOQuery; }
Add-SPOCustomAction -Description "ScriptLink XYZ" -Location "ScriptLink" -Title "X" `
  -Group "X" -Sequence 0 -Url "X" -Scope "Site"
$action = Get-SPOCustomAction -Scope "Site" | ? { $_.Description -eq "ScriptLink XYZ" }
$action.Name = "ScriptLink.XYZ"
$action.ScriptSrc = "~sitecollection/_catalogs/masterpage/Scripts/xyz.js"
$action.Sequence = 10100
$action.Update()
Execute-SPOQuery