This post is just one part in my 10-part email course Understanding the SharePoint Framework Development Toolchain which you can subscribe to and get delivered straight to your inbox.
In yesterday’s installment, I gave you an overview on what you can expect from this email course. In today’s installment, we are going to get down to business.
Today I will answer one simple question: what is the SharePoint Framework? In the past when we were customizing or extending SharePoint, we primarily did so with server-side code.
The challenge with this approach is that in the case of SharePoint solutions, it meant our custom code had to run within a SharePoint process which is a problem in hosted SharePoint deployments such as Office 365.
While add-ins addressed the issue of our code running within the SharePoint process, it did so in ways that were not performant, somewhat limiting and not proving the capabilities that developers and customers were looking for.
Microsoft introduced the SharePoint Framework in May 2016. This not only makes client-side customizations easier, but it includes APIs and first-class ways of deploying our customizations.
The purpose of the SharePoint Framework to make client-side customizations an official development model for SharePoint developers. Developers are able to create client-side customizations that are packaged and deployed to SharePoint sites just like Sharepoint solutions and SharePoint add-ins were in previous versions.
These customizations will also have easy access to SharePoint data using APIs included with the SharePoint Framework. But this does not mean they will be limited to accessing just SharePoint data… they are client-side solutions that can use any technology to access other data sources, including the Microsoft Graph, Office Graph or other accessible APIs.
Components built using the SharePoint Framework will run in the current context, unlike their predecessor add-ins that ran within the context of an IFRAME. This means not only will they load faster, but they will run within the context of the current user and using the current connection in the browser.
SharePoint Framework customizations are also rendered in the current page DOM, again not in an IFRAME, which eliminates the requirement (but not the ability) to host more involved customizations in another website.
Because the customizations are rendered in the current page DOM and not in an IFRAME, they will not have the same baggage associated with them as IFRAMES have. One of the biggest benefits to this is that the customizations will be responsive and accessible by nature.
In a significant break from the past, Microsoft has elected to go with a very different development model for the SharePoint Framework customizations.
Traditional SharePoint developers are used to using tools like Visual Studio to create SharePoint solutions or add-ins. With the SharePoint Framework, Microsoft has elected to embrace and adopt what is commonly referred to as the modern web development stack and toolchain.
This approach opens the platform up to more developers because it is not limited to Windows; the tools are cross-platform. You can use any text editor you prefer. Popular open source tools are used to solve different parts of the build toolchain from project scaffolding, building, serving, packaging all the way to deploying. This includes tools like Yeoman, Gulp, and Webpack, runtimes like Node.js, package managers like NPM and editors like Visual Studio Code or Sublime.
When creating customizations with the SharePoint Framework, you want to make sure you are not excluding your users from using them in legacy SharePoint sites.
Another aspect of the SharePoint Framework is that the customizations you create will work not only in the new current modern pages, but they will also work in the traditional classic web part pages as well as publishing pages.
First party & third party… now that’s a confusing set of phrases you might not be familiar with. The term “third party” refers to people like us… people who are creating things to deploy and run within SharePoint.
In the past things like SharePoint add-ins were a third-party only customization tool; Microsoft did not create add-ins for SharePoint… they just baked their changes directly into the product. The downside to this is that Microsoft, the provider of the host and the development model, is not using the tools they give us to extend the product.
The term “first party” refers to people like Microsoft… not only do they create the host extensibility model, but they also use that extensibility model to extend SharePoint. When they want to create a new component or customization in SharePoint, from this point forward they will use the SharePoint Framework.
What does this mean for us? Well, they are clearly taking a strong dependency on their own extensibility model so they will be able to leverage the same benefits it provides that we use in our customizations but on the flip side, they will also be held back by its limitations. This is good because as they improve the SharePoint Framework for their use, we can benefit from it as well.
That’s it for day 2. Tomorrow’s I will tackle the question of how the SharePoint Framework differs from traditional development and deployment. Enjoy the rest of your day and I’ll be back with you tomorrow!
Today's installment is actually from one of the lessons in the Mastering the SharePoint Framework - Starter Bundle course. This is a free resource you can subscribe to today, or you check out a preview of the course by watching the lesson associated with today's email course installment: