Site Templates vs Site Definition vs Web Templates vs Remote Provisioning

Site Definitions	Site Templates
Files are on disk, better performance.	Files are in database, less efficient.
Highly customizable and extensible (XML  and .NET code is much more flexible than UI)	Not easily extensible  (You are limited by what UI offers)
Can provision multiple webs *	Can only provision one web
Complex to create	Easier to create
Requires admin access to server for deploying.	Installable from a Web UI by site owners.
Modifying the site definition after provisioning at least one site from it is not supported and might break existing sites.	Custom templates can be modified without affecting existing sites that have been created from the templates(**).

Site templates are the one’s which are created by using the “Save site as template” functionality from the site settings.Saving sites as template is not supported for publishing sites.Site templates are only available in the Site scope, meaning that you can’t directly create new site collections based on site template

Web templates is technique based on WebTemplate feature framework element, which was introduced in SharePoint 2010. Technique provides us a way to use alternative onet.xml during provisioning time of the sites without any dependencies on that onet.xml file when provisioning has been completed.
We need to create two files for each of the web templates. Other one is empty element (is VS2010 is used) for defining the actual WebTemplate element and other one is completely similar onet.xml file as for site definitions. WebTemplate element is supported in two scopes, which are Farm and Site
One big advantage of the web templates is the fact that since they are feature based and there won’t be any files stored in file system, those are completely supported usually by the cloud services, like MS Online (BPOS). One really important advantage with the web templates compared to the site templates is the fact that we can utilize the publishing features in web templates.

Site definitions are the classic xml files, which are for example used to provision out of the box sites. Many of the developers learned to create these in 2007 version, since they are very powerful and there were almost no other options available for introducing new options for the Create site functionality. As mentioned earlier site definition consists basically from two different files: WebTemp*.xml and onet.xml files.WebTemp*.xml defines how the site definition is visible for the end users and the onet.xml file contains the definitions for the actual site provisioning.One of the key downside is also the fact that site definitions will require full trust or farm solutions, which means that they are only supported in on-premises deployment 

Remote provisioning is model where we actually do the template system outside of the SharePoint by using the new SharePoint app patterns. In this case we would be using provider hosted pattern to provide customizable sub site creation experience for the end users of the SharePoint.This model is suitable for both on-premises and Office365, which is clearly beneficial from long term maintenance and operation perspective

Custom Site Provisioning Provider to the Rescue!!!!

A site provisioning provider is a piece of code that is run by a site definition when a new site is created. By default SharePoint performs the provisioning actions of a new site. These actions can include creation of lists, activation of features etc. and, most importantly, telling the site which site definition it should be based off. This is important because by declaring the site definition to base the site off you inevitably bind the site to that site definition.

Now that you understand what a site provisioning provider does its time to explain how we can use this concept to our advantage. Generally we would like to use a site template to do most things – they are simple to create and just as easy to deploy. Site templates also provide us with a way to easily deploy a new custom site to a completely different SharePoint installation, provided they are based on an out-of-the-box site definition.

With the above facts in mind, by creating a site definition declaration with a custom provisioning provider, we can tell the SharePoint very specifically how to create the site. This includes which site definition we should base the site off. It is very important to note that there is actually a separation between the declaration of a site definition and the onet.xml which declares all the parts of the site definition. The reason this is so important is that by use of the site provisioning provider we can intercept the call to use the onet.xml. Its through this interception that we can then request the site provisioning provider to instead use a different site definition/onet.xml – specifically an out-of-the-box site definition/onet.xml. This means that we are, in a very round-a-bout way creating something very similar to a site template but from code. Recall I said I liked to think of a site template as an XML script, well now instead of having an XML script to build the site we can create code to build the site.

After the above paragraph you’re probably sitting there confused with the question “but if my site definition is being called how is it that I end up with a site set up like a template?” and that is a fair question. As I described above, its important to realise that there is a difference between your declaration of the site definition and the actual files that describe your site definition. By using the site provisioning provider we no longer need the file (onet.xml) that describes your site definition as we instead use the one provided by one of the out-of-the-box site definitions. Its similar to using a map to find your way to a place but along your journey there are road works and signs for a detour. Even though the map tells you to go one way, you end up following the detour signs. The site provisioning provider is the detour sign.

By basing the new site off an out-of-the-box site definition as opposed to a custom site definition we have effectively decoupled ourselves as a dependency for any future site templates that may be based off us. Additionally we can add to the code and we won’t break any sites that have already been created from using the site provisioning provider. As you can see, in effect, we’ve turned the standard site definition into a sort of site definition/site template hybrid. It uses the same concept of a site template but built within the framework of a site definition.