I have been just hanging out at the Rencore office as my daughter is doing a work experience there. During a chat, they’ve just told me about their recent “State of SharePoint and Office Customizations Report 2018” and one section that really interested me was their analysis around which development approaches (frameworks, libraries, tools) are being used in 2018.
If you’d ask me to guess I’d have said server side code would’ve still been in the top 3. I know SharePoint Online is taking off like rocket fuel, but I never imagined coding on the server was so infrequently used nowadays. In fact, it’s actually bottom with just 20% of respondants stating they use it.
Here’s what Rencore had to say in their report …
“In time for our 2016 survey, the SharePoint Framework had just been released with the purpose to guide internal or third-party developers within organizations to build customizations to best practice guidelines. With Office 365 and SharePoint Online and client-side development gaining popularity it seemed a sensible move. In 2016, many of the respondents were certainly aware of the SharePoint Framework and tried it out, but for some, it was deemed unrelated to their organization’s approach at that specific time.
Fast forward to 2018 and the SharePoint framework is featuring prominently in customization builds across the globe. However, there are still many more development models and languages being used depending on the specific type of customization that organizations are creating.
The graph below represents development approaches that are currently in place when tackling new customization builds. The top five approaches for developing SharePoint customizations range between 63% and 46% in usage, and the relatively high numbers and gradual decrease between each approach shows that many organizations are using more than just one development model to attend to various customizations across multiple platforms.
The SharePoint Framework which has 45% usage sits just outside the top five, but in context, this can be considered a positive trend as it goes from being a new concept in 2016 and with little usage to a significant SharePoint customization development approach two years later. Furthermore, we can see that client-side CSOM and Client – side JSOM make the top five with 53% and 46% of respondents. This shows that client-side development is continuing to be adopted by individuals who customize SharePoint. In contrast, only 20% of our respondents use server-side SSCOM.”
The top 11 SharePoint Development Approaches …
1: REST API – 63% use this
This approach allows you to do basic CRUD (Create, Read, Update, Delete) operations against SharePoint objects such as Sites, Lists and Libraries. The key thing is that REST is (usually) a remote call which means that you’re calling endpoints that Microsoft fully support. Get to know the SharePoint REST service.
2: Powershell – 58% use this
Powershell is the scripting tool of the SharePoint IT Pro and can be used to do all manner of operations against SharePoint, both locally and remote. If you want to use Powershell with SharePoint then take a look at the really popular SharePoint Pnp library on Github.
3: Client side (CSOM) – 53% use this
CSOM was introduced as a way to programmaically perform CRUD operations remotely against SharePoint. I think its main purpose was to give developers an easy to learn alternative to using the Server-side Object Model. There are a few ways to use CSOM with the main ones being a Javascript library (detailed in 5), REST API and also .Net redistributable assemblies. Learn how to complete basic operations using SharePoint client library code.
4: Content Editor Webparts / Javascript Webparts – 52% use this
The Content Editor Webpart has been around since the very early days of SharePoint. Its purpose is to be able to add HTML to an existing SharePoint page. In other words, it’s a dead easy way to add tables, lists, text, pictures, etc. to a page. This also means Power Users have the ability to get involved in the customisation of SharePoint. Read more.
5: Client Side JSOM – 46% use this
The Javascript Object Model allows you to perform CRUD operations remotely against SharePoint using Javascript. This is ideal for web developers. Learn how to complete basic operations using Javascript library code in SharePoint.
6: SharePoint Framework (SPFx) – 45% use this
SPFx is the newest development framework to develop on SharePoint with. Microsoft describe it as “The SharePoint Framework (SPFx) is a page and part model that enables client-side development for building SharePoint experiences. It facilitates easy integration with the SharePoint data, and provides support for open source tooling development”.
SPFx is growing in popularity and I think it’s fast becoming the “Go to” way to develop on SharePoint. If you want to know more then I strongly suggest purchasing one of Andrew Connell’s online courses. He’s one of the world’s best trainers and has been doing SPFx from the very start. Check out his ‘Mastering SPFx course‘.
7: Customization through the SharePoint User Interface – 43% use this
I think this one may be scored a little low if I understand it properly. This approach covers those users that edit SharePoint pages by carrying out activites usch as adding and customising Webparts on a page. This approach is great because it gets things done fast. However, if you’re an organisation that uses test servers then you have the problem of being able to move those changes to your live servers.
If you’re interested in migrating your customizations to the Cloud then this checklist by Rencore is worthy of a read.
8: SharePoint Designer – 38% use this
SharePoint Designer has been around for years and will have been used in 1000’s of companies. It’s a seperate application that lets you connect to SharePoint to customise it. Microsoft never released a new version for SharePoint 2016, however, you can still use SharePoint Designer 2013 to customise SharePoint 2016.
9: JSLink – 30% use this
JSLink is an approach that allows you to customise the rendering of a List Views and List Forms. You do this by utilising Javascript, HTML and CSS.
10: Microsoft Graph – 28% use this
Microsoft Graph is the unified API to perform operations against all of the Microsoft 365 applications including SharePoint. Learn more about Microsoft Graph.
11: Server-side (SSOM) – 20% use this
Now this one has REALLY surprised me. This approach is where you use server-side .Net libraries to perform CRUD operations over SharePoint. These changes are usually packaged up in your own .Net assemblies and deployed as Farm Solutions (WSPs). This isn’t something you can do on SharePoint Online however, you can still do it on all version of SharePoint. If you ever see yourself moving to Office 365 then don’t do this as it will cause you a migration headache.
Learn More in the State of SharePoint & Office 365 Customizations Report
If you haven’t seen the report here are a few more questions that are answered:
- Are people confused or generally unsure what best practice governance means for their specific SharePoint environment?
- Due to multiple models for developing code and building apps, is managing the safety of this code more difficult?
- Are developers struggling to build custom solutions in a way that will be ‘future proof’ and conform to best practice?
- Is the rise of ‘citizen development’ putting companies at risk?