Architecture decision: SharePoint-hosted AddIn or 'plain-old Html/JavaScript/CSS'

When does SharePoint-hosted AddIn has value above 'plain-old Html/JavaScript/CSS'?

As we developers like to jump in on anything new, design decision to deliver new functionality as a SharePoint AddIn is nowadays almost the default. I object against that. I consider the AddIn paradigm an useful addition to deploy functionality on SharePoint, but it is not the silver bullet. Beyond the advantages that the AddIn paradigm brings, using it also has its drawbacks:

• Building functionality as AddIn results in extra build effort; code and testing for the AddIn installation, AddIn lifecycle management;
• Deployment is more complex: add to SharePoint AppCatalog, and next add to site collection;
• AddIn based deployment requires the presence of a SharePoint AppCatalog in the webapplication;
• Reusing the AddIn functionality on multiple locations in the site structure, results in multiple AddIn instances that each operate in isolation. While this can be desired, it also means that an AddIn update must be repeated on multiple instances in the site structure; and may result in inconsistent behavior when not all AddIn instances are upgraded;
• Cleanup of AddIn is more complex, and largely happens under the SharePoint covers and outside the control and visibility of site owner. I’ve seen examples of so-called Orphaned Apps (the initial name) that can only with difficulty be removed from the SharePoint content database.

For the above drawbacks, I as solution architect do not allow the decision for whether or not to build as SharePoint AddIn to be made on personal preferences of the individual developer. I apply the design principle “keep the development + deployment model as simple as feasible”. And in many cases, ‘modern Apps’ hosted in SharePoint can just as well be delivered via the ‘content-approach’: plain html5, javascript and css files, and upload these files as content to a SharePoint document library. Note that this approach also works for SharePoint 2010 (and even 2007, but I assume/hope there are very few left that actually still build new functionalities on a 2007 basis).

Of course there are cases in which the AddIn concept truly adds value. I identify the following:

1. When the functionality must be customizable; either by content editor ico shared page, or end-user ico personalized page. For such you need AppPart properties, to customize the (individual) App Instance
2. When the functionality will be deployed multiple times in different locations (sites, web applications), and with the flexibility to let if behave differently in different locations
3. When you want to enable site owners, or even end-users via personalization, self to add and remove the functionality to a page (via the AppCatalog)
4. For suppliers to package as direct installable ‘deployment unit’; either via Microsoft Store, or via local AppCatalog