The SharePoint Framework went generally available (GA) in Feb 2017. I am personally very excited to see the next evolution of SharePoint development be made available to Office 365.
One of the toughest discussion with organizations transitioning to Office 365 is how to transition SharePoint to SharePoint Online. For organizations with complex deployments, SharePoint Online is transition could be challenging. The biggest challenge was what to do with Full Trust code that was either developed internally or part of a third-party solution that was acquired. Over the years since SharePoint Online has been released, organizations and third-party solution providers have transitioned over to the APIs and the SharePoint Apps model. However, there was still gaps in what could achieve with SharePoint Online. With the introduction of the new SharePoint Framework, these gaps have been closed.
What is the SharePoint Framework?
Simply put, the SharePoint Framework is a new web page and web part development model that supports open source tools providing new flexibility in the creation of apps using modern web technologies. This framework works for either SharePoint on-premises or SharePoint Online. The new SharePoint Framework will give you a smooth transition from .Net development to Javascript development using this new method.
Up this point, SharePoint Online development options were:
- Full Trust Code: Not supported in SharePoint Online.
- Sandbox Solutions: Limited set of Full Trust code APIs available however this solution is being deprecated; so it was not recommended to invest time in Sandbox Solutions.
- SharePoint Apps: Was first introduce in SharePoint 2013 days and was used by many to transition complex solutions to SharePoint Online. This solution moved complex code to other locations and then provided a user experience through a iFrame that was integrated into SharePoint Online. This approach had many benefits however iFrame boundary created some barriers for building an integrated solution with the SharePoint user experience.
- Script Editor: Has been and will continue to be as a solution to inject javascript and customizations into web pages. This solution has several limitations around configuration and its ability to integrate deeply into the SharePoint API.
How have things changed from the old way?
With the new SharePoint Framework, we can get back to writing web-parts the way we used to; which is truly exciting.
- Development Environment – The first big change is that Visual Studio is no longer required to do development. Yeoman generator is used to create your project artifacts that can then be used to do your development is Visual Studio, Subline, Atom, etc.
- API – Instead of using server side code using .NET, you will use Node.js.
Strongly Typed Scripting – Even though development is done in Javascript; Typescript is the primary language providing developers the ability to do object-oriented development that they were used to do with .NET. - Build – Instead of using MSBuild to compile and build your solutions, you will use Gulp which is operating agnostic. It will build solutions using Node.js.
- Deployment – Deployment of code is no longer pushed out to the GAC. With the SharePoint Framework code is built and then deployed to any CDN service. For instance a public CDN used to make the solution publicly available or can be deployed in a SharePoint CDN only make the solution available to a tenant.
References
I highly recommend you start reviewing these articles.SharePoint Framework GA Announcement - https://blogs.office.com/2017/02/23/sharepoint-framework-reaches-general-availability-build-and-deploy-engaging-web-parts-today/
Overview from Ignite - https://myignite.microsoft.com/videos/2723
Overview - https://dev.office.com/sharepoint/docs/spfx/sharepoint-framework-overview
Enterprise Guidance - https://dev.office.com/sharepoint/docs/spfx/enterprise-guidance