Announced at the “Future of SharePoint” event, was the SharePoint Framework. And it is in public beta since this week! I was one of the lucky persons who had access to the internal repository, so I already had a play with it before. Unfortunately I could not blog about it, as it was under NDA. I will talk about how it will fit into the existing SharePoint development infrastructure, and start with some history 🙂
Argh, again a new development model?
To be honest, this was my first reaction. I’ve got SharePoint experience since SharePoint 2003, and over the years Microsoft has given me a new way to build SharePoint customisations every couple of years:
- In SharePoint 2007 the Server-Side object model was released. This became a huge success, and that was a big surprise to Microsoft. There was no documentation, no tooling, we had to manually create a folder structure and use 3rd party tooling like WSPBuilder to create WSP’s. There was no guidance how to develop, so this was the time that we created heavily customized applications in SharePoint.
- As farm solutions could (and did) bring down entire farms, Microsoft invented “sandboxed solutions”. The code did no longer run inside w3wp, but inside a separate process. Because of major limitations (really, why can’t you send emails from a sandboxed solution), this has never become popular.
- Sandboxed and Farm solutions were still tight to C#, and the .NET version of SharePoint. E.g. no .NET 4 in SharePoint 2010.
Everything became different in SharePoint 2013 where the first step was made to take the code outside of SharePoint: The app (now add-in) model. Code was either running in the browser (SharePoint hosted) or on another server (provider hosted).
Part of this development was that the REST API’s were introduced in SharePoint 2013, providing a much better API than the old school ASMX web services in SharePoint 2010.
To be honest, we have not used add-ins a lot. In most cases we use ScriptLinks to inject scripts in our pages, and use REST / CSOM to talk to SharePoint. But key point is that there is no more server-side code running inside SharePoint processes.
And now, 3 years after the add-in model, we have got the SharePoint Framework.
The SharePoint Framework is a Page and Part model that enables client-side development for building SharePoint experiences
Roughly said, it replaces page layouts (Page Model) and add-in web parts (Part Model). It provides a much richer user experience based on modern web technologies. For example, the “old school” web part properties still use full page post backs, and feel clunky. The web part properties in the new Part Model provide real-time updates, undo functionality, and do not involve post backs.
How does the new Framework fit in?
First of all, sandboxed and farm solutions are deprecated and I believe that they don’t have a future. That being said, last week I’ve created a farm solution for an on-premises SharePoint 2013 to provide feature stapling…
I believe going forward the SharePoint Framework will not entirely replace the classic add-in model. The big limitation I see with the new Page Model is that it is a one-column layout. There is no notion of a left-hand navigation, no multi-column layout, etc. The new editing canvas originates from the new blogging experience in Delve, where this makes sense, but in intranet scenarios this won’t make our design team happy.
- Farm models and Sandboxed solutions are deprecated, but are still handy in rare cases.
- The single column layout in the new Page Model is not suitable for all scenarios
- The new Part Model can be used in classic page layouts.
We are using Angular in a couple of our projects. Immediately after the announcement that SPFX is available, I looked at compatibility with Angular (1 / 2). Unfortunately this is not available, but luckily it is being actively worked on. I’ve opened an issue for ng2 support, feel free to collaborate!