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 on-premises and SharePoint Online.
Key features of the SharePoint Framework include:
- Runs in the context of the current user and connection in the browser. There are no iFrames.
- The controls are rendered in the normal page DOM.
- The controls are responsive and accessible by nature.
- Enables the developer to access the lifecycle - including, in addition to render - load, serialize and deserialize, configuration changes, and more.
- It's framework agnostic. You can use any browser framework that you like: React, Handlebars, Knockout, Angular, and more.
- The toolchain is based on common open source client development tools like npm, TypeScript, Yeoman, webpack, and gulp.
- Performance is reliable.
- 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.
- Solutions can be deployed in both classic web part and publishing pages 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.
Why the SharePoint Framework?
SharePoint was launched as an on-premises product in 2001. Over time, a large developer community has extended and shaped it in many ways. For the most part, the developer community followed the same patterns and practices that the SharePoint product development team used, including web parts, SharePoint feature XML, and more. Many features were written in C#, compiled to DLLs, and deployed to the servers.
There are a couple of downsides to this approach, however. First, while you can package your solution so that end users can drop the control onto the page, you can't easily provide configuration options. Also, the end user can edit the page and modify the script, which can break the web part. Another big problem is that the script editor web part is not marked as "Safe For Scripting". Most self-service site collections (my-sites, team sites, group sites) have a feature known as "NoScript" enabled. Technically, it is the removal of the Add/Customize Pages (ACP) permission in SharePoint. This means that the script editor web part will be blocked from executing on these sites.
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.
This is the first preview release. We will provide updates and refinements over time based on your feedback and experiences. While the SharePoint Framework is in preview, you might experience occasional breaking changes around API names, flows, and more. Future updates to the SharePoint Framework will be backward compatible, so that your solutions will continue to work.
SharePoint Framework License
The SharePoint Framework components are licensed under this Microsoft EULA.
You can also post issues, questions, or feedback on the docs or the SharePoint Framework in our GitHub repo.