I am bit confused on how SharePoint Framework fits in with the two hosting models (SP-hosted, Provider-hosted). When I go to this tutorial they suddenly call it as client side web-part, and it seems to be something that lives on the SP site. Isn't this was SP hosted apps where for?
-
check this wiki, we had excellent discussion some time ago - sharepoint.stackexchange.com/questions/206685/…– Gautam ShethCommented Feb 21, 2017 at 12:52
-
There's also a useful webcast from the SharePoint PnP team that discusses when to use which model which might be helpful: dev.office.com/blogs/…– Andy DawsonCommented Feb 21, 2017 at 13:14
-
4Thanks for all links, but a simple explanation in a few sentences would be perfectly enough. Everything I read something from M$ about a new technology I have to wade through a big pile of marketing/evangelist fluff– CowborgCommented Feb 21, 2017 at 15:16
Add a comment
|
1 Answer
The SharePoint Framework is not an Add-In
There are some significant differences between SharePoint Add-Ins (SharePoint-hosted or otherwise) and the SharePoint Framework (SPFx).
You can almost think of the SharePoint Framework as a compromise between efficient (but unmanaged and non-secure) JavaScript injection techniques on the one hand and highly controllable (but browser/network inefficient) add-ins on the other.
This documentation explains in detail how the SharePoint Framework differs from both JavaScript injection and add-ins.
Efficiency Differences
Notably, consider these disadvantages that add-ins have:
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.
In contrast, SPFx code isn't embedded in an iFrame:
- 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).
- The controls are rendered in the normal page DOM.
This means customizations through the Framework can load more efficiently.
It also means you sacrifice some flexibility: when you peel back the covers of a hosted add-in, you potentially have a web server doing whatever you want underneath. In contrast, SPFx is "just JavaScript" ...although of course it can make REST calls to invoke available web services on your web servers.
SharePoint Integration Differences
Sensibly, SPFx provides some "hooks" for getting info from SharePoint, since it's designed explicitly for the context of a SharePoint page (whereas add-ins are a little more agnostic, with a lot of shared infrastructure and design between Office Add-Ins and SharePoint Add-Ins).
Again, quoting from the above documentation about the SharePoint Framework:
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.
These hooks are useful not only for web parts but also for "extensions" which are also built using the SharePoint Framework. Think of extensions as replacements for customization that typically got injected into masterpages and custom script actions. There is not a hosted add-in equivalent to extensions.
