博客地址：http://blog.csdn.net/FoxDave
透视视图：SharePoint在更广泛的SharePoint平台中
SPFx是一个新的模型，附加在已存在的方法上，但是专注于为用户接口自定义提供更多的价值如客户端web部件。该框架被设计用来跟现有的模型一起工作，并且更容易以一种更广泛和持久的支持方式创建新的用户接口自定义部署。
对比Add-ins
SharePoint Add-ins，之前被称作SharePoint应用程序（SharePoint 2013版本被引入），曾经是唯一的被SharePoint Online支持和管理的自定义选项。然而在很多情况下，SharePoint Add-ins需要相比简单的用户接口自定义所需要的必要的工作多得多的架构工作。SharePoint Add-ins有两个类型：SharePoint承载和提供方承载。SharePoint承载的Add-ins以SharePoint支持的方式执行客户端代码，但正像刚才所说的即使是一个客户端web部件也需要比必要工作多得多的工作。在很多情况下是构建SharePoint承载的Add-ins来部署组件，如SharePoint网站中的列表和web部件。这些web部件在一个特殊的网站存在，即应用程序网站，它只有有限的功能，专门用于承载Add-ins。另一方面，提供方承载的Add-ins能同时执行服务端代码和客户端代码，对SharePoint Online进行远程调用（注意这里说的服务端代码是指C#后台代码，而非SharePoint服务端对象模型，Online是无法执行Server API的）。这对独立软件供应商是有利的，可以保护他们的知识产权、代码和逻辑，也适用于无法执行客户端脚本的场景，如长时间运行、繁琐的计算操作或是无法用客户端脚本实现的访问远程数据源等操作。Add-ins的主要优势是独立性：实际的代码并不是在SharePoint网站浏览器跨站脚本保护中执行，这可以方式Add-in获得跟当前登录用户一样的访问权限。Add-ins的只能在安装的过程中授权，这使得管理员从第三方获取Add-in时更加安全，同时也相对独立地存在于微软商店中，用户可以自行搜索下载安装。
SPFx跟SharePoint Add-ins并肩工作，并且可以替代只需要客户端脚本的场景。例如，Add-ins能够向网站添加应用程序部件。这些应用程序部件跟web部件类似，区别在于：web部件是在网站页面的上下文中运行，而应用程序部件是运行在他们自己的独立域名（上文中提到的应用程序网站或提供方承载的网站）下，以iframe的形式嵌入到页面中。另一方面，SPFx并不是在iframe中运行的。得益于此，它能以更无缝的方式在页面上下文运行，提供给用户更强大的交互功能。这使它可以运行丰富的函数，但同时没有像Add-ins一样的安全控制。SPFx解决方案也因此被称为是完全信任的客户端解决方案。同时由于iframe是非响应式的，所以在移动端和备用显示器上显示得不是那么好。
基于前面提到的安全方面的原因，SPFx解决方案目前并没有商店来让你下载和安装解决方案。另一方面，在许多情形下使用用户上下文是期望的场景的情况下，可以使用SPFx替代。