If you are a SharePoint developer doing any work in SharePoint Online and you have held out on taking a look at the SharePoint Framework, now is a good time to start taking a look. We are currently at the release candidate 0 (RC0) and in the coming weeks, we can expect to see the generally available (GA) release. This release will support client-side web parts as Microsoft wanted to make sure they got that capability perfected… but they won’t stop there!
One of the most common questions is “what’s next?” with respect to the SharePoint Framework… what additional scenarios will be supported and when will the framework come to on-premises deployments. In last week’s Microsoft Office PnP SharePoint Framework & JavaScript SIG meeting, Vesa Juvonen shared quite a bit on what we can expect!
SharePoint Framework & On-premises
Microsoft is committed to bringing the SharePoint Framework to on-premises SharePoint deployments this year (2017). When exactly isn’t clear but I’d expect it in the second half of the year. It will ship as part of a feature pack for SharePoint Server 2016 so it won’t be supported in prior releases (such as SharePoint 2013).
You can expect full feature parity for what we can do in SharePoint Online with the SharePoint Framework but at a different pace. That means you may see new features and capabilities with the SharePoint Framework show up in SharePoint Online before we get them on-premises which are to be expected. In addition, they are committed to using the same development toolchain to facilitate the same common development experience regardless if you are creating customizations for on-premises or SharePoint Online deployments.
SPFx Roadmap: Web Parts++
Once the GA release ships, Microsoft is working to add additional capabilities to the SharePoint Framework. This includes updates to client-side web parts such as part-to-part communication.
In the meeting last week they also talked about additional work they are investing in to make sure that if you are using multiple JavaScript frameworks on the page (like React, Angular or Vue.js) you don’t run into conflicts. They are also investing in what they call the “citizen developer” where they want to make it easy to do the same thing many people do today with the Script Editor Web Part: how can you add some JavaScript to the page without having to package everything up and deploy it as an app.
SPFx Roadmap: Add-ins
An interesting mention was add-ins and the work they want to do there. Today SharePoint Add-ins are manifested on the page within an IFRAME which makes the experience slow and less than ideal. This IFRAME approach also makes it very hard to create responsive experiences. In the future, we can expect to see the SharePoint Framework improve this by making them more responsive & allow you to build add-ins using the SharePoint Framework development approach!
SPFx Roadmap: Code Parts
An interesting topic that was discussed were code parts. It’s not entirely clear what these are… I’ve heard Microsoft talk about these in private discussions and was hoping that the first time they went public with this the messaging would be a bit more clear. The idea here is that they want to give people the ability to implement customizations we used to do with things like JSLink and custom actions with the SharePoint Framework.
These code parts would use the same toolchain and deployment model as client-side web parts and derive from the same strongly typed base class whenever possible instead of manipulating the page DOM directly like we’ve done in the past. In addition, they would also work with the NoScript setting via the tenant-scoped App Catalog AND the site collection scoped App Catalog (hey… that’s new too!).
SPFx Roadmap: ALM Investments
This is a huge topic that developers have been asking for. How do you roll out and upgrade your customizations easily? How do you do it in a scripted way?
First, Microsoft is going to provide additional REST endpoints to enable the (1) deployment of app packages, (2) activation, (3) upgrade and (4) deletion of apps. These endpoints would work for anything deployed to the App Catalog including Add-ins!
They also talked about a streamlined approval experience for new and updated app packages. When an app package owner wants to update a deployment, they can initiate an approval process to the tenant administrator. The tenant administrator would get a notification that there is a new package to approve. This means developers don’t need to keep track of who the admins are for a tenant… SharePoint will handle this for you. The tenant admin can then approve or deny the submission or even set it to automatically approve or deny after X days of no action. In addition, the tenant administrator can flag trusted developers whose updates are automatically approved.
SPFx Roadmap: Full Page apps
While originally in the plans for v1.0 of the SharePoint Framework, Microsoft pull these from their plans early on to focus on the client-side web parts… but they are still in the plans! The idea here is that you can take over an entire page vs. extending an existing page. One use is for lists where you can create custom view / edit / delete and add forms as well at the page level to assign an app to an entire page for a full page experience.
SPFx Roadmap: Workbench 2.0
All the things I’ve mentioned above will require updates to the development experience. This includes additional Yeoman generators for things like Code Parts, Add-ins & full page apps. One thing that was not mentioned was any investments or work being done for Visual Studio… an interesting omission.
They discussed a few other things in the meeting last week but I wanted to just cover the big items in this post. You can check out the meeting recording on their YouTube channel by clicking this link… it will jump straight to the part where Vesa started giving an update on the SharePoint Framework.
