SharePoint Framework – Part 1 (Why SPFx)

After speaking at some international events and organizing workshops on SharePoint Framework, It inspires me to share the knowledge through web platform. I am going to start a series of SharePoint Framework (SPFx).

Introduction:

SharePoint Framework was announced in May 2016. Before diving into what is SPFx, I will explain bit about SharePoint Development history because I think it’s important to understand where we came from and what goals Microsoft is trying to solve by introducing a SharePoint Framework.

Why do we need the SharePoint Framework?

SharePoint Portal Server 2003 – The first version of SharePoint was really impressed by developers. We had 2001 and Team Services 2002 but in 2003 based on SharePoint Team Services 2.0 the developers used the concept of customization.

It was built on .NET Framework2.0. We don’t have any development model. The APIs was not documented. If you remember the tool called Reflector were used in those days. The only API we had access to is “Server-Side” API and this was the same API what Microsoft were using.

There were no client-side API available. Anything we did, anything we customized all ran in Full trust.

The manual deployment process includes: Create dll, compile and manually XCOPY that over to Global assembly cache on your production server. This was not the best option for the developer’s point of view. Then came

Office SharePoint Server 2007 – It was based on Windows SharePoint Services 3.0. This is where you see most people start jump into SharePoint development. This one still we only have Server-Side API. No Client-side APIs available. Everything we code – all customizations ran in full trust.

We did get two new ways to implement our customizations and deploy into SharePoint and that was with the plug in model: Let me call it: “Features” and deployment vehicle called “Solutions” is really just a cabinet file that was renamed to WSP file for Windows SharePoint Services solution package. That cabinet file contains features and dll files and everything we needed to deploy on the server. This really triggered a wave of SharePoint Development & extensibility.

SharePoint 2007 was stand out to manage. It required more efforts and hard work to deploy the solutions. So lot of organizations were looking for an option like – I want SharePoint but I do not want to host it. So Microsoft started looking around hosting options. They thought about multi-tenant hosting options (same SharePoint deployment can be used to host two or more customers) but the way we are doing the SharePoint customization was not going to work with that model.

Because If I wrote a component, and that component blow up on the SharePoint Server – it may break down the SharePoint Process which is not for my customers only but eventually it effects other customers who are using same hardware. So not really a good experience there. So, Microsoft really started to address this and

SharePoint Server 2010 – This is where they have introduced something called – “Sandbox Solutions” also known as partially trusted solutions.

The sandbox solution would not work outside of site collection and it allowed us to work where we wrote something blow up will affect only our customer not everyone else.

Now the problem with this was that the developers quickly find the sandbox solutions were too limiting.

In SP2010 Microsoft did introduce a Client-Side API called CSOM (Client side object model).

They rolled out Office 365 with SharePoint 2010 and they found few things needs to address and they come up with

SharePoint Server 2013 and SharePoint Online – That was the first real multi-tenant version of SharePoint as far as the developers are concerned.

It was based on SharePoint Foundation 2013 and heavy investments in Client-side APIs.

They found we can’t put the code on the servers and they have introduced SharePoint Add-in model: It allowed us two different ways to deploy either

SharePoint Hosted Add-ins which meant that all client side stuff HTML, CSS, JavaScript stored in SharePoint but it was actually executed in the client. It was not run on the server.

Provider Hosted Add-ins – you can put anything you want out there but it will run outside of the SharePoint like an Azure, AWS or your own IIS Box on premises.

Now we have other challenges with Add-ins : The biggest challenge we had with add-ins is that they really limited how our stuff of service inside SharePoint site so whenever we add an Add-ins in SharePoint site it creates child site with add-ins is installed or provision. This allowed Microsoft to isolate add-ins for the rest of SharePoint which was good security and good barrier between their stuff and our stuff.

But it was not really looking for as 3rd party developers. All our stuff try to get surfaced inside of the SharePoint site had to be done with iFrame. It was not easy to make it responsive. It was very slow in terms of performance to render the content. So to address that most of the developers had started using JavaScript injection techniques.

So using things like Script Editor and Content Editor Web Part for client side customization, there are lots of challenges with Script Editor Web Parts as well:

1. Customizations were brittle (Any one can edit the page and update the script)
2. Customizations not easily repeatable (we cannot create package for deployment)
3. Scripts is not always allowed – No Script.

Script editor web part was awesome except there are a certain kind of sites in SharePoint called Self-service site creation and that applies to My Sites. Team sites and group sites. And by default, they have a property on their called “Script Disabled” on those kinds of sites.

Unfortunately, script editor web part is not marked as a safe for scripting.

So, Microsoft looked at all this stuff and found that what we need to change this style of development and they came up with this concept called the SharePoint Framework.