 A SharePoint evolved over time into the product that we have today, Microsoft iterated over different development models until they found one that worked for both developers and Microsoft alike. They came to this conclusion by addressing the challenges and the requirements that they were faced by observing what customers were doing through their implicit actions. Do you want to learn why they created it? That's what this episode is all about. Hey, I'm Nubi Paolo. 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. Hi, I'm Andrew. I think that when you try to learn something or understand something new, I've always found the best approach is to first get a grasp on answering the following question. Why? To answer this question gives you so much valuable insight into the motivations, the reasons and the goals for the thing that you want to learn. And in the case of the SharePoint framework, I find that most of the questions that I get from people new to SharePoint framework would resolve themselves if they had taken some time to get a little perspective on history and context. Answering the question, why did Microsoft create the SharePoint framework? It just requires you to have some history under your belt. And that's what I'm going to do in this episode. I'm going to give you a little bit of a SharePoint history lesson. Now, just a fair warning, this is a rather lengthy episode because it takes time to understand where we came from. But before I do that, let me answer my own question. Why do I need a SharePoint history lesson to understand why Microsoft created the SharePoint framework? The reason is simple. A SharePoint evolved over time into the product that we have today, one that is primarily a hosted implementation in SharePoint Online. Microsoft iterated through multiple development models until they found one that worked for both developers and Microsoft alike. And they came to this conclusion by addressing the challenges and the requirements that they faced and by observing what customers were doing throughout their implicit actions. So let's get started with the history. We're first going to start with full trust solutions. SharePoint's roots go way back to 2003 to the days when we called it Tahoe. That's when I started working with SharePoint. Microsoft SharePoint Portal Server and Windows SharePoint Services v2, also known as SPS 2003 and WSS v2, Microsoft shipped a product that was designed as a departmental portal solution in a collaboration space. Developers weren't given any sort of development model. But if you knew where to look, you could create custom solutions. In Microsoft Office SharePoint Server 2007 and WS and Windows SharePoint Services v3, known as Moss 2007 and WSS v3, Microsoft introduced two concepts that were a huge step forward for customizations and that's features and solutions. Features were effectively plug-ins of reusable functionality that you could add to SharePoint and solutions where the packaging and deployment vehicle to get this custom code added to SharePoint and the server. Both of these things are still with us today in modern-date SharePoint. Features and solutions are still used to deploy SPFX solutions inside of SharePoint. And when developers build custom solutions during this time and either SPS 2003 or Moss 2007, they can do anything that they wanted to with the API. And this allowed us to build some really powerful and robust solutions, but there were some drawbacks. These customizations executed within the same process as the SharePoint process and this meant that they ran under full trust, which means they had full access to the SharePoint API, enabling some really powerful customizations. But the downside was that if the custom code ever failed and crashed, it would bring down the entire process, including the hosting SharePoint process. Yeah, that means that if your custom stock ticker web part through a divide by zero exception, your entire corporate intranet can crash down. At the same time or at the time we called these solutions, but looking back, these were later named to full trust solutions for reasons that well, they'll become clear in just a minute. Now, around this time, Microsoft was started looking more closely at the business of SharePoint. And at this time, they saw how SharePoint was mostly available only to large organizations. Let's face it, this thing was expensive. It was expensive to license. It was expensive to host. It required a lot of domain knowledge and that administrators had to know not only how to manage SharePoint, but also Windows, SQL Server, just to name a few other products. This put SharePoint way out of reach from many medium-sized companies and almost all small businesses. The workings of hosted SharePoint services started to grow. And as it first happened in the ecosystem, and then Microsoft wanted to get into the game. Now, to do this at scale, you really need to have the ability to put multiple customers on the same SharePoint installation. One customer just wasn't going to scale. We call that architecture single tenant. And that one customer. But the customer is a tenant. But the idea of allowing customers to deploy their customizations to a server where one broken web part can bring down the whole process, not just for their intranet, but for all the other sites and all the other customizations that were on the same server, that wasn't going to work. So they needed a better option. So in SharePoint 2010, Microsoft introduced a few things to make SharePoint more multi-tenant friendly. They introduced the concept of service applications. And that allowed administrators to create a process like a search indexer that was separate from a site and can be shared by multiple sites. But for developers, they introduced this concept called a sandbox. And the sandbox was a separate process from the core SharePoint process that would run something called sandbox solutions. So when a web part was in a sandbox solution and it was requested on the page, the core SharePoint process would call the sandbox process to go run the web part, get the results to display them back on the SharePoint page. This meant that if your custom code crashed, it wouldn't bring down the entire SharePoint site. Only the sandbox process would crash. So the customer's SharePoint sites would actually stay up. But you'd have this little hole where the custom web part was supposed to be. They thought, as a fair trade, we call these sandbox solutions partial trust solutions. Because the sandbox process, this process didn't have all the same capabilities of the full trust stuff had that we talked about earlier. The sandbox process was tied to specific web applications. And the partial trust solutions could only access the site collection that they were deployed to. So I couldn't have a sandbox solution reach across the different site collections. It only was able to work within the sandbox or the site collection that it was deployed to. In addition, they only had access to a subset of the SharePoint API. So I couldn't access things like the farm or web applications or stuff like that. This meant that many of the things that we as developers that were building our full trust solutions, we couldn't do it. So what did customers do? A lot of them just ignored the sandbox solutions and told Microsoft, go back to the drawing board. This ain't gonna work. SharePoint Server 2010 was the first version that Microsoft used to implement their SharePoint online offering, SPO, inside of a service they called Office 365. Today we call it Microsoft 365. Customers that were signing up for SPO were limited to only deploying partial trust solutions for any custom code that they deployed and they were subject to the throttling limits that were imposed by the sandbox. I think one of the reasons the sandbox and partially trusted solutions were dead on arrival when it was introduced was because Microsoft didn't fully appreciate the problem that customers were having. Because Microsoft wasn't hosting SharePoint, they couldn't see what types of solutions customers were creating or how many of them there were that were out there. When Microsoft extended SharePoint, they used fully trusted solutions. Why? Because they were the only customer. So they had complete control over SharePoint, both in the product that was shipped to customers in SharePoint Server 2010 and also SharePoint online. So while you can look at the fully trusted solution development model as first party, Microsoft, and third party customers, that development model, the partially trusted solution model was exclusively only a third party development model. This is a critical point in the history of the SharePoint framework because you're going to learn about later on in this episode. And it's one that I touched on in the first installment of this series of episodes on what is the SharePoint framework. Now, before I continue here, I do want to point out that SharePoint Server 2010 is when Microsoft introduced the beginnings of a SharePoint REST API. The API replaced a specific task-based kind of ASMX-style web services setup, and it opened up SharePoint to a lot more external development off the SharePoint Server. This development happened both in a server-side solution with .NET, as well as with client-side solutions in the browser. And at the time, we were mostly using libraries like jQuery. But they also introduced a client-side SDK, the client-side object model, or the CSOM, and that included a JavaScript SDK, a .NET SDK, and a SilverLite SDK, if you remember SilverLite. Now, today we only have the .NET SDK implementation, which is what we mean when we refer to the CSOM. Now, anyway, due to the restrictions I've already explained about partially trusted solutions, customers who wanted to customize their SharePoint deployments, they didn't move to SharePoint online. They couldn't address their business requirements that full trust solutions would enable them to do. So, Microsoft got the feedback from customers, give us a better option for custom-closed solutions in SharePoint online that allow us to meet the needs of our customers. So, yet again, Microsoft needed to go back to the drawing board to come up with a better option for developers. So, now we're at about 2013, 2016, and I want to introduce something new called the add-in model. And Microsoft really went back to the drawing board in SharePoint Server 2013. They took a step back and they asked themselves, what do we really need to get developers to do? And the answer they came up with, they said, we need to get them off SharePoint. Specifically, Microsoft needed to get our own custom code off their servers. So, the ultimate goal was to get our code to run either in the browser or in some other process that's completely external to SharePoint. But at the same time, they needed to give us a way as developers to customize SharePoint sites and interact with the data within these sites. So, they came up with a solution. They introduced this thing called the SharePoint add-in model, or app model. Now, Microsoft introduced this new way of developing customizations in SharePoint with SharePoint Server 2013 release. The SharePoint app model was later renamed to the add-in model, enabled developers to create solutions that ran completely external to SharePoint. Custom code ran either in the browser as a client-side script or in some other process. So, those were called provider-hosted add-ins. If it was client-side script, they were SharePoint-hosted add-ins. So, this meant that we were not limited to, but we could use things like an Azure web app or Azure Functions. Apps were given their own identities so that you could assign permissions to the app just like you could assign it to users. Now, at the same time they did this, Microsoft made significant investments in the SharePoint REST API and in the CSOM. They needed to because if all these custom solutions were getting kicked off the SharePoint servers, developers needed a way to talk to SharePoint. So, the REST API and the CSOM was the best way to do it. Unfortunately, the SharePoint add-ins were treated as second class. I mean, these things that people started to call ghetto webs. What is this? Well, let me explain something. Aside from the steep learning curve associated with developers learning OAuth and the REST API, Microsoft also made another curious design decision. The SharePoint add-ins weren't added to existing SharePoint sites. Rather, when they were installed, they were added to subsites that had their own unique URLs. And this was done so a custom solution couldn't easily access data in the parent site. The label ghetto web started to get popular because these sites, SharePoint sites or webs, they weren't treated the same as existing sites. And this frustrated developers and customers because now they're left without a good option to extend SharePoint sites at all. And as such, customers didn't really adopt the add-in model as much as Microsoft would have hoped. Now, I'm going to repeat myself a little here with the previous things that I've already said because I think that one of the reasons the add-in model wasn't adopted by customers was because Microsoft didn't fully appreciate the problem customers were having. Microsoft continued to use fully trusted solutions to extend SharePoint. They didn't use the add-in model to extend SharePoint. This is history repeating itself. The add-in model is exclusively a third-party development model, which meant that Microsoft didn't feel the same challenges and pains that customers were feeling. So when SharePoint developers couldn't solve the requirements for their customers, they had to look elsewhere. This time, they didn't just tell Microsoft the add-in model wasn't working for them. This time, they went and solved the problem with their own tools that they had available. We're still in the 2013 and 2016 kind of timeframe right now. I'm not talking SharePoint releases, I mean just those years. Now, another thing happened about this same time when the add-in model came out. This next thing I'm going to describe, this happened at the same time of the add-in model. After a bad experience with the sandbox and partially trusted solutions, followed by the add-in model phase, customers started to take things into their own hands. The add-in model had some significant shortcomings that I've already discussed that made it a bad option for developers. First, there was a learning curve to working with apps. OAuth and REST was a pretty steep learning curve for a lot of developers at the time. And more importantly, the add-in model didn't allow for developers to make changes to existing sites, which is what their customers were really asking for. So, developers weren't going to wait around for another solution from Microsoft, so they took the tools that were available to them. Developers quickly realized that one option available to them to make customizations in SharePoint was using client-side technologies. SharePoint had long included the content editor web part, and more recently, the script editor web part. These two web parts enabled users to add richly-formatted content to a page, but more importantly, add JavaScript to the page. In this approach, coupled with leveraging the vastly improved REST APIs, empowered client-side developers to customize and extend existing SharePoint sites. But just like all the other development models, there were shortcomings to this option. All customizations were manually deployed. Development went something like this. Upload the assets to the document library, that's JavaScript, CSS, images, stuff like that. Add the content editor web part to the page, and then edit the content editor web part to point to the client-side script that you previously uploaded. Now, the problem with this approach is that anyone with edit rights could change the page of the solution. They could change the code in the solution. And while this is certainly an advantage for rapid development in many scenarios, it's a problem in organizations where many users rely on custom solutions and someone can easily make a change without going through a change management process or introduce a bug in a solution. In an organization with rigorous change management processes, these manual steps are not the best way to get custom solutions deployed, nor can a custom solution like this be easily scriptable to automate deployment of the custom solution. Also, in many of these customizations, they leveraged DOM manipulation, usually with utilities like jQuery, to inject or 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 page as DOM as an API, so they could change it whenever they wanted to to suit their needs. For instance, maybe a new button was added to the user interface, or an HTML element's ID value was changed. If your custom script relied on that element ID and it changed out of the blue, and Microsoft updated SharePoint Online or SharePoint Server, Microsoft was free to break your solution with no warning at all. All right, so what's next? Well, after the 2013 release, the SharePoint engineering team started looking at the SharePoint development landscape, and they were evaluating what developers were using and not using and balanced those with the current goals of their platform. One observation they had was that JavaScript injection, that technique of creating solutions, had become incredibly popular developers. In fact, the content editor web part and the script editor web part were by far the most used web parts in SharePoint Online, as they were usually the way people deployed their JavaScript-based customizations. And at the same time, they recognized shortcomings of this customization approach. And Microsoft wanted to take this approach customers were already dealing with and already doing and not only adopted, but they wanted to improve upon it. So this new approach not only addressed many of the goals and needs of SharePoint, but also of their customers. Custom solutions could be completely decoupled from the SharePoint process, as they would be executing entirely in the client and the browser. So customizations are secure and that they only run in the context of the current user. And furthermore, customers can apply customizations to existing sites through simply installing an app. Now, solutions are also easier to create and deploy and that they don't need to be hosted in some external place to SharePoint. Solutions are deployed to SharePoint and while the files are stored in SharePoint, they're only executed in the browser. And this also establishes an API or contract in areas of the page that can be customized. So that's where we are today. This new approach that Microsoft came up with in 2016 is the SharePoint framework. Now, again, my goal in this episode was to provide some context and explain the developer history of SharePoint. And hopefully now that you have this context, you can see the following. As Microsoft have followed over time to the product that we have today, one that is primarily hosted in SharePoint online, Microsoft iterated through multiple development models until they found one that worked for both developers and Microsoft alike. And they came to this conclusion by addressing the challenges and the requirements that they were facing by observing what customers were doing through their implicit actions. You got a question or 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.