 Microsoft released the SharePoint framework in early 2017, after initially introducing it to the world in concept at their May 2016 event. One set of questions I seem to keep going back to is explaining the what the SharePoint framework is and why did Microsoft create it. And I thought about it and I finally realized that there really isn't some definitive body of work that answers the most basic questions about the SharePoint framework. You know those questions, the ones they refer to as the 5Ws or sometimes the 5W in the 1H? Is the classic what, why, when, how, where and who? In this installment, I'm gonna answer the question, what is the SharePoint framework? Hey, I'm Andrew Connell. This episode is also available as a blog post on boytanos.io and as a podcast on boytanos.show. Check out the description below the video for links to these other resources. If this is your first time here, be sure to hit that big red subscribe button. Hey, I'm Andrew Connell. Have you ever wondered what the SharePoint framework even is? Ever asked yourself, what can I build with the SharePoint framework? You're in luck because that's what this comprehensive piece is gonna be all about. This assumes that you don't have to any present prior knowledge or experience with the SharePoint framework. You're gonna get answers to your questions, specifically what is the SharePoint framework as well as what can someone build with the SharePoint framework? This piece is one of a multi-part series that I answer the questions that are most common that I see with related to the SharePoint framework. I call this series the SharePoint framework 5Ws and 1H answered and it's supposed to give you the best high-level picture of the SharePoint framework. You can find links to the other pieces in this series in the notes related to this installment. Now I'm gonna kick off this series of the 5Ws and 1H with the question that's most likely on the top of mind to everyone. What is the SharePoint framework? So what I wanna accomplish in this post is I wanna answer two questions. I wanna answer what is the SharePoint framework and what can you build with the SharePoint framework? But before I start to answer these questions, I wanna say that these are somewhat tricky to answer without also answering the why Microsoft created the SharePoint framework at the same time, but I answer that in a separate installment. So I recommend that you read or watch or listen to this one as well as the why question as well and I'll include links in the notes to that as well. Because that really does explain a lot of the behind the scenes stuff and I always find that it makes a lot more sense or it makes it easier to understand something when you understand the reasoning and the rationale behind something and not just, what can I do? Because then you kind of wonder a little bit of, how do I do X or how do I do Y? When you find out that, well, if that's not what the motivation was for creating this, you may get frustrated when you can't do the things that you thought you'd be able to do. So with that all being said, let's dive in. What is the SharePoint framework? SharePoint framework is a customization and extensibility development model that Microsoft is currently recommending for all customers of Microsoft SharePoint. It's a framework SDK and API contract for developers who want to customize their SharePoint implementations. It's also 100% client-side customization framework. That's a break from previous development models in that it's only client-side whereas previous models had a server-side component. And that means that all the customizations are all implemented in JavaScript. We write them in TypeScript and CSS and therefore they're executed only in the browser. Previous development models usually relied on some sort of a server-side component. But as I explained in the why Microsoft created the SharePoint framework installment of the series, not only did they outlive their usefulness, but they prohibited some customers from easily migrating to new versions of SharePoint and from Microsoft's offering hosted SharePoint offerings in Microsoft 365 that was formerly called Office 365. Now with the SharePoint framework, Microsoft is fully embracing client-side customizations on extending SharePoint pages that developers were previously implementing using the content editor web part and script editor web parts. Customizations implemented using these two web parts, the content editor web part and the script editor web part, they were brittle solutions. And I mean that they were brittle in the sense that anyone with edit rights on the page could change the code of the solution. Now, while this is certainly an advantage to rapid deployment and development in many scenarios, it's a problem in organizations where many users relied on custom solutions and someone can easily make a change without going through some change management process or introduce a bug in the solution. Solutions implemented using the content editor web part or script editor web part, while they were easy to change, they require multiple manual steps to deploy and configure them. And in these solutions, someone would upload the files used in the solution such as JavaScript, CSS and images and other dependencies to a document library in an existing SharePoint site. They would then go to a page in the site and add the content editor web part or script editor web part to the page and edit it to point to the files previously uploaded to a document library. And that deployment or installation process was error prone due to multiple steps that were actually required. So in an organization with a rigorous change management process, these manual steps aren't always the best way to get custom solutions that are deployed. Nor can a solution like this be easily scriptable to automate deployment of the custom solution. So Microsoft addressed these two shortcomings with the SharePoint framework. Developers create a custom solution of one or more custom components and the resulting files that are deployed to SharePoint are packaged up in a SharePoint package file. That's an SPPKG file. That package is then deployed to your SharePoint environment and made available as an app. And to add it to the page, the user simply has to select the component from the list of available components that are available on the page, like just adding web parts to a page. They don't have to worry about uploading the files needed to implement it. That's handled by SharePoint when you uploaded that SharePoint package, the SPPKG file. Another thing the SharePoint framework does is that it introduces this thing called a page context. So in my other installment here on the why Microsoft created the SharePoint framework, I explained how previous customizations didn't include a contract for developers when customizing SharePoint pages. This was primarily an issue when using the JavaScript injection technique to customize SharePoint pages. Developers would use DOM manipulation, usually with utilities like jQuery or inject to modify content functionality or just to change the page to suit their business requirements. The problem with this approach is that Microsoft never saw the pages DOM as an API, so they would change it to suit their needs. Now, for instance, maybe a new button was added to the user interface or the HTML elements ID changed. If your custom script relied on the element ID that just changed, an update to SharePoint online or SharePoint server by Microsoft, that can break your solution with absolutely no warning. This happened so many times in the years leading up to the release of the SharePoint framework in 2017. So many times that Microsoft added the following message to their official documentation. They say that the SharePoint page HTML DOM is not an API. You should avoid taking any dependencies on the page DOM, the structure or the CSS styles, which are subject to change and potentially break your solution. SharePoint framework provides a rich API to customize the SharePoint experience in a reliable way and is the only supported means to interact with the SharePoint page HTML DOM. As this quote states, developers can look at SPFX as Microsoft's contract with developers for SharePoint pages. They've carved out specific areas of the page that can be customized and these customizations can only be implemented using the supported components included with the SharePoint framework, such as SharePoint framework web parts and extensions. Now, Microsoft also likes to boast that all SharePoint framework solutions are mobile friendly, they're accessible and responsive by default. And while it's true, it's always really in the hands of the developer in what they're building. I mean, what Microsoft has done is make the default experience for developers, one that is amenable and set up for a mobile and accessible experience. But unlike previous development models, all SPFX components, they're all rendered within a div element on the page. So this differs from the previous add-in model that we had where everything that was rendered in an iframe element. Iframes are notoriously unfriendly for accessibility and mobile experiences and they're not easily resizable like their div siblings. Another aspect to the SharePoint framework is simplified permissions because everything runs in the current context of the current user. A client-side solution that runs within a browser, including SPFX, it executes within the context of the current user. This means that SharePoint framework components will run under the identity of whomever is logged and currently logged in to the page. This differs from previous SharePoint development models, such as full trust solutions that support user impersonation. User impersonation is not supported nor is it possible to implement securely in any client-side browser-based solution. This includes SPFX solutions as well. Any user impersonation solution is gonna require you to have the credentials of the current user to impersonate and include those credentials on a client-side page that's gonna result in the password being transmitted and clear text in the source of the page. That's not a good idea, right? That's a very big security risk. It doesn't mean that developers can't implement a solution that includes user impersonation. It just means that the portion of the application that implements user impersonation should be in the SPFX component. Rather, you could do some server-side API, such as an Azure Function, and call it via the SPFX API. Now, like I previously said, all SPFX components are client-side solutions manifested in HTML, JavaScript, and CSS. And while you've heard that SharePoint Framework solutions are primarily built using React, the only real bias is towards TypeScript. Developers can use whatever script library or web framework they want to use. The SharePoint team, much like as did much of Microsoft 365 as a whole, they've elected to adopt React for most of their solutions. This makes it an obvious choice for your more complex apps because the React libraries are already on the page, which means if you don't have to add another web part or another web framework library, or another script download for your users, but if your preference is to use Angular or Vue.js or any other web framework, you're totally free to do whatever you want there. In fact, you can even use the long-time, popular script library like jQuery or even knockout or handlebars in your custom SPFX solutions. It's totally up to you. Now, one little note on using Angular, there is a way to do that, to use Angular inside of, in a SharePoint framework component. I don't think it's a great option, but you should at least know that it is an option that's available to you. And I've got a four-part series that I wrote on my blog that actually explains that, kind of what the problem is. Here's one way to do it. Here's another way to do it. And then here's the good, bad and the ugly on it. So check the notes in the description related to this installment. In this episode, if you wanna learn more about that. Now, unlike previous development models, Microsoft included a set of APIs in the SharePoint framework to make it easier to integrate data from external sources and interact with APIs. Previously, you needed to build requests for calling the SharePoint framework REST API, Microsoft Graph or other third-party RESTful APIs. This included authenticating and specifying all the necessary HTTP headers in a REST request. And that was cumbersome and problematic. The SharePoint framework API includes objects that handle all the overhead of calling the SharePoint REST API when you wanna leverage SharePoint list data or to do other tasks within the APIs. All you have to worry about is creating the endpoint that you wanna request. The SharePoint request object, the SP HTTP client object that handles including all the necessary HTTP headers to authenticate the request of the current user on the page as well as handle all the other requirements in making the request. Yes, that means you don't have to include the jQuery library in your project just to call jQuery.ajax method. In fact, if that's the only reason you're using jQuery, please stop, you're bloating your project for no reason at all. For those customers creating SharePoint framework solutions for SharePoint online, Microsoft has also included two other APIs to call Microsoft Graph and other secured endpoints that are secured with Azure Active Directory and Azure AD. The MS Graph Client Factory and the MS Graph Client APIs, they're gonna wrap the Microsoft Graph JavaScript SDK and they're gonna handle all the initialization to authenticate the request from your SPFX solutions that call Microsoft Graph endpoints. Now, in those cases where you need to call a third party API, you can use either the HTTP client for an open API, one that has no authentication requirements to it or simple authentication where you have to put like a token in the URL or you can use the Azure AD HTTP Client Factory and the associated Azure AD HTTP Client Objects to obtain an access token from Azure AD that SharePoint online has been granted access to. Now the SharePoint framework is designed to be used by both first party and third party developers. What does that mean? So third party developers are people who create solutions for SharePoint such as consultants, customers and ISVs, independent software vendors. So in other words, a third party developer is building something to extend SharePoint. This is different from a first party developer. That's a Microsoft developer. That's somebody who actually works for Microsoft. And this means that Microsoft has to use the SharePoint framework to extend SharePoint. For example, things like communication sites and hub sites, they use SharePoint framework to implement certain components. Now this is a change from previous versions of SharePoint development models that were only for third party developers. When only third party developers use an API, Microsoft doesn't experience the same pain points and thus they don't appreciate the shortcomings of that API. But when Microsoft uses the same API, third party developers use, not only do they experience the same bugs and shortcomings, but they also introduce features they need which third party developers can also use. Okay, so that's a lot of the what is the SharePoint framework. Now let's transition. Let's talk a little bit more about what can you build? What kind, it's a developer, man. We always want to know what I can build. So let's talk a little bit about that. That's the second question I wanted to address about what we can actually build. So what can you use it for? What can you do with it? SharePoint framework provides developers with a couple different types of things that they can build. We can build web parts, we can build extensions, and we can build library components, and we can build these other things called adaptive card extensions or ACES if we're gonna extend Viva connections. Some of these things include additional subtypes or components that they can create. So let's start by looking at web parts. Web parts are the oldest type of customizations that developers have been able to build for the SharePoint framework. These are boxes of functionality that are added to the page. Developers can use pure HTML elements and CSS to implement the user experience for their web parts. Or they can use a web framework like Reactor Angular as I've already talked about to implement more complex applications. All web parts have public properties that enable users to modify the settings and the configuration of a web part. And web parts are also the core building block for two other types of components that developers can build. We can build single page app pages, otherwise known as single page apps or spas. These are really just big web parts on a page. Developers can create these spas as a web part by simply setting a specific string in the web parts manifest to tell SharePoint that we can deploy it as a spa. A user can then create an instance of the spa from the SharePoint user interface. So what SharePoint does is it just creates a brand new page and adds the web part to the page as a spa. The page doesn't allow any other web parts on the page. So to the user, it just looks like an application. Developers can also use SPFX web parts to create custom apps for Microsoft Teams. The web parts manifest can be used to indicate that it can be used as a custom tab or other types of Microsoft Teams extensions. Microsoft Teams tabs and other extensibility options like task modules, they're just iframes that are loaded in a web page. So when you use a web part for a custom Microsoft Teams tab, a task module or one of the other supportive Microsoft Teams customization options, SharePoint adds the web part when requested to a SharePoint page with no other user interface components that are on it. This way you can use a single SPFX web part as both a web part in SharePoint or as a tab in a Microsoft Teams custom app. Now another type of SPFX component that we can create is an extension. Now extensions are used to customize or augment the SharePoint user interface across sites or across the entire tenant. Most extensions are implementations of customization options that developers had in previous development models or deployment models and in SharePoint classic sites. The application customizer extension type is one of those three types that we have with extensions. This is gonna allow us to add client-side script to all pages in our SharePoint site as well as having option to like set a header or a footer to all pages on the site. These replace what you might have remembered in prior deployment models as the script link control or the delegate control that we have with like the full trust model. Command sets are another type of extension that are gonna allow developers to add toolbar buttons as well as items to the item context menu to SharePoint lists and libraries. These replace what we used to call custom actions in the SharePoint feature schema. And then field customizer is another type of a SharePoint framework extension that allows developers to use script to define how a cell within a grid view of a SharePoint list is gonna be displayed. Developers can use the data in the SharePoint list item to render the results and for instance, or for example, you can use a field customizer to display colored bars or a key performance indicator for more engaging experience than just like some text-based percentage value in a field cell. You might remember something from the full trust development days called JS link or client-side rendering or CSR. That's what this is gonna is replacing. Now, another type of extension we have is something called a search extension. It allows developers to modify the search query that's been entered by the user in the Microsoft search bar prior to the search query returning the results engine. So that's everything that I wanted to cover in this episode. My goal of this episode was just to answer the question, what is the SharePoint framework? This piece is one of a multi-part series that I answer the questions that are most common that I see with related to the SharePoint framework. I call this series the SharePoint framework 5Ws and 1H answered and it's supposed to give you the best high-level picture of the SharePoint framework. You can find links to the other pieces in this series and the notes related to this installment. You got a question or a comment? Let me know what you think by dropping a comment in the video below or tweeting me at Andrew Connell or at Voitanos. And if you liked this episode, man, I'd really appreciate it if you'd share it with the rest of your friends. This episode is also available as a blog post on Voitanos.io.