SharePoint 最初在 2001 年作为本地产品推出。 随着时间的推移，一个大型的开发人员社区已经形成并壮大，并从多方面对其进行了改进。 开发人员社区遵循了 SharePoint 产品开发团队所使用的同一种模式和做法，其中包括 Web 部件、SharePoint 功能 XML 等。 许多功能使用 C# 编写为服务器端自定义项，编译为 DLL，并部署到本地服务器场。
这种架构非常适用于只包含一个企业的环境，但是无法扩展到有多个租户在同一服务器上并行运行的云中。 因此，我们引入了两种备用模型：客户端 JavaScript 注入和 SharePoint 外接程序。两种解决方案各有优势和劣势。
JavaScript 注入
SharePoint Online 中最常用的 Web 部件之一是脚本编辑器。 可以将 JavaScript 添加到脚本编辑器 Web 部件并使该 JavaScript 在页面呈现时执行。 它简单 & 有效。 它和页面在同一个浏览器上下文中运行，并在同一个 DOM 中，因此它可与页面上的其他控件交互。 相对而言，其性能良好且易于使用。
此方法存在一些弊端：
- 虽然你可以打包解决方案，以便最终用户可以将控件放到页面上，但你无法轻松提供配置选项。
- 最终用户可以编辑页面并修改脚本，这样可能会破坏 Web 部件。
- 脚本编辑器 Web 部件不会标记为“对脚本编写是安全的”。 大多数自助式网站集（我的网站、团队网站、组网站）都已启用 NoScript 功能。 从技术角度来讲，这撤消了 SharePoint 中的添加/自定义页面 (ACP) 权限。 也就是说，将阻止脚本编辑器 Web 部件在这些网站上运行。
SharePoint 加载项模型
可在 NoScript 网站中运行的解决方案的一个选项是在 SharePoint Server 2013 中引入的外接程序/应用部件模型。 这种实现将创建 iFrame，实际体验位于此处并在此执行。 其优势在于由于其位于系统外部，且无权访问当前 DOM/连接，因此更易受到信息工作者的信任且更易部署。 最终用户可以在 NoScript 网站上安装外接程序。
此方法也存在一些弊端
- 它们在 iFrame 中运行。 iframe 比脚本编辑器 Web 部件慢，因为它要求通过新请求才能转到其他页面。 此页面必须经历完整身份验证和授权，并执行自己的调用来获取 SharePoint 数据，同时加载各种 JavaScript 库等。 例如，脚本编辑器 Web 部件通常可能需要 100 毫秒才能加载和呈现，而应用部件则可能需要 2 秒或更长时间。
- iframe 边界加大了创建响应式设计并继承 CSS 和主题信息的难度。 iframe 确实更加安全，这对于你（无法通过页面上的其他控件访问页面）和最终用户（控件无权连接到 Microsoft 365）可能会非常有用。
SharePoint 框架
之前，开发人员创建了 Web 部件作为安装到云服务器上的完全信任 C# 程序集。
但是，当前的开发模型通常涉及在浏览器中运行的 JavaScript，对 SharePoint 和 Microsoft 365 后端工作负载进行 REST API 调用。 C# 程序集不适用于此环境。 开发人员需要新的开发模型。
SharePoint 框架是 SharePoint 开发的下一个发展方向。