SharePoint development: 5 trends to follow

SharePoint development: 5 trends to follow

August 28, 2020

Sandra Göğer

Digital Experience Strategist

SharePoint development has changed substantially over the years. SharePoint owners who started using the platform in the early 2000s now have at their disposal multiple SharePoint On-Premises versions in addition to cloud-based SharePoint Online, Office 365, and Microsoft 365.

Working with the server versions of the platform, companies often turn to SharePoint consultants to create custom solutions adapted to their collaboration and business needs. Taking the out-of-the-box platform as a starting point, SharePoint developers have to toil over it to create a corporate intranet, a document management system, or a learning hub.

As for SharePoint Online, Office 365, and Microsoft 365, these platforms come with a more mature out-of-the-box design and features, so developers spend less effort on developing a solution on top of these versions from scratch. However, they still need to face multiple challenges related to the customization of this globally available cloud ecosystem, which makes SharePoint professionals shift to alternative development methods.

In this article, we will analyze the key trends in SharePoint development that will help companies succeed in building, managing, and using modern SharePoint-based solutions both in the cloud and on premises.

1. Saying no to farm solutions

Companies that run both on-premises and cloud-based SharePoint deployments, as well as those switching from on-premises implementations to cloud-based ones often face a common issue. They try to handle the cloud and on-premises SharePoint development with the same toolkits and approaches. Why is this dangerous? Because if we compare SharePoint On-Premises vs SharePoint Online, we will find critical differences in their deployment logic.

When companies acquire SharePoint Server, they become the sole owners of their solution. It means that businesses can decide on their own approaches to SharePoint design, customization, and management.

For many years, SharePoint On-Premises customizations were based on two types of SharePoint solutions: farm and sandboxed ones.

Farm solutions contain code that is deployed to SharePoint servers and affects the entire SharePoint farm. Farm solutions can exist only within server implementations; they are suitable for developing custom server-side SharePoint features, web parts, timer jobs, and event receivers.

Sandboxed solutionscontain code that affects a solution at the site collection level. Sandboxed solutions are suitable for designing SharePoint web parts that aggregate data from multiple SharePoint lists, creating a workflow in SharePoint Designer, or developing a new ribbon element. Unlike farm solutions, sandboxed solutions can run both on-premises and in the cloud. There is a restriction, though—only no-code or declarative solutions can be deployed in SharePoint Online.

All in all, neither farm nor code-based sandboxed solutions fit the SharePoint Online logic because they could affect the entire cloud environment, which is inadmissible. For this very reason, Microsoft recommends organizations to smoothly transition to alternative SharePoint development methods.

SharePoint add-ins are among the most popular approaches. Add-ins don’t contain custom code that runs on SharePoint servers, which ensures they can have no impact on organizational servers or the overall SharePoint Online performance. Currently, applying the SharePoint add-ins development model, SharePoint specialists can create almost all types of custom components, be it a SharePoint page, a web part, a list, or a workflow.

There are two types of SharePoint add-ins: SharePoint-hosted and provider-hosted ones.

  • SharePoint-hosted add-ins live in the web within SharePoint and can contain only JavaScript code.
  • Provider-hosted add-ins come with at least one component (for example, a web app or a database) hosted elsewhere outside the SharePoint farm or SharePoint Online deployment. Organizations are free to choose hosting frameworks and cloud services to build and manage their add-ins. It’s not obligatory to use the Microsoft technology stack. Thus, an add-in can reside in Microsoft Azure or in the AWS cloud equally well.

Provider-hosted add-ins come with at least one component (for example, a web app or a database) hosted externally from the SharePoint farm or SharePoint Online subscription. Organizations are free to choose hosting frameworks and cloud services to build and manage their add-ins. It’s unnecessary to use the Microsoft technology stack either. Thus, an add-in can reside in Microsoft Azure or in the AWS cloud equally well.

Undeniably, today the number of companies preserving their SharePoint On-Premises deployments is still impressive, that’s why SharePoint developers keep using farm solutions heavily.

What types of customizations does your organization currently have in production with SharePoint & Office 365

However, it is high time for the professional community to rethink their server-based development approach and start using SharePoint add-ins and client-side (CSOM and JSOM) models more actively. Modernizing your development approach will allow you to have more flexible deployments, always ready to be moved to the cloud and adapted to the cloud requirements if necessary.

We know how to develop with SharePoint the right way

Contact us

2. Leveraging SPFx and PnP best practices

To support organizations in their transition from traditional server-oriented to modern SharePoint development, Microsoft launched a brand-new development approach based on the SharePoint Framework (SPFx).

According to Microsoft’s definition, SPFx is a page and web part model that provides full support of client-side SharePoint development and easy integration with SharePoint data. Being client-side-oriented, SPFx also enables developers to use a variety of open-source frameworks and technologies. For example, those can be JavaScript technologies, such as Node.js, React, Knockout, or Angular.

But what is the greatest benefit behind SPFx?

The framework sets companies free from the traditional .NET-centric development. It means that even those businesses that never engaged .NET developers can now handle SharePoint development by involving professionals with different technological skills, including programmers specializing in JavaScript technologies.

At the same time, even seasoned .NET developers need to extend their knowledge to handle SharePoint customizations. For instance, it’s highly recommended to dive into TypeScript, which is, together with JavaScript, the key language of SPFx artifacts. What’s more, SPFx is also compatible with SharePoint 2016 and 2019, which proves once again that server-side development absorbs the cloud trends.

SharePoint Patterns and Practices (PnP) is another popular initiative that represents the global effort of SharePoint engineers. Guided by Microsoft’s SharePoint engineering team, PnP has already gained a mature worldwide community that keeps on finding more optimal development approaches. Although PnP is not a specific technology but a global initiative, it is oftentimes used as a synonym of SPFx and embraces the overall modern vision of SharePoint customization.

The stats reflect an increasing interest and use of SPFx and PnP technologies within the professional community. If back in 2016 most businesses didn’t consider SPFx as a suitable development toolset, just two years later PnP became the key third-party framework for SharePoint professionals.

3. Putting more into SharePoint testing

SharePoint testing was never among widely discussed SharePoint topics. There is a surprising reason behind this indifference towards SharePoint testing. Considering SharePoint as a ready-made product from Microsoft, businesses don’t think their SharePoint solutions need as much testing as custom software. As a result, we can see that the majority of companies initiate only occasional testing of their SharePoint environments, while 15% don’t perform testing activities at all or simply don’t know if there is any SharePoint testing in place.

How do you test your customizations

The lack of SharePoint testing entails three critical issues:

  1. Poor performance. When tuning their SharePoint On-Premises deployments, companies often go for quite radical customizations all the way from custom design to revamping of SharePoint components, including sites, libraries, and workflows. At some point, a SharePoint solution can become a mish-mash of features developed and deployed by different people. If customizations are not tested well, performance issues will pop up sooner or later, and restoring the normal operation of the platform won’t be easy at all.
  2. Integration inconsistencies. SharePoint rarely functions as an isolated solution. Typically, SharePoint serves at a central hub connected to other enterprise solutions, particularly so, if we speak about a SharePoint intranet. Untested customizations not only impact the normal functioning of the integrations but also affect third-party solutions. Say, if there are post-customization security loopholes in SharePoint, they can let malicious actors into the connected enterprise systems, which dramatically increases the risk of severe security breaches.
  3. SharePoint governance disparity. Testing makes an important part of the overall SharePoint governance strategy. Testing should act as a litmus paper showing the quality of the deployed customizations and allowing businesses to build consistent solutions where every component follows the logic of the system. If there are no formal requirements for testing activities, every new customization will be a pig in a poke. If a company outsources their SharePoint development without any testing guidelines, they risk getting solutions built according to different logic, programming languages or designs.

Weighing all the risks stemming from the lack of well-established testing activities, it becomes obvious that SharePoint owners should definitely prioritize SharePoint testing.

4. Bearing with Microsoft’s policies

Developers who got used to managing their on-premises SharePoint deployments expect having the same level of control over SharePoint Online solutions. That’s when the frustration comes.

When performance issues happen within a server-based deployment, SharePoint admins can quickly access their in-house infrastructure to find the root causes of their troubles. Generally, specialists can manage emerging issues on their own by finding workarounds and modifying the platform’s code. However, no SharePoint professional, perhaps except Microsoft’s own employees, can access SharePoint or Office 365 physical deployments to reveal the problem.

Performance is a frequent issue for developers of SharePoint Online customizations. Even though Microsoft keeps expanding the geography of its data centers, it’s still impossible to ensure the equally stable operation of the cloud suites across the globe, so certain slowdowns are possible. If such issues occur, it’s important to understand and explain to customers that local development teams just can’t do anything about it but wait until Microsoft handles the issue.

When it comes to custom features, SharePoint developers can also face various issues at the technology level. If a customization looks healthy and well-designed but SharePoint Online just won’t accommodate it, there is no other chance for SharePoint developers to understand why their solution doesn’t work but contact Microsoft. The problem is that developers can wait for the answer for several days, which can affect the customization speed and delay the release. Moreover, there is no guarantee that the issue will be addressed if it doesn’t make part of the Microsoft development roadmap.

While developing custom solutions, our team often faces SharePoint Online operability issues inherent to the cloud nature of the platform. The SharePoint performance depends heavily on Microsoft datacenters location and we, as developers, can’t improve it. We also often deal with SharePoint Online customizations that work inappropriately after updates are rolled out. However, as we can’t control these changes, we just prefer sticking to the Microsoft recommendations to minimize risks of inoperability.

Sergey Korolev

Sergey Korolev

.NET and SharePoint project coordinator at Itransition

5. Expanding knowledge non-stop

As we have already mentioned, changing the development approach also implies new knowledge and skills that SharePoint teams should have to fulfill their project successfully. Additional training might be required to align specialists’ competencies with the latest requirements of SharePoint Online and Office 365.

All in all, to keep up with SharePoint development updates, it’s highly recommended for SharePoint professionals to follow the activities of the SharePoint PnP community or even become its active members. This can be a great chance to contribute to the evolution of the platform globally.

For example, the community manages an issue list on GitHub where developers can report challenges they are dealing with and ask SharePoint experts for advice or assistance in solving them. On the SharePoint Dev Platform, SharePoint experts suggest possible improvements within SharePoint. After the suggestion passes moderation and voting, the Microsoft team decides whether to accept or decline it. This is a feasible way to promote development initiatives that can be implemented across the entire suite.

It is also necessary for SharePoint professionals to keep track of Microsoft updates, particularly when it comes to the release of new features and security packs. As Microsoft pays much attention to maintaining Office 365 and Microsoft 365, updates come every week if not every day, so there is no way for SharePoint developers to miss out on the platform changes.

The future of SharePoint development: expectations and forecasts

In almost 20 years since its first release, SharePoint has made a big journey full of changes. The cloud version of the platform, SharePoint Online, as well as Microsoft’s collaboration suites, Office 365 and Microsoft 365, will continue to evolve, so SharePoint developers and business owners should stay tuned for continuous updates.

Analyzing the current state of SharePoint and its growth, I can say that farm and sandboxed solutions will go out of custom development. I expect further expansion of the SharePoint Framework and modern frontend development tools, as well as the advance of CSOM and REST API. I am also looking forward to seeing improved support for continuous integration and deployment in SharePoint Online at the API level.

Sergey Protchenko

Sergey Protchenko

.NET and SharePoint architect at Itransition

As for SharePoint On-Premises, it’s era hasn’t finished yet. However, we can see that Microsoft pushes businesses to switch to the cloud, so it won’t be surprising if, at the end of the SharePoint 2019 lifecycle, we don’t see any new versions of SharePoint Server. Keeping in mind this cloud pivot, SharePoint On-Premises owners have to rethink their development and customization approaches as soon as possible to ensure a less stressful migration to the cloud in the future.