Introduction to SharePoint Framework

• As per Microsoft Docs, 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.
• It runs in the context of 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.
• The controls are responsive and accessible by nature.
• It enables the developer to access the lifecycle in addition to render, load, serialize and deserialize, configuration changes and more.
• It is framework-agnostic. You can use any JavaScript framework that you like: React, Handlebars, Knockout, Angular etc.
• The toolchain is based on common open source client development tools such as 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.
• SPFx web parts can be added to both classic and modern pages.
• SharePoint client-side web parts are controls that appear inside a SharePoint page but run locally in the browser.

JavaScript Injection/Script Editor Web Part

• Pros
  • You can paste JavaScript in Script Editor web part and have that JavaScript execute when the page renders.
  • It is simple and rudimentary but effective.
  • It runs in the same browser context as the page and is in the same DOM hence it can interact with other controls on the page.
  • It is also relatively performant and easy to use.
• Cons
  • While you can package your solution so that end users can drop the control onto the page, you can’t easily provide configuration options.
  • The end user can edit the page and modify the script, which can break the web part.
  • 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 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

• Pros
  • The current option that run in NoScript sites is the add-in model.
  • This implementation creates an iFrame where the actual experience resides and executes.
  • As it is external to the system and has no access to the current DOM/connection, it is easier for information workers to trust and deploy.
  • End users can install add-ins on NoScript sites.
  • 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).
• Cons
  • They run in an iFrame. iFrames are slower than the Script Editor web parts, as 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.
  • The iFrame boundary makes it more difficult to create responsive designs and inherit CSS and theming information.