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. 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.
When you try to learn or understand something new, I’ve always found the best approach is to first get a grasp on answering the following question: why. The answer to this question gives you such valuable insight into the motivations, reasons and goals for the thing you want to learn.
In the case of the SharePoint Framework (SPFx), I find most of the questions I get from people new to SPFx 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 requires you to have some history under your belt. That’s what I’ll do in this article – give you a little SharePoint history lesson.
This is going to be a rather lengthy article because it takes time to understand where we came from. 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: 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 requires they were faced and by observing what customers were doing through their implicit actions.
So… let’s get started!
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.
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.
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, 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. This put SharePoint out of many medium sized companies and most small businesses.
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 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.
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.
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.
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. So what did customers do? Many of them ignored sandboxed solutions and told Microsoft “go back to the drawing board”.
SharePoint Server 2010 was the first version that Microsoft used to implement their SharePoint Online (SPO) offering in Office 365. Customers signing up for SPO were limited to only partial trust solutions for any custom code they deployed & subject to the throttling limits imposed on 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 customers were having. Because they weren’t hosting SharePoint so they couldn’t see not just what types of solutions customers were creating, but how many there were.
When Microsoft extended SharePoint, they used fully trusted solutions. Why? Because they were the only customer and had complete control over SharePoint both in the product that was shipped to customers in SharePoint Server 2010, but also in SharePoint Online.
So, while you can look at the fully trusted solution development model as a first-party (Microsoft) & third-party (customers) 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 as you’ll learn about later in this article and one that I touched on in the first part of this series: What is the SharePoint Framework: SPFx is both for first-party & third-party developers.
Before I move on, I want to point out that SharePoint Server 2010 is when Microsoft introduced the beginnings of the SharePoint REST API. This API replaced task-specific ASMX-style web services and opened SharePoint up to a lot more external development off the SharePoint servers. This development happened both in server-side solutions with .NET as well as with client-side solutions in the browser using libraries like jQuery.
Are you ready to learn the SharePoint Framework? Check out our on-demand video course with over 30 hours of demos, explanation and downloadable code: Mastering the SharePoint Framework!
Start with the FREE Starter bundle that includes three (3) chapters including a walk-through of setting up your developer environment to start creating SharePoint Framework components.
Once you start working, jump to the Fundamentals bundle to learn the basics and start creating SharePoint Framework components. The Ultimate bundle will make you a master at the SharePoint Framework with automated testing, continuous monitoring, implement CI/CD practices, and learn other advanced techniques.
The Ultimate bundle includes the Fundamentals bundle and grants you access to our live monthly office hours meetings as well as access to our student-only mastermind group.
Anyway… due to the restrictions I previously explained with partial trust solutions, customers who wanted to customize their SharePoint deployments didn’t move to SPO. They couldn’t address the business requirements that full trust solutions enabled.
Microsoft got the feedback from customers: give us a better option for custom code solutions in SharePoint Online that allow us to meet our needs.
So… yet again, Microsoft needed a better option for developers…
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…
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.
Ever wonder why Microsoft renamed apps to add-ins in SharePoint? Apple forced their hand… yeah… seriously!
The App model wasn’t exclusive to SharePoint, rather the Office clients were using it as well for their new development model. The idea was you could build apps and install them within Office, just like we can do today with Office Add-ins (which were also renamed).
Well, when Microsoft wanted to put Microsoft Office in the iOS App Store, Apple said no: apps go in the App Store, and you can’t put apps in apps. Apple wouldn’t budge, so in order to get Office into the App Store, they renamed Apps to Add-ins. Now you could install the Office apps on your iPad and then add Add-ins to them!
Because SharePoint & Office clients were in the same organization, it only made sense to keep things consistent, so the app model was renamed across the Office division to the Add-in model.
Yup… Apple effectively forced Microsoft to rename the SharePoint App model to the SharePoint Add-in model… crazy huh?
Apps were given their own identities that you could assign permissions to, just like you can with users.
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 get kicked off the SharePoint servers. Developers needed a way to talk to SharePoint.
Aside from the steep learning curve associated with developers learning OAuth (a key part of the new add-in model identities) and the REST API, Microsoft also made another curious design decision.
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. This was done so a custom solution couldn’t easily access the data in the parent site. The label ghetto web started to get popular because these subsites (aka: webs) weren’t treated the same as existing sites.
This frustrated developers and customers because now they were left without a good option to extend existing SharePoint sites.
And as such, customers didn’t adopt the add-in model as much as Microsoft would have hoped.
I’m going to repeat myself a little with the previous sections. I think one of the reasons the add-in model wasn’t adopted by most 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. History was repeating itself.
The Add-in model was exclusively only a third-party development model which meant Microsoft didn’t feel the same challenges and pains customers were feeling.
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 solved the problem on their own with the tools they had available.
No, that’s not a typo on the date. This phase of the SharePoint history overlaps with he Add-in model.
After a bad experience with the sandboxed/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 made it a bad option for many developers. First, the learning curve to working with apps, OAuth, and REST was quite steep for many developers. But more importantly, the add-in model didn’t allow for developers to make changes to existing sites which is what their customers were asking for.
Developers weren’t going to wait around for another solution from Microsoft so they took to the tools that were available to them.
Developers quickly realized that one option available to them to make customizations in SharePoint sites was using client-side technologies.
This approach, coupled with leveraging the vastly improved REST API, empowered client-side developers to customize and extend existing SharePoint sites.
But, just like all the other development models, there were shortcomings with this option. All customizations were manually deployed. Deployment went something like this:
- Add CEWP to the page
- Edit CEWP to point to the client side script previously uploaded
The problem with this approach is that anyone with edit rights on the page could change the code of the solution. While this is certainly an advantage to rapid development in many scenarios, it is a problem in organizations where many users rely on a custom solution and someone can easily make a change without going through a change management process or introduces a bug in the solution.
In an organization with a rigorous change management process, these manual steps aren’t the best way to get custom solutions deployed. Nor can a solution like this be easily scriptable to automate deployment of the custom solution.
In addition many customizations employed 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’s DOM as an API so they would change it to suit their needs. For instance, maybe a new button was added to the user interface, or the HTML element’s ID changed. If your custom script relies on an element ID that changes, an update to SharePoint Online or SharePoint Server by Microsoft can break your solution with no warning.
After the SharePoint 2013 release, SharePoint engineering started looking at the SharePoint development landscape. They were evaluating what developers were using, were not using, and balance those with the current goals of the platform.
Microsoft wanted to take this approach customers were clearly already doing, and not only adopt it, but improve upon it.
This new approach not only addressed many of the goals & needs of SharePoint, but also of customers.
- Custom solutions would be completely decoupled from the SharePoint process as execute entirely in the client (browser). Customizations are secure in that they only run in the context of the current user.
- Customers can apply customizations to existing sites through simply installing an app.
- Solutions are easier to create and deploy in that they don’t need to be hosted external to SharePoint. Solutions are deployed to SharePoint and while the files are stored in SharePoint, they are only executed in the browser.
- Establish an API (contract) on areas of the page that can be customized.
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 requires they were faced and by observing what customers were doing through their implicit actions.