Why did Microsoft create the SharePoint Framework (SPFx)?

As SharePoint evolved over time into the product we have today, Microsoft iterated over development models until they found one that worked for both developers & Microsoft alike. They came to this conclusion by addressing the challenges and requirements they were faced and by observing what customers were doing through their implicit actions.

by Andrew Connell

Last updated September 21, 2024

16 minutes read

Focus Mode

2003 – 2009: Full trust solutions - SharePoint Portal Server 2003 (WSS v2) & Office SharePoint Server 2007 (WSS v3)
2010 – 2012: Partial trust solutions - SharePoint Server 2010 & SharePoint Online
2013 – 2016: Add-in model - SharePoint Server 2013 & SharePoint Online
2013 – 2016: JavaScript injection - SharePoint Server 2013 & SharePoint Online
What’s next for SharePoint developers?
Conclusion

This is one of a multi-part series of posts answering the most common questions on the SharePoint Framework. This series, SharePoint Framework Five “W"s & One “H” answered, gives you the best high-level picture of the SharePoint Framework. I (Andrew Connell) wrote this series in late 2020 to help people new to the SharePoint Framework get the answers to the most common and basic questions about the SharePoint Framework.

2003 – 2009: Full trust solutions - SharePoint Portal Server 2003 (WSS v2) & Office SharePoint Server 2007 (WSS v3)

While SharePoint’s roots go back before 2003 to the days when we called it Tahoe, I want to start in 2003.

In SharePoint Portal Server 2003 & Windows SharePoint Services v2 (SPS 2003 & WSS v2), Microsoft shipped a product that was designed as a departmental portal and collaboration space. Developers weren’t given any sort of a development model, but if you knew where to look, you could create custom solutions.

In [Microsoft] Office SharePoint Server 2007 & Windows SharePoint Services v3 (MOSS 2007 & WSS v3), Microsoft introduced two concepts that were a huge step forward for custom solutions: Features & Solutions. Features were effectively plugins of reusable functionality you could add to SharePoint and solutions were the packaging & deployment vehicle to get this custom code added to SharePoint & 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 in SharePoint.

When developers built custom solutions during this time, in either SPS 2003 or MOSS 2007, they could do anything they wanted to do with the API. This allowed us to build some very powerful and robust solutions, but there were also some drawbacks.

Full trust solutions

These customizations executed within the same process as the SharePoint process. This means they ran under full trust, which means they had full access to the SharePoint API enabling some 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. Yup, that means if your custom stock ticker web part threw a divide by zero exception, your entire corporate intranet was also crashing.

At the time we called these solutions, but looking back, these were later named full trust solutions for reasons that will be clear in the next section.

SharePoint was expensive & hard to run

Around this time, Microsoft started looking more closely at the business of SharePoint. At this time, they saw how SharePoint was mostly only available to large organizations. It was expensive to license, expensive to host, and required a lot of domain knowledge in that administrators had to know not only how to manage SharePoint but also Windows & SQL Server to name just a few other products.

The workings of a hosted SharePoint service started to grow. First, it happened in the ecosystem, and then Microsoft wanted to get into the game. To do this at scale, you really needed to have the ability to put multiple customers on the same SharePoint installation. One customer per server just wasn’t going to scale. We call this architecture single-tenant in that one customer ( aka: tenant)

But the idea of allowing customers to deploy their customizations to a server where one broken web part could bring down the process not just for their intranet but also those sites of other customers on the same server wasn’t going to work.

So… they needed a better option.

2010 – 2012: Partial trust solutions - SharePoint Server 2010 & SharePoint Online

In SharePoint Server 2010, Microsoft introduced a few new things to make SharePoint more multi-tenant friendly. They introduced the concept of service applications which allowed administrators to create a process, like a search indexer, that was separate from a site and could be shared by multiple sites.

Partial trust solutions

But for developers, they introduced the sandbox. The sandbox was a separate process from the core SharePoint process that would run sandboxed solutions. When a web part in a sandboxed solution was requested on a page, the core SharePoint process would call the sandbox process to run the web part and get the results to display in the SharePoint page.

This meant that if your custom code crashed, it wouldn’t bring down the SharePoint site; only the sandbox process would crash. So, customer SharePoint sites would stay up, but you’d have a little hole where that custom web part was supposed to be. They thought this would be a fair trade-off.

We called these sandboxed solutions partial trust solutions because this sandboxed process didn’t have all the same capabilities or permissions as the core SharePoint process.

Sandboxed solutions were too restrictive

The sandboxed process was tied to a specific web app and partial trust solutions could only access the site collection they were deployed to. You couldn’t reach across site collections, a common thing developers did in custom full trust solutions.

But even more challenging, was that these partial trust solutions didn’t have full access to the complete SharePoint API; they only had access to a subset of the complete SharePoint API.

This meant that many of the things we used to do as developers in our full trust solutions were impossible.

2013 – 2016: Add-in model - SharePoint Server 2013 & SharePoint Online

Microsoft really went back to the drawing board in SharePoint Server 2013. They took a step back and asked themselves: “what do we really need to get developers to do?” The answer: we need to get them off of SharePoint. Specifically, Microsoft needed to get our custom code off of the SharePoint servers.

The ultimate goal was to get our code to run either in the browser or in a process completely separate from SharePoint. But at the same time, they needed to give developers a way to customize SharePoint sites and interact with the data within these sites.

And they came up with a solution…

SharePoint Add-in model

Microsoft introduced a new way of developing customizations in SharePoint with the SharePoint Server 2013 release. The SharePoint App model, later renamed to the SharePoint Add-in model, enabled developers to create solutions that ran completely external to SharePoint. Custom code ran either in the browser as client-side script ( aka: SharePoint Hosted Add-ins) or in some other process ( aka: Provider Hosted Add-ins), such as in, but not limited to, an Azure web app.

Significantly improved SharePoint REST API & CSOM

At the same time, Microsoft also made significant investments in the SharePoint REST API and CSOM. They needed to if all these custom solutions were going to be able to talk to SharePoint.

Conclusion

And that is where we are today. This new approach that Microsoft came up with in 2016 is the SharePoint Framework.

My goal in this post was to provide some context and explain the developer history of SharePoint. Hopefully now that you have some context, you see the following:

As SharePoint evolved over time into the product 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 & Microsoft alike. They came to this conclusion by addressing the challenges and requirements they faced and by observing what customers were doing through their implicit actions.