SharePoint Framework
Microsoft's edit ·
Microsoft's commit message in SharePoint/sp-dev-docs · commit 8829271 · +30 −32 lines · also on GitHub
11
---
22
title: Overview of the SharePoint Framework (SPFx)
3
−description: 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.
4
−ms.date: 01/08/2018
3
+description: SPFx is a page and web part model that provides full support for client-side SharePoint development, easy integration with SharePoint data, and extending Microsoft Teams.
4
+ms.date: 06/12/2020
55
ms.prod: sharepoint
66
localization_priority: Priority
77
---
⋯ 1 unchanged line
99
1010
# Overview of the SharePoint Framework
1111
12
−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 also for on-premises (SharePoint 2016 Feature Pack 2 and SharePoint 2019).
13
−
14
−Key features of the SharePoint Framework include the following:
12
+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 extending Microsoft Teams. 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.
1513
16
−* It runs in the context of the current user and connection in the browser. There are no iFrames for the customization (JavaScript is embedded directly to the page).
17
−* The controls are rendered in the normal page DOM.
18
−* The controls are responsive and accessible by nature.
19
−* It enables the developer to access the lifecycle in addition to **render**, **load**, **serialize** and **deserialize**, **configuration changes**, and more.
20
−* It is framework-agnostic. You can use any JavaScript framework that you like: React, Handlebars, Knockout, Angular, and more.
21
−* The toolchain is based on common open source client development tools such as npm, TypeScript, Yeoman, webpack, and gulp.
22
−* Performance is reliable.
23
−* 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.
24
−* SPFx web parts can be added to both classic and modern pages.
25
−
26
−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.
14
+The latest version, and all previous versions, of the SharePoint Framework are hosted and available in SharePoint Online. It's also available for SharePoint Server 2016 (with Feature Pack 2) and SharePoint Server 2019.
2715
28
−If you work primarily with C#, you want to learn more about client-side JavaScript development. Most of your existing JavaScript knowledge related to SharePoint, however, is completely transferable, as the data models have not changed, and you’ll use the same [REST services](https://msdn.microsoft.com/library/office/jj860569.aspx) or [JavaScript Object Model (JSOM)](https://msdn.microsoft.com/library/office/jj193034.aspx), depending on your requirements. If you are a C# developer, TypeScript is a nice transition into the JavaScript world. The choice of IDE is up to you. Many developers like to use the cross-platform IDE Visual Studio Code. Many developers also use products like Sublime and ATOM. Use what works best for you.
16
+Key features of the SharePoint Framework include:
2917
18
+- It runs in the context of the current user and connection in the browser. There are no iFrames for the customization (JavaScript is embedded directly to the page).
19
+- The controls are rendered in the normal page DOM.
20
+- The controls are responsive and accessible by nature.
21
+- It enables the developer to access the lifecycle in addition to **render**, **load**, **serialize* and **deserialize**, **configuration changes**, and more.
22
+- It's framework-agnostic. You can use any JavaScript framework that you like including, but not limited to, React, Handlebars, Knockout, Angular, and Vue.js.
23
+- The developer toolchain is based on popular open-source client development tools such as NPM, TypeScript, Yeoman, webpack, and gulp.
24
+- Performance is reliable.
25
+- 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.
26
+- SPFx web parts can be added to both classic and modern pages.
27
+- SPFx solutions can be used to extend Microsoft Teams.
28
+
29
+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.
30
+
31
+If you work primarily with C#, you want to learn more about client-side JavaScript development. Most of your existing JavaScript knowledge related to SharePoint, however, is transferable, as the data models haven't changed, and you’ll use the same [REST services](../sp-add-ins/get-to-know-the-sharepoint-rest-service.md) depending on your requirements. If you're a C# developer, TypeScript is a nice transition into the JavaScript world. The choice of IDE is up to you. Many developers like to use the cross-platform IDE [Visual Studio Code](https://code.visualstudio.com).
32
+
3033
## Why the SharePoint Framework?
3134
32
−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 on-premises farms.
33
−
34
−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. As a result, we introduced two alternative models: client-side JavaScript injection, and SharePoint Add-ins. Both of these solutions have pros and cons.
35
+SharePoint was launched as an on-premises product in 2001. Over time, a large developer community has extended and shaped it in many ways. 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 on-premises server farms.
3536
37
+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 on the same servers. As a result, we introduced two alternative models: client-side JavaScript injection, and SharePoint Add-ins. Both of these solutions have pros and cons.
38
+
3639
### JavaScript injection
3740
38
−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.
41
+One of the most popular web parts in SharePoint Online is the Script Editor. You can add JavaScript to the Script Editor web part and have that JavaScript execute when the page renders. It’s simple 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's also relatively performant, and simple to use.
3942
40
−There are a few 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.
43
+There are a few downsides to this approach. 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 significant problem is that the Script Editor web part isn't 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.
4144
4245
### SharePoint Add-in model
4346
44
−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.
45
−
46
−There are some downsides to this approach as well. First, they run in an **iFrame**. iFrames are slower than the Script Editor web part, because it requires a new request to another page. The page has to go through authentication and authorization, make its own calls to get SharePoint data, load various JavaScript libraries, and more. A Script Editor web part might typically take, for example, 100 milliseconds to load and render, while an app part might take 2 seconds or more. Additionally, the **iFrame** boundary makes it more difficult to create responsive designs and inherit CSS and theming information. iFrames do have stronger security, which can be useful for you (your page is inaccessible by other controls on the page) and for the end user (the control has no access to their connection to Office 365).
47
+The current option for solutions that run in NoScript sites is the add-in/app-part model introduced in SharePoint Server 2013. 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.
4748
49
+There are some downsides to this approach as well. First, they run in an **iFrame**. iFrames are slower than the Script Editor web part, because it requires a new request to another page. The page has to go through the complete authentication and authorization, make its own calls to get SharePoint data, load various JavaScript libraries, and more. A Script Editor web part might typically take, for example, 100 milliseconds to load and render, while an app part might take 2 seconds or more. Additionally, the **iFrame** boundary makes it more difficult to create responsive designs and inherit CSS and theming information. iFrames do have stronger security, which can be useful for you (your page is inaccessible by other controls on the page) and for the end user (the control has no access to their connection to Office 365).
4850
49
−### SharePoint Framework
51
+### SharePoint Framework
5052
5153
Historically, we created web parts as full trust C# assemblies that were installed on the cloud servers. However, current development models for the most part involve JavaScript running in a browser making REST API calls to the SharePoint and Office 365 back-end workloads. C# assemblies don’t work in this world. We needed a new development model. The SharePoint Framework is the next evolution in SharePoint development.
5254
53
−## What's next?
54
−
55
−SharePoint Framework web parts and extensions have now reached General Availability (GA). We continue to provide updates and refinements over time based on your feedback and experiences. For any additional SharePoint Framework capabilities that are first launched in preview mode, 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 continue to work.
56
−
5755
## SharePoint Framework License
5856
5957
The SharePoint Framework components are licensed under this [Microsoft EULA](https://unpkg.com/@microsoft/[email protected]/EULA/Microsoft%20Sharepoint%20Framework%20-%20Standalone%20(free)%20Use%20Terms.docx).
6058
6159
## Questions?
6260
63
−If you have any questions, post them on [SharePoint StackExchange](https://sharepoint.stackexchange.com/). Tag your questions and comments with [#spfx](https://sharepoint.stackexchange.com/tags/spfx/), [#spfx-webparts](https://sharepoint.stackexchange.com/tags/spfx-webparts/), and [#spfx-tooling](https://sharepoint.stackexchange.com/tags/spfx-tooling/).
61
+If you have any questions, post them on [SharePoint StackExchange](https://sharepoint.stackexchange.com/). Tag your questions and comments with [#spfx](https://sharepoint.stackexchange.com/tags/spfx/), [#spfx-webparts](https://sharepoint.stackexchange.com/tags/spfx-webparts/), and [#spfx-tooling](https://sharepoint.stackexchange.com/tags/spfx-tooling/).
6462
6563
You can also post issues, questions, or feedback about the docs or the SharePoint Framework in our [GitHub repo](https://github.com/SharePoint/sp-dev-docs/issues).
6664
⋯ 2 unchanged lines
6967
- [Overview of SharePoint client-side web parts](./web-parts/overview-client-side-web-parts.md)
7068
- [Overview of SharePoint Framework Extensions](./extensions/overview-extensions.md)
7169
- [SharePoint development](https://docs.microsoft.com/sharepoint/dev/)
72
−- [SharePoint glossary](../general-development/sharepoint-glossary.md)
70
+- [SharePoint glossary](../general-development/sharepoint-glossary.md)
Microsoft's Markdown source from SharePoint/sp-dev-docs, © Microsoft Corporation, under CC BY 4.0. Changed lines with up to 3 unchanged lines around each; ChangeIntel kept this copy 12 Oct 19:35 UTC. The commit date is when the source changed, which can be hours or days before Learn published it.