Way back in 2006 I wrote a blog post entitled “Application Development on MOSS 2007 & WSS V3” that discussed the various options for building apps on SharePoint. It’s been by far and away the most viewed blog post I have written. As of writing its sitting at 140,000 views.  

The main point on writing that post 6.5 years ago was to provide a simple summary of the options available for development in SharePoint 2007. At the time those were:

• Web Parts
• _Layouts application
• User Controls
• ASPX pages added to a site with code behind

Towards the end of the post I summarized the choices in a simple decision matrix (below):

Now fast forward to 2013 and the new release of SharePoint 2013 … Most of that matrix still holds true albeit with a couple of minor tweaks. Back when I wrote the original post there was no support for SharePoint built into Visual Studio for example.  Today instead of the Smart Part (thx again Jan Tielens) you can use a Visual WebPart (which is a user control that is compiled down to a server control by Visual Studio, but which gives you the benefits of the visual design surface at design time, unlike a standard WebPart).

Given so long has passed I thought it was about time that I revisited the choices and took a look at what has changed in the last 6.5 years!

Before I go on, I want to reiterate that this is my personal opinion. Many of you won’t agree.  So this is really just a summary of the decision matrix I use in my head when evaluating the options and deciding on the best choice for the situation.

Evolution of the matrix…

Updating this matrix is a lot trickier now we have SharePoint Online where many of the pervious on-prem options don’t exist. e.g. no full trust code.

I went back and forth on deciding what my updated matrix would include. This took a while and, given I am a big proponent of SharePoint Online, I would prefer everyone think about designing their solutions with the possibility of moving to SharePoint Online in future.

Why?  Well in a recent internal email amongst developers here is what I said (some bit snipped):

Apps should be our first choice moving forward.

The reason is simple.  There is no future in Sandbox Solutions or Full trust solutions.

Notice i said “first” .. not only 🙂 When will Sandbox Solutions go away? Shortly after the new app model supports everything you can do in a sandbox solution. MS will deprecate it as fast as they can and then turn it off after giving  everyone a year to re-write their code.

Trust me, MS wants to kill sandbox solutions as fast as they can.  Same with full trust code. It gives SharePoint a bad name when SharePoint fails … even because of code someone else wrote and deployed to it.  The sandbox is too expensive to run in Office 365 and therefore will be shot. To be clear, the goal is to remove any 3rd party code running within a SharePoint process. Doing so will improve the security, scalability and reliability of SharePoint.

Now that might sound a bit harsh … and to be fair I was trying to be … but my point is the long term vision for SharePoint is to not host other peoples code.  The new app model might not be a perfect replacement today … but given time I’m willing to bet it will get better and support more of the things you can’t do today.

Then I went on…

For now we should be thinking Apps first … and augmenting it with sandbox and full trust only when needed.  Otherwise we are painting ourselves in a corner. This is most important for 365 solutions.  Still, 2 years from now we shouldn’t be having to explain ourselves to our customers for painting them into a corner where they can’t migrate to 365 or upgrade to the latest version of SharePoint because of our recommendations. Not good.

Don’t get me wrong.  I’m not saying “no sandbox” and “no full trust” … i’m just saying we should be leading with apps first and then backing in sandbox and full trust only when needed.

I like apps because they also mean we are not constrained to what development options SharePoint imposes like MVC or the latest improvements in the .Net framework.  Because your code runs remotely you can run it on anything you like. It could be PHP for example.

<mega tangent> PS: can we start a petition to stop calling the new model the “app  model” and call it something like the “remote code model” that “apps” happen to use. Then we can reserve “apps” for stuff that gets put in the Marketplace. I know this won’t happen but it would be nice 🙂 “Apps” was a bad idea IMHO.</mega tangent>

Back to the matrix…

After going back and forth on it for a while I came to the stark realization that a matrix was no longer required.  Dev has got simpler for a change!

So here is my new “matrix” … or the “Decision List 2013 edition” as I am now calling it:

1. Design Manager package (on-prem or online)
2. App for SharePoint (on-prem or online)
3. Sandbox Web Part (on-prem or online)
4. Full Trust Web Part (on-prem only)
5. Full Trust everything else (on-prem only) (_layouts pages etc…)

It’s pretty straightforward when you think about it.  Start with the lightest touch possible and only step down to the next heaviest when you have to.  This might seem screamingly obvious, but it would surprise you (or not) how many developers jump for the most heavy weight option first because it’s the most powerful and they don’t have to think.

Further more option #2  above can be further expanded to:

1. SharePoint Hosted App
2. Provider Hosted App

You may notice the absence of the Auto Hosted app type above. This is the option where you package your application and SharePoint will automatically host the application code for you in Azure. Reasons for this are simple A) its not available (yet)  B) it’s horrid (my opinion).  Auto Hosted apps code runs in Azure space managed and controlled by SharePoint Online … not you.  I hate the thought of having to support code running in a location I have no control over and no visibility.  For example, unable to see what is going wrong when a customer calls asking for support.  For the small price you pay hosting in Azure directly via the Provider Hosted model you will reap payback many times over when you need to upgrade your app and or diagnose a support issue and can’t tell what is going on.

Summary…

Regardless of your like or dislike of the new app model there is one thing that is clear … at least to me anyway. That your code will not live inside the SharePoint process in the future. For me, that means thinking about how to start designing solutions with this in mind as to not inadvertently painting yourself into a corner that is costly and painful to get out of.  Sure, there will be situations today that mean you have no other choice to use some sandbox and full trust code.  But …

My words of advice are simple.  Think apps first and fall back to heavier options if needed.

This way over time as the new app model gets better and becomes the starting point for all SharePoint development you will already be ahead of the curve and will have an easier path to the cloud when your customers are ready.

+ ask any developer if they would rather be using MVC, Razor, SignalR etc… my bet is they say “yes”.

-CJ