SharePoint Development Models and the SharePoint Framework (SPFx)

In this article we will go through history of SharePoint development, getting a brief concept of popular approaches/development models followed by SharePoint developers, their benefits and cons, and the features of the trending SharePoint Framework (SPFx).

Microsoft SharePoint was introduced in the year 2001 as an on premise product. Since the beginning, a lot of developers gave their part in shaping the future of SharePoint by extending its features such as web parts and Feature XML and many other solutions through custom development. Major development included writing features in C#, compiling these in to DLLs, and deploying these to SharePoint Servers to accomplish the business requirements by the many businesses that adopted SharePoint. This development model worked suitably with on premise enterprise level deployments of SharePoint.

The diagram here shows a general Request flow or communication diagram for Full Trust Deployment Model as explained above

With SharePoint 2013, SharePoint Online and Office 365, Microsoft introduced multi-tenancy functionality that has the general concept of the ability to manage and distribute data of sites and services among multiple subscribing clients generally referred as tenants. This functionality allowed using one SharePoint farm to manage multiple clients that were before managed through multiple instances of a service or through separate hardware for each tenant.

In the multi-tenant architecture the conventional model for SharePoint development could not be implemented as it required Full Trusted Deployments of the customized solutions. Another major drawback was the lack of extensibility in the traditional development frameworks. To deal with this issue Microsoft introduced two prevalent alternatives.

Extending SharePoint through client side JavaScript Injection:

This model allows a developer to add JavaScript into the script editor web parts on SharePoint pages, usually Publishing Pages, to execute along with the page rendering. This method is fairly simple and powerful as the executing JavaScript is in context with the page DOM. This allows the script to communicate with all controls and page objects such as Breadcrumb, SharePoint contextual ribbon, Navigation and other web parts on the page. The downsides of this approach include manual configuration requirement. Along with this most self-service site collections such as my-sites, team sites, etc. have a feature known as “NoScript” enabled, technically, it refers to page customization permission removal in SharePoint. Script Editor is not allowed in such sites if “NoScript” feature is enabled. This feature blocks the script that is not “Safe for Scripting”. For a developer that means the script editor web part will be blocked from executing on these sites.

SharePoint Add-in/App Part Model

As an alternate approach for “NoScript” environments the App Part Model was introduced. This model basically works in an iframe, to execute the extended features in an isolated section on the SharePoint page. The main benefit of this model is that as it is external to the system and has no access to the current DOM/connection, it is easier to trust and deploy for IT users and provides a heightened sense of security. App parts can be installed on NoScript sites by end users effortlessly. The downsides of this model, however include slowness in comparison to the script editor web part as this is a call to another whole page inside a page, having the concept of iframe. This page has to go through authentication and authorization and iframe makes it more difficult to create responsive designs.

Having a review of the development models, it is apparent that there was a need to introduce a model that supports the changing mobile-first cloud based era, as full trusted C# assemblies do not work in the O365 and SharePoint. Because of this majority of SharePoint developers currently work with JavaScript calls to SharePoint and O365 through REST API.

Microsoft introduced Microsoft SharePoint Framework as “Future of SharePoint” and a new development model to deal with with the changing cloud based era. Hereon referred as SPFx, we will deep dive in to the features of SharePoint Framework. SPFx comprises of a set of tools to build robust solutions over Microsoft SharePoint. SharePoint Framework is mobile-first and cloud-enabled, so it works as well with SharePoint Online and O365 suite. As Microsoft introduces:

“The SharePoint Framework (SPFx) is a page and web part model that provides full support for client-side SharePoint development, easy integration with SharePoint data and support for open source tooling.” (Reference: https://dev.office.com)

The best part of SPFx is that it enables developers to create solutions for SharePoint without having knowledge of .NET programming language as JavaScript and open source tools can be used for this purpose. Developers can develop apps for SharePoint and O365 without requiring specific skills that were mandatory in previous models. While SharePoint Framework is already released for the rest, Microsoft has announced in SharePoint Summit 2017 that SharePoint Framework will be introduced with Feature Pack 2 for SharePoint 2016.

Below are some key features of SharePoint Framework

SPFx is 100% JavaScript through JavaScript Client-side Object Model that enables the SPFx approach to be consistent with modern web UI best practices in comparison to traditional server side model.

SPFx allows the code to run in context of current user, site and environment variables of the browser.

Features developed through SPFx can be deployed in to classic pages as well as modern web UI pages equally.

Development can be done in any of you favorite frameworks such as React, knockout, angular js and many other opensource framework.

No more performance issues to be catered as in server-side traditional model.

What about “NoScript” enabled sites? Yes, SPFx model will allow the code to be run in team sites, my sites and other “NoScript” enabled sites too

With all the changes in the implementation, web parts built through SPFx still are compatible with the conventional pages.

Having considered all drawbacks of existing development models Microsoft has addressed all of the downsides in the SPFx that makes it most efficient model for SharePoint development. SPFx that can be used on any platform with any JavaScript framework to build SharePoint customized solutions.

SPFx is already introduced in SharePoint Online, however, according to researches, majority of developers still use the conventional server side development model, the app part model and the JavaScript Injection to achieve solutions to the business needs of the customers. The main reason is that majority of the developers are comfortable with the traditional methodologies. Secondly, the SPFx is an entirely new model hence it will require significant time to adopt and get comfortable with, for traditional developers. For SharePoint developers who have already been working with client object model for SharePoint and REST API, client side scripting for web technologies SharePoint Framework is a matter of understanding a new approach to their work.

SharePoint Framework promises reduced development costs and provides opportunities for a better developer experience with increased efficiency and robust applications for both web and devices.

1 Comment

Awesome article. Great, I really liked the beginning of this article about the history of SharePoint development and how it helped the enterprises. Thanks much for sharing such an informative article about SharePoint. Also, the flow diagrams are perfect for explaining about the deployments of SharePoint and SharePoint framework. Thank you!