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

SharePoint: platform, services API, or both?

Recent, SharePoint MVP Andrew Connell posed an argument to regard SharePoint from now on as a services API: Developers: SharePoint isn’t a Platform, SharePoint is a Service. His suggestion received multiple comments, mostly affirmative, some a bit cautious. A week later, Doug Ware published on his blog a reaction in which he warns against not utilizing SharePoint as a platform: Architects: SharePoint is a platform, treating it as only a service is a mistake.

My opinion in this verbal 'battle' with seemingly opposite perspectives is that both raise valid points. This is my addition to the discussion / position-taking (also posted as comment on Doug's post):

My view in these opposite perspectives is somewhere in the middle. In the past, the SharePoint community regarded and applied SharePoint as a 1) functional, 2) development and 3) deployment platform. The first still holds, for me it is ridiculous to eg not utilize the OOTB DMS features if you have SharePoint at hand in your company. The latter 2 however have changed: we can still use SharePoint to “build upon”, but we must not do that anymore by deploying to SharePoint infra. So for development, less to even no more regard / utilize SharePoint as platform in favor of services model; and as deployment model the SharePoint farm is in future-proof sense an absolute no-go. Note that also on functional level, Microsoft can unpleasant surprise with functions before strongely advocated, have disappeared in the next version. This is ao the result of the long design and development timespans for SharePoint as product itself. The bare essence of SharePoint 2010 was designed even before the year 2007, 2013 before 2010? In the IT world that is an eternity, the world is completely different. That is one of the charmes and benefits of online products, it enables SaaS providers (Salesforce.com, Microsoft, SAP, …) to respond in much shorter timeframe to new IT possibilities and changed market requests.