Developing with SharePoint Script Editor vs. Custom App Parts

Creating custom user experiences and branding components in SharePoint involves using JavaScript and HTML to render content within a SharePoint page layout.  As a simple example, you might want to include a JavaScript based “slider” that loads up list items or pages and displays them on your home page.


The JavaScript file pulls a set of list items from a SharePoint list and using JQuery adds them to a <DIV> element as “slides”.

In order to implement this type of solution, there are a couple options:

1. Use a simple script editor web part and just add your HTML as source code and a link to your JavaScript file and load it directly into your page.

2. Build a custom App Part that contains the JavaScript code, the HTML, and the configuration properties and deploy it your site.

As a team, we have tried both approaches and we have some clients who prefer approach #1 and some that prefer approach #2.  Here is a quick comparison of the pros and cons of each approach.

In general, our current approach is to start with approach #1 and then if we need to do so we’ll mature the code into #2 if the customization is complex, intended for mass re-use, etc.  For something like a slider that is showing up on a single home page for one client, using a simple script editor is much simpler.  However, if we were going to build a complex control that we wanted to deploy to dozens of clients, we would use approach #2.

Using the Script Editor


  • Simple to deploy – just upload your JS file and stick your HTML into the script editor.  You could also have your JS injected right into the script editor.
  • HTML is rendered within the main page, e.g. there are no IFrames involved.
  • Easy to update the JavaScript code using SharePoint Designer
  • JavaScript can be “re-used” if it is externalized on multiple pages.
  • Easier to make responsive than the App Part approach.
  • JavaScript files can be versioned if uploaded to a document library with version control turned on


  • Code isn’t packaged and deployable as a component
  • Code cannot be added to the app store
  • Lack of a configuration layer (e.g. you don’t have properties that your content editor can configure in the app part properties)
  • HTML is not easily re-usable – you need some minimal amount of HTML and a link to the JS file in your script editor.
  • Content author needs to know how to add the HTML, JavaScript, etc.
  • Permissions are based on the context of the user loading the page.  Lacks the permission model used in App Parts.
  • Debugging is done through browser as directly loaded JavaScript
  • Lack of integration with Visual Studio – you can edit the code but no built in deployment/debugging mechanism
  • Lack of support for multiple “views”

Creating an App Part


  • An App Part is a deployable component (code is packaged into a zip file) and can be uploaded to the app store (both the SharePoint app store or your internal tenant/farm app store)
  • App Parts have a configuration layer that allows you to define configuration properties – very useful for specifying things like the list name, fields to map, locations, etc. for pulling data.
  • App Parts are first class projects in Visual Studio
  • Content Authors can add an App Part with zero knowledge of HTML/JavaScript – they just add the component to the page.
  • Visual Studio integration with publishing of your app and debugging
  • Support for multiple pages as views
  • App Parts are versioned as components (e.g. the entire package of files making up the component).


  • App Parts are rendered within IFrames.
  • Deployment is slower – it involves several steps including deploying to the app store, then deploying to the site and then adding to the page.  In our experience, unit testing is significantly slower because the deployment cycle is slower.
  • Making App Parts responsive is much more complicated because they are hosted wtihin a fixed width, fixed height IFrame.
  • No ability to change the code from SharePoint Designer