Webinar: SharePoint Framework Developer Preview

View Presentation

One of the things I was the most keen on to see coming out of the May 4th Future of SharePoint event was the public announcement around the new SharePoint Framework. This was something the MVPs had heard about in last fall's MVP Summit, but now it was no longer under a non-disclosure agreement.

For those of you who have been involved in SharePoint development for many years, you have seen a variety of approaches come and go from Microsoft. First, there were full trust solutions that ran on the server, but they weren't allowed in the cloud on Microsoft's multi-tenant servers. Then sandbox was the solution, but that fell through. Their next approach was with apps, but many people (myself included) found them overly complex. If you've followed my previous talks like Electronic Forms and Alternative SharePoint App Approaches or our open source project Shakespeare, you'll know I've been a big fan of client side development for quite a few years now. More recently we've been using that approach with native SharePoint REST APIs or custom-built ones to build some very interesting solutions. The SharePoint Framework validates and improves on that approach.

Effectively, the SharePoint Framework is a way for any web developer to use cross-platform tools of their choice to build applications. In fact, it will likely be easier for an open source JavaScript developer to get up to speed with the framework than a traditional SharePoint developer. This is not to say that traditional SharePoint developers will not like the approach, it will just take a little more getting used to.

The net result of the framework is that client side code running natively in the SharePoint chrome (not inside an iFrame, thank you) is interacting with back end APIs (SharePoint or custom). This lets the front-end developer create an awesome user experience that is responsive for different device sizes and is quick and reactive to use. Business rules and security that need to be locked down can then be run on back-end APIs. This is exactly what was on my wish list in the Electronic Forms and Alternative SharePoint App Approaches webinar. Add in the ability to deploy and configure these like traditional web parts, and you have an awesome solution. Finally, since it doesn't dictate the technical implementation tools, it will adapt as the web development space evolves.

In this session, I'll be building on what we've done in the Shakespeare reference project, and updating it to work with the new Framework. This means the cross-site publishing approach we've built gets even easier to deploy under the new Framework. My plan is to also incorporate some of our custom applications like our Leave Request form that leverages custom Visual Studio Web APIs and REST APIs for security and business rules into the framework.