Welcome to the SPFx Series! In this blog series, we’ll dive deep into the SharePoint Framework (SPFx), a powerful toolset for building modern, dynamic solutions in SharePoint and Microsoft 365. In this blogpost we’ll dive into the history of SharePoint Development

Web parts as Farm solutions ~ 2007

In the past, there was only SharePoint On-Premise, there was no question of a Cloud environment since the first introduction of SharePoint Online was in 2012. There was only SharePoint On-Premise that was installed on local servers. These On-Premise environments could be customized and personalized by creating and implementing webparts. These webparts were created in C# and Visual Studio was used for that. Once a webpart was ready, one could bundle the code into a wsp file, such a wsp file is in fact a Cabinet file and then implement this file in the SharePoint Central Admin web application.

When implementing such a wsp solution, the dll files were placed in the BIN folder of the GAC (General Assembly Cache).

Disadvantage of this way of working: There were generally code access security restrictions on the code that was installed in the GAC. Therefore, there was no in-depth security. In other words, the code that was written was a Full Trust code

Sandbox Solutions ~ 2010

In Microsoft SharePoint 2010, Sandbox solutions were created. These were applications that ran in a secure, controlled process that had access to a limited part of the web farm. Microsoft SharePoint 2010 uses a combination of features, solution galleries, solution monitoring, and a validation framework to enable sandbox solutions.

In Visual Studio, you could choose a farm solution to deploy the solution as a farm solution or if you set the Sandboxed Solution property to false. As a result, the solution was deployed to the Web Farm and these changes applied to the Web Farm and all site collections under it.

A Sandbox solution, on the other hand, only related to a site collection. You could achieve this by setting the Sandboxed Solution property to true or by choosing to deploy the solution from Visual Studio as a sandbox solution

But why?

In Windows SharePoint Services 3.0, it was only possible to deploy solutions at the farm level. This meant that potentially harmful or destabilizing solutions could be implemented that impacted the entire web farm and all the site collection and applications running under it.

However, by using sandbox solutions, solutions could be implemented in a sub-area of the farm: a specific site collection. To provide additional protection, the solution assembly was not loaded into the main IIS Process (w3wp.exe). Instead, it was loaded into a separate process (SPUCWorkerProcess.exe); which is monitored and implements quotas and restrictions to protect the farm from sandbox solutions that perform malicious activities.

SharePoint add-ins ~ 2013

In 2013, Microsoft released SharePoint add-ins. Originally called this Microsoft Apps, but later they changed this name to add-ins.

You had 2 types of Microsoft add-ins:

• SharePoint hosted: all client stuff (HTML, CSS, JavaScript) code that was stored in SP but was executed as a client. It was served by SharePoint but it didn’t run on the server
• Provider hosted: could hold everything but it had to run outside of SP. The biggest challenge was how limited the things of an add-in were presented in SharePoint. Because every time we added an add-in to a SharePoint site, SharePoint created a child site where the add-in was installed. This allowed Microsoft to isolate the add-in from the rest of SharePoint. Security wise: Great, but everything had to be done via iframe and they were not responsive etc.

Script injection ~ 2013

Since add-ins turned out to be less than ideal, developers started using JavaScript injection via Content Editor Webparts to customize the UI experience. But the dangerous thing about that was that there was nothing to stop anyone from editing pages in any way. Same with SharePoint designer where you could customize the MasterPage, and since a MasterPage is used on every page in your SharePoint farm, that’s not exactly secure.

In addition, your JavaScript could be broken when SharePoint made an update.

SPFx 2017

In 2017, Microsoft came up with the SharePoint Framework, which offered developers the ability to create client-side customization instead of server-side that could be packaged and uploaded to SharePoint sites, just like SharePoint solutions & add-ins did in previous versions. In addition, these client-side customizations have the ability to easily use the APIs to use SharePoint data that the framework offers, but you are not limited to that. No, you can query any data with the SharePoint REST API, Microsoft Graph or any API you want. For example, an Azure Function API, an API from AWS or even something completely different like 4ME. 4ME is a service management system that uses the same authorization protocol as Office 365, namely OAUTH 2.0, so you could use the 4ME APIs and do all kinds of things with them within the SharePoint Framework.

In addition, all adjustments are made within the current context. No more elevated privileges as was possible with server side solutions and most importantly, no iframes anymore. When you want to call data, you don’t have to authenticate because the code will execute that call to the data as the logged-in user. So you don’t have that heavy authentication authorization layer payload anymore that an iframe would need.

Customizations are responsive and accessible where the development experience includes the web development stack, we’ll get to that later, but what that means is that you’re no longer tied to Microsoft or associated products, you can perfectly use open source tools to create SharePoint Framework solutions! You don’t need a heavy Visual Studio for it, which is also paying. No, you can use lightweight tools that are free.

In addition, the SharePoint Framework solutions work on both classic and modern pages in SharePoint. Finally, SharePoint Framework solutions are accessible to first-line people and third-line people. 3rd line people are people who create things. It used to be the case that, as with SharePoint Add-ins, for example, these were only accessible to third line people. We had a SharePoint environment and only the third-line people could add things that would be useful within that SharePoint environment. First-line people are Microsoft pushing their features to SharePoint online that we can take advantage of, and we, as third-line people, can then add our own customizations that we think will be useful.