With the introduction of the SharePoint Framework, organizations now have an entirely new option to choose from when designing custom extensions for their cloud and on-premise collaboration solutions. Although this new model provides additional capabilities and addresses many of the feature gaps present in Azure Web Applications and SharePoint Add-Ins, it also makes the development landscape more complicated than ever before, inevitably leading to confusion around which model to use for specific business scenarios. Integrating the Framework into an existing development strategy involves several key decision points and a deeper understanding of why it was introduced and what specific problems it was created to solve.
When Microsoft made the decision to invest heavily in cloud collaboration, it was obvious that a new development model would be necessary, as the full-trust solutions that had served customers so well simply could not be supported in a massively scalable shared tenancy architecture. In order to maintain a decent level of extensibility, which has always been one of the core strengths of the SharePoint platform, any such model would need to provide developers with the ability to create custom solutions that could run both in the cloud and in legacy on-premises environments.
This presented numerous challenges, not the least of which was introducing an entirely new authorization process and deployment methodology. The “App Model” (or “Add-In Model,” as it would eventually be known) was a compromise between the need for contextual application components, which were traditionally delivered in the form of web parts, and off-server code execution to maintain cloud scalability and code isolation. A further extension of this model, which focused on global accessibility and directory integration, later became available when Azure Web Applications were introduced.
While these models provide an important set of features and functionality, they both stray quite far from the “pages and parts” methodology of traditional full-trust solutions, which were primarily used to extend and enhance the user experience inside of SharePoint. Add-ins and web applications redirect common collaboration activities outside of the environment with only a thin integration layer connecting them with the original context. Although add-ins offered a partial solution in the form of frame-based Client Side Web Parts (or “app parts” as they are more commonly known), they fell fall short of the rich component and custom page extensibility offered by traditional web parts, arguably causing more issues than they actually solved.
It was clear that a more robust model was needed, one that would support a wide range of customizations natively within SharePoint sites in a way that worked equally well on-premises and in the cloud. Most importantly, it would need to focus on a “pages and parts” methodology more closely aligned with how users interact with the platform than remotely hosted, standalone micro-applications.
How the SharePoint Framework helps
To address this clear gap in development model capabilities, Microsoft introduced the SharePoint Framework, an entirely new development stack for SharePoint and Office 365 that allows developers to create web parts that can be added to individual pages, along with completely immersive single-page experiences that make it far easier to deliver a SharePoint user interface that doesn’t look like... well... SharePoint.
The SharePoint Framework, which underlies native features like the new-look lists and libraries, is designed to address customization scenarios in which web parts and custom pages running natively within a SharePoint site context provide enhanced value to the user. Such scenarios might include the display of external data on a site home page, the addition of custom capabilities to a list view page, CRUD operations for a back-end line of business systems, or some other piece of functionality that would traditionally have been delivered as a web part or application page in an on-premises deployment as part of a full-trust solution. In fact, it is quite likely that Framework solutions will be employed more often to supplant full-trust code, as opposed to add-ins or web applications, as they have greater similarity to the most common uses of the server-side API’s (with notable exceptions for things like timer jobs and custom workflows).
When viewed from this perspective, it becomes rather obvious where Framework projects fit within the spectrum of SharePoint development model options. If the requirements are best met with a page or part, then a Framework solution is the most appropriate. If the need is for a distinct “app” experience within the context of an individual site, then a SharePoint Add-In will most likely be the best answer. In those instances where an external application is needed that is globally accessible, but still includes at least some level of SharePoint data integration, then an Azure Web Application would best meet the requirement. This approach simplifies the strategic decision making process and ensures that the right solution is chosen for the stated scenario.
Of course, it is never quite so simple in reality. SharePoint Framework solutions offer the ability to create self-contained single-page applications that can be almost identical to Add-Ins or Web Applications. The primary distinction, leaving aside deployment and tooling differences, is that when a user is interacting with a Framework page, they never actually leave the SharePoint site context.
The overall experience is much like running an application page in a full-screen dialog with the option to completely remove all the SharePoint UI chrome. In these situations, the decision on which model to use can be a difficult one that will most likely driven by tangential factors such as single sign-on to other applications, internal or external hosting of the solution, compiled vs. uncompiled code, third-party dependencies, security policies, and so on. Personal preference may also play a part, as developers with experience creating full-trust solutions will most likely prefer the “pages and parts” model as opposed to the “app” model.
Moving from Visual Studio to things like Node.js, Gulp, TypeScript, React and so on is likely to cause a great deal of disruption for developers, especially within enterprise companies where tooling is standardized and very difficult to change. This is not a trivial matter; it may very well be that a SharePoint Framework solution is the right answer to a particular set of requirements, but due to the lack of requisite skills within the development team and an inability to abandon tried and testing development processes for often highly volatile web stack techniques, it may be unusable. Unless Microsoft creates native tooling for the Framework on par with the other SharePoint development models, then it may not play a role at all in the development strategy of many organizations for whom it could otherwise provide a great deal of value.
From a strategic perspective, deciding when and where to use the SharePoint Framework for custom solutions is as much a function of ability as it is capability. Organizations with the right skill sets within their development teams (or those willing to invest in the acquisition of such skills) that can work around the technical limitations may quickly realize a great deal of benefit by employing the “pages and parts” model in situations where the “app” model was not a good fit. They may also find it much easier to map out a path toward complete replacement of full-trust solutions using Framework components within their on-premise and hybrid environments. Some may find that the technical limitations and requirements make adoption difficult or altogether impossible. In either case, understanding how the SharePoint Framework functions and what it is designed to achieve will prove helpful in designing a development strategy that fits the needs of every organization.