Adventures with the SharePoint Framework (SPFx): Part 5 – Sanity Check

So far in this series of articles I have just addressed the plumbing of how to get a solution, built and up and running using the SPFx and have covered some important configuration options that you should consider. I’ve not built anything useful yet. Until now it’s just been the good old “Hello World” exercise. That will change with the next few articles, but before we move forward I feel it is important to do a bit of a sanity check to make sure we are doing the right thing by using the SPFx.

The Epiphany

I come for a traditional SharePoint developer background which means managed code, a proper debugging experience in a proper object-oriented programming language – C#. I’ve been building traditional server-side web parts for years and with some aplomb, even if I say so myself. I must confess to struggling a bit when Microsoft introduced the Cloud App Model. Of the 2 variants of the Cloud App Model, I steered clear of SharePoint Hosted Apps because these meant I was limited in lots of ways, including my choice of development language as it was basically JavaScript and REST. Instead I favoured the Provider Hosted App model where I could remain within my comfort zone by continuing to develop in C# using the Client SharePoint Object Model (CSOM), limiting and frustrating as it is.

When developing web parts or basically any enhancements to the UI, it was (and still is) difficult for me to face up to the reality that the traditional approach is all but dead. And the reason I come to this shocking realisation and starling conclusion can be summed up in a single word – Modern.

You see, the Modern UX is where Microsoft are pouring all their investment dollars. They’ve not spent any money on Classic in years and that’s not about to change. This is important because whilst client-side web parts are supported on Classic pages, Classic web parts, including all those build with either variant of the Cloud App Model, are not supported on Modern pages. If the penny didn’t drop with that last statement then read it again!

Up until recently you could get away with ignoring Modern because it was an ugly affair and most customers were happy enough with Classic and saw no pressing need to change. But things changed a few months back when Microsoft released the new Communication Portal and Modern Team Site templates. These puppies have Modern woven into their DNA and they look good. Anything that looks good attracts users like magpies after a shinny thing.

What’s more, they support Responsive Design meaning that they work well with tablets and smart-phones which everyone seems to accept as being the most prevalent business platform for the future. Personally, I don’t 100% buy into that but I do recognise that SharePoint in Classic mode was woefully inadequate for mobile and SharePoint in Modern is heaps better.

The only logical conclusion is that as we see more and more businesses embracing Modern then there are less and less reasons to build a web part in any of the traditional ways because you will be developing products for an ever-diminishing customer base. It might be a different story if Modern supported Classic web parts but it doesn’t and I can’t see that changing. Microsoft want us in Modern and they are not going to invest money in giving you a reason not to transition.

Ok, so you might be a business, or have customers, that will be stuck on Classic for years and please read my All Mode Cons article if you are interested in some reasons as to why this might be, but moving forward, it only really makes sense to develop future web parts using the SPFx, wherever possible.

Is the SPFx the right tool for the job?

However, before you race ahead there is an important caveat here, and that is whether the SPFx can actually be used to deliver the functionality you are after and whether it is the right tool for the job at hand. A few key considerations here are:

• We are limited to what can be done within the constraints imposed by the JavaScript SharePoint Object Model (JSOM) and/or the REST API (and/or legacy Web Services I guess).
• We can only run code under the context of the current user and so the access control restrictions of that user must be considered. In the full server object model world, you could run code under elevated permissions and in a Provider Hosted App you could run code under the permissions granted to the app, but not so here.
• The SPFx is focused on providing extensions to the Modern UX and whilst you might be able to do other (non-UI) related work, such as provisioning lists and the like, that doesn’t mean that you should. Generally, these tasks would be better done by some other approach in my opinion, but I guess if your web part needs a list in which to store data then it might make sense to have some auto-provisioning code in there – so long as you can code around the restriction that you can’t rely on the user having the permissions necessary to do such things.
• Currently, SPFx solutions are not supported in the App Store and so you can’t get Microsoft to promote it through the market-place in the way you can with Cloud App Model solutions.
• We have no way of leveraging the Microsoft licensing framework which means, either:
  • All your work either has to be given away for free
  • You have to trust that purchasers of your solution won’t make it publicly downloadable – good luck with that one
  • You have to invent your own licensing framework, yikes – not a 5-minute proposition
• Currently, the only way to deploy an SPFx solution is to get an admin to upload the solution package file to the App Catalog and this has to be done manually. This means that standard users can’t simply request and install the solution as might be the case with an app from the App Store.
• We are also reliant on the solution installer (the administrator) to do some post-deployment work here, like set the appropriate values for the Description, Short Description and Icon URL as described in my previous article. The problem is that the solution will work just fine without completing these post-deployment steps and so there is a very real likelihood that these tasks will never get done and so leave your solution looking less elegant that you may have intended!
• There is no (native) event model. With a Provider Hosted App, we can trap the On-App-Installed event and the On-App-Uninstalling event and this gave us the prefect opportunity to do some initial configuration tasks or tidy up after ourselves respectively. We don’t have these options with the SPFx.

Conclusions and Recommendations

In summary:

• SharePoint Classic mode is deprecated all but in name and Modern is where Microsoft are investing for the future.
• Until the relatively recent release of the new Modern templates you could get away with ignoring Modern as it was an ugly affair with its bi-polar UI tendencies that just caused confusion for users of a perfectly serviceable site built for a pre-mobile, Classic world.
• But users have seen Modern now and they like it and so you can’t afford to ignore it any more.
• Classic web parts, including those developed using the Cloud App Model, won’t work on Modern pages but client web parts developed using the SPFx can be used on Classic pages.
• As more organisations transition to Modern it makes little sense to develop web parts using the traditional approaches because you will be developing for a diminishing customer base.
• The SPFx has some limitations and its really a mechanism for extending and customising the Modern UX, so its not the answer to everything and there is still most definitely a place for the Cloud App Model and even for full trust farm solutions for those customers who remain on-prem or in hybrid mode.
• If you are a seasoned veteran of traditional software development and love all the goodness of object-orientated development based on 20 years of best practice then, like me, you are going to be a somewhat reluctant traveller. But toughen up princess because this is currently the only road ahead that doesn’t lead to a dead end.

That then is the reason as to why I have decided to embrace the faith and why I am writing these Chronicles of Narnia. Come on this journey with me and together we’ll discover what is on the other side of the wardrobe.

In the next article I am going to talk about web part properties and how that all works in the SPFx.