SharePoint 2013 Preview – Apps or Crapps?

The SharePoint 2013 beta came out less than 60 hours ago and in less than 24 hours I saw this tweet on twitter.

It’s an easy joke to make and one that I’ll probably make myself during difficult debugging sessions. Still the hype machine is in full swing around this new mode of development. A good example is this article from CMS Wire: SharePoint 2013: 5 Reasons Why the New App Model Will Make Everyone Happy.

Microsoft wants you to Build Apps

But they have a credibility problem!

Consider this bit of advice from this MSDN article: Apps for SharePoint compared with SharePoint solutions.

(Develop an app whenever you can)

This is pretty unambiguous; the new App model should be my default choice. But, it reminds me of something from the past.



So the advice from 2010 was that everyone should build sandbox solutions as the default. The new version must really take sandbox solutions to the next level, right?

Yep, last versions new hotness is this version’s old and busted, and everyone is still building farm solutions.

Why the Sandbox Architecture was Bad

The sandbox architecture was fundamentally flawed. I discovered this during the last beta when I spent a few weeks building a non-trivial sandbox solution. I wrote about my feelings in a post title SharePoint 2010 Sandbox Solutions are Bad. It was reposted to End User SharePoint and sadly is still on the first page of search results if you search for ‘SharePoint 2010 sandbox’.

I was really irritated when I wrote that article, but to summarize my two biggest issues were that UI development was very difficult due to the sandbox restrictions and that the sandbox model lacked an answer for high-trust scenarios.

In short, the tools were insufficient for building business applications on SharePoint.

What about Apps?

So the question on everyone’s mind is: are they Apps or Crapps? Let’s start with the case that they are not Crapps.

They are Apps

The first question is: can you build a good UI? Sandbox made this difficult because it blocked access to the Microsoft.SharePoint.WebControls namespace. It was server side code without access to any of the server side controls. Apps also lack access to this namespace because they prohibit all custom SharePoint server-side code. However, as you saw in my previous post there are now mechanisms for rendering just about everything with JavaScript templates. The completeness of the CSOM API’s and the robustness of the templates and documentation will be the keys to general acceptance of this mode of UI development. There seem to be some obvious omissions at the moment, in particular with regards to the ribbon, but keep in mind that this is a preview and we are a long way from release.

The second question is: can you effectively perform high-trust operations (things the current user isn’t allowed to do) with apps? If you build a provider hosted or auto hosted app you can write code to respond to remote events from SharePoint based on whatever permission set you require assuming the installer of the app agrees. Even better, the server that handles the events and performs the high trust operations can be written in any language assuming it can use some form of the client side object model (CSOM). There are even people out there using CSOM with node.js.

The App architecture is beautiful in my opinion especially for solutions that will be widely installed. Imagine having hundreds of installed versions of a sandbox solution that you need to update. You’d have to update hundreds of sites. With important code on a shared app server you simply don’t have this problem. Even for point solutions the fact that the UI code now goes in the actual UI via HTML, CSS, and JavaScript instead of through ASP.NET web forms (which are really showing their age) makes apps very attractive.

They are Crapps

People Like Farm Solutions!

Say what you will about the server side API’s, they are quirky, ornery, and often frustrating to use. You can build powerful farm solutions and they are the standard approach for most SharePoint developers. If Microsoft wants people to move to CSOM they must make it worthwhile and as painless as possible. This means that when a developer decides to port some existing code to CSOM she shouldn’t hit walls because a given commonly used property or method is inexplicably missing from CSOM.

For example, as of today you can’t persist changes to property bags or hide fields via the ShowIn*Form properties; CSOM lacks functions for these. Once again this is a preview release we are talking about and they have time to fill these little holes in the API. But if they don’t I expect they will have a hard time convincing developers to change models.

I also don’t think they can get away with a repeat of the sandbox situation and retain any credibility. As our former president said, "fool me once, shame on — shame on you. Fool me — you can’t get fooled again."

This same need for completeness extends to the UI itself. I think it is telling that at the moment the SharePoint hosted sample apps they have in the marketplace are all based on Access Services. They do not have a sample that displays and uses standard collaboration site elements tied together to solve a business problem. Access Services is pretty cool, but if my app has a calendar or contacts list I want it to integrate with Outlook and be standard SharePoint goodness, not some half-assed custom thing I built in Access. I want my application’s web to be a normal SharePoint web with my specific customizations.

Speaking of app webs…

App Webs are Stupid

When you have a SharePoint hosted or hybrid app you get an ‘app web’. An app web lives outside the host web in a special isolated web application and site collection. The idea is that the app web isolates the app for purposes of permissions and management. If the user decides they don’t want an app they can uninstall it without affecting the host web.

This sounds great, but the problem is that a SharePoint site is not a phone!

I don’t believe users will make a distinction between a site that has a document library with their important documents and a normal site created independently of an App as a subweb or freestanding site collection. If you build a specialized app that facilitates the majority of an individual or group’s work the host web becomes this thing the user has to traverse to get where they really want to be. Worse still, if you have many such sites based on an app they will exist outside of your carefully defined IA and site topology under a bunch of funny looking URLs.

Guidelines aren’t Published Yet

It must be said that everything I just said might be wrong because it is possible for an app to do things to a host web. If it has permission to do so it could theoretically pave the host web and replace its contents with the app specific lists and libraries. However, your app must meet guidelines from Microsoft and pass review for inclusion in the new marketplace. My suspicion is that paving the host web, at least in Office 365, is a big no-no.

Alas, that is pure speculation. So until the marketplace guidelines come out you have some risk if you decide to start building an app today.

It doesn’t Matter if they are Apps or Crapps

There is a third fundamental reason I disliked the sandbox architecture. The UI model was very different and features were subtly different. In spite of Microsoft’s promises to the contrary you could not take a non-trivial sandbox solution, deploy it as a farm solution, and expect it to work. You had to think differently and design differently.

I don’t think the same is true for most apps. This is counter intuitive so let me explain…

A typical SharePoint solution consists of:

  • Features for provisioning
  • UI
  • Event handlers (feature, web, list, item)

From a logical design standpoint a provider hosted or auto hosted app is exactly the same thing. The physical difference is that the code runs in a different place using a set of API’s with a different syntax or even a different language.

Unlike the sandbox, it is possible to write identical code in the UI of a page (or client rendering template) for a farm solution as for an app. However, it is up to you to do so because you can also do the farm code the old way, in which case it won’t transfer.

And so, my point is that you should be approaching your UI the same way regardless of the mode of development. This means you can begin to move toward apps without ditching farm solutions.

Finally, it is worth pointing out that in on premises deployments you can mix and match solution types and build hybrid farm/app solutions and even hybrid farm/sandbox/app solutions if you want. I haven’t tried it, but it seems like it should be perfectly possible for a web service that responds to remote app events to be hosted in SharePoint and deployed as a farm solution, but that is super speculative as the devil is in the details.

The Devil is in the Details Indeed

So, I guess what I am saying is that it is too soon to tell if they are Apps or Crapps, but they have the potential of being awesome if Microsoft provides a complete API that makes it possible for people to meet their requirements. If they don’t I am certain that people will happily keep writing farm solutions and only those motivated by the (also as yet unproven) marketplace will build Apps.

That would be a shame.


Author: Doug Ware