Overview of the SharePoint Framework

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.

With the SharePoint Framework, you can use modern web technologies and tools in your preferred development environment to build productive experiences and apps that are responsive and mobile-ready from day one.

The SharePoint Framework works for SharePoint Online and for on-premises (SharePoint 2016 Feature Pack 2).

Key features of the SharePoint Framework include:

1.      Runs in the context of the current user and connection in the browser. There are no iFrames for the customization (JavaScript is embedded directly into the page).

2.      The controls are rendered in the normal page DOM.

3.      The controls are responsive and accessible by nature.

4.      Enables the developer to access the lifecycle - including, in addition, to render - load, serialize and deserialize, configuration changes, and more.

5.      It's framework agnostic. You can use any JavaScript framework that you like: React, Handlebars, Knockout, Angular, and more.

6.      The toolchain is based on common open source client development tools like npm, TypeScript, Yeoman, webpack, and gulp.

7.      Performance is reliable.

8.      End users can use SPFx client-side solutions that are approved by the tenant administrators (or their delegates) on all sites, including self-service team, group, or personal sites.

9.      SPFx web parts can be added to both classic and modern pages.

The runtime model improves on the Script Editor web part. It includes a robust client API, an HttpClient object that handles authentication to SharePoint and Office 365, contextual information, easy property definition and configuration, and more.

That architecture worked well in environments with only one enterprise, but it didn’t scale to the cloud, where multiple tenants run side-by-side. Thus, we introduced two alternative models: client-side JavaScript injection, and SharePoint Add-ins. Both solutions have pros and cons.

JavaScript injection

One of the most popular web parts in SharePoint Online is the Script Editor. You can paste JavaScript into the Script Editor web part and have that JavaScript execute when the page renders. It’s simple and rudimentary, but effective. It runs in the same browser context as the page and is in the same DOM, so it can interact with other controls on the page. It is also relatively performant, and simple to use.

SharePoint Add-in model

The current option for solutions that run in NoScript sites is the add-in/app-part model. This implementation creates an iFrame where the actual experience resides and executes. The advantage is that because it's external to the system and has no access to the current DOM/connection, it's easier for information workers to trust and deploy. End users can install add-ins on NoScript sites.