When to Use SharePoint Apps
To understand which approach to take when developing SharePoint apps, we need to understand the alternatives and what advantaged and disadvantages are involved with each.
SharePoint apps/add-ins were introduced in order to increase the security and stability of the farm on which they were running. As opposed to farm solutions, app code is run as a separate process and on a separate domain from the rest of the farm, meaning poor code cannot lead to the entire environment crashing, and apps cannot make changes to the farm without explicit consent from users that have the rights to make those changes already.
An alternative to farm solutions, introduced in 2010, are Sandboxed Solutions. However, Sandboxed Solutions that contain custom server-side code are deprecated, and will no longer be allowed in SharePoint Online. Simple Sandboxed Solutions that provision SharePoint artifacts, such as lists, libraries, and content types, on the site where they are installed can still be used. Note that, for SharePoint Online, the community is now recommending remote provisioning of these artifacts using the Office 365 APIs.
Despite the advantages that SharePoint Apps bring in terms of security, stability, and upgradeability, they are a relatively heavyweight approach. Integrating an app into its host web is a challenge, especially if responsive design is called for. Therefore, in situations where only one instance of the Sharepoint customization is going to be needed, consider creating the lists, libraries, etc. through SharePoint’s user interface and load JavaScript on the pages where it is needed through a Content Editor Web Part. This approach has traditionally been a “hack”, but has been legitimized by the pending rollout of the SharePoint Framework.