SharePoint Framework

This page's changes and edits · All guidance changes

Microsoft's edit · 7 Sep 2021 21:21 UTC

replace 'office 365' with 'microsoft 365'

Microsoft's commit message in SharePoint/sp-dev-docs · commit f5baf53 · +4 −4 lines · also on GitHub

11 ---

22 title: Overview of the SharePoint Framework (SPFx)

33 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

4 +ms.date: 09/07/2021

55 ms.prod: sharepoint

66 localization_priority: Priority

77 ---

⋯ 18 unchanged lines

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

2727 - SPFx solutions can be used to extend Microsoft Teams.

2828

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.

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 Microsoft 365, contextual information, easy property definition and configuration, and more.

3030

3131 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).

3232

⋯ 13 unchanged lines

4646

4747 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.

4848

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).

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 Microsoft 365).

5050

5151 ### SharePoint Framework

5252

53 −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.

53 +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 Microsoft 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.

5454

5555 ## SharePoint Framework License

5656

⋯ 14 unchanged lines

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.