SharePoint has come a long way in the last ten years, with three major releases and an entirely new product line in the form of the cloud-based Office 365. The graphic design and user interface has been overhauled several times, and many new features have been added along the way. Yet, prior to SharePoint 2013, it was still quite easy to break down the key building blocks (as far as users where concerned anyway) of an implementation, as follows:

  • Sites: A site is a large ‘container’ of content. A site has its own users and permissions settings, and is often used to differentiate departments or business units in a web or Intranet system.
  • Lists and libraries: Each site can contain as many list and libraries as required. A list is basically a set of items, each with a predefined set of properties. Libraries are similar, but come with the ability to store documents as well as metadata.
  • Web Parts: A ‘web part’ is most easily thought of as a widget of functionality, which can be placed on a web page. Examples include blocks of rich text, media content, and specific views of lists and libraries.

Thinking of SharePoint in terms of these three elements helps organizations design and implement their SharePoint systems. They are simple enough to be easily understood, but at the same time, they offer a wealth of power to those prepared to invest a bit more time to dig deeper.


Most types of SharePoint content can be stored and managed in lists. There are a number of different types of lists - such as document libraries, image galleries, and generic lists with custom properties. SharePoint itself uses lists to store its own files and assets - things like page layouts, master pages, styling and ‘web parts.’


With the advent of SharePoint 2013, Microsoft changed the game by introducing a new concept called ‘Apps’. Apps are standalone entities that run outside of normal SharePoint functionality. They can be hosted in a number of different ways, and can even be written in a range of programming languages. The new App model has been a bold step forward by Microsoft, and it has generally been embraced by developers.  But it has had a few ramifications for end users that worth noting. Understanding the differences between lists and apps will help you decide which one is right for you.

Creating a List or an App?

Before SharePoint 2013 users could use the ‘Create’ button to select a new type of List. In SharePoint 2013, the terminology has changed slightly, as users are now invited to ‘Add an App’ instead. Lists and libraries are now referred to as ‘Apps’.

The perfectly logical reason behind this change is that apps are actually much more than just lists. An app can consist of pages, ‘app parts,’ custom styling and of lists themselves. As such, Microsoft has brought lists into line, referring to them as apps throughout SharePoint. It might be a change for experienced SharePoint users, but something that makes sense in the long run.

App Parts and Web Parts

Not only have lists become apps, but ‘web parts’ have been joined by something new called ‘app parts.’

‘Web parts’ have always been a flexible concept in SharePoint. In SharePoint 2007, ‘web parts’ could only be added to designated zones on a page. Since SharePoint 2010, users can place them anywhere in content, via the wiki page template.

Now, SharePoint 2013 added the ‘app part.’ So how does an ‘app part’ differ from a ‘web part?’  A ‘web part’ simply refers to a piece of server-side code, meaning a specific DLL file needs to be present on the SharePoint farm.  On the other hand, a core idea behind SharePoint Apps is that an app can be hosted outside of SharePoint itself. An ‘app part’ renders a piece of HTML, the source of which can be a SharePoint server or a totally different location somewhere on the Internet.

In essence, a ‘web part’ is tightly coupled to the SharePoint farm, runs under SharePoint itself, and needs to be installed on the server using a farm or sandboxed solution. A poorly designed ‘web part’ can decrease the performance of the system and can even result in a buggy site or page. An ‘app part’ on the other hand, is simply a link to some piece of functionality, located outside of SharePoint.  It doesn’t affect core SharePoint functionality, and is securely isolated in the case of a problem.

The bottom line is that ‘app parts’ are very much the future of SharePoint, just like apps are the future of lists.

A Rose by Another Other Name…

The terminology currently used in SharePoint 2013 can be a little confusing for some. Elements are referred to as apps, where veteran SharePoint users know them as lists. ‘Web parts’ and ‘app parts’ also appear, at first glance, to be roughly similar. But as we have seen, ‘app parts’ offer a number of substantially different, and important, improvements.

Microsoft has taken a good step forward with apps and ‘app parts’ in SharePoint 2013. They are part of the sweeping changes Microsoft has made to how SharePoint applications and functionality are developed; these changes have helped Office 365 and SharePoint thrive in the new cloud reality. We look forward to seeing further improvements in this area, giving more power to help developers build secure stable innovative tools for end users.

New Support for Lists

Don’t forget to check out’s new support for lists, including calendar, tasks, issues, contacts, links and announcements. Now you can follow SharePoint/Office 365 lists in the same screen where you access and edit documents, and reach out to colleagues in real-time. Get the whole scoop here.

Ram Tagher
Product Manager