About two months ago, I was pointed to an article that talked about SharePoint Apps and how some people are starting to call them “Crapps”: SharePoint 2013 Preview – Apps or Crapps? I didn’t want to add my two cents right away because I hadn’t really had a chance to play with the App Model in SharePoint 2013 and I didn’t want to sound sycophantic.
However, now that I’ve been deeply immersed in building a complex on-premise SharePoint 2013 app for the better part of 2 months, I find myself firmly in the “major improvement” camp. In case you haven’t read Doug Ware’s article, I’ll summarize it here briefly:
Doug talks about how, in SharePoint 2010, Sandboxed Solutions were supposed to be so amazing and make everything better and it turned out that Sandboxed Solutions actually had too many limitations to be useful for a lot of work streams and that the same thing could happen with Apps. In addition, he points out that people like creating Farm Solutions, the concept of clean deletion is broken because SharePoint is not a phone, and there are no guidelines for creating apps yet. In the end, he decides that the devil is in the details with how you create the app.
This is About More Than Just Apps
It’s true that whether an app works out or not depends on the details, but now is the point where we can shape those details. More importantly, the inherent power of the app framework bequeathed on it from the much-improved Client-Side Object Model (CSOM) provides nearly all of the capabilities you get from the Server-Side Object Model. This is an important distinction, because in SharePoint 2010 you could do a lot of really cool read-only things with CSOM, but as soon as you wanted to write back to SharePoint, things got a lot more difficult, especially in JavaScript. (I won’t even get into the other issues!)
I think this is the major reason for slow adoption of CSOM. Since we were all building Farm Solutions anyway (because of the limitations of Sandboxed Solutions), there was little incentive to use CSOM from either JavaScript, Silverlight, or managed code when you could use the server-side object model and do things the same way they’ve been done since the beginning of SharePoint. (I know there are CSOM limitations from Sandboxed Solutions too). The only time you’d have to use CSOM is when you absolutely couldn’t deploy a Farm Solution (i.e. SharePoint Online and Office 365) and had to cross a site collection boundary. Couple that with the fact that a large number of SharePoint experts cut their teeth on SharePoint 2007 (MOSS) where there was no CSOM and Sandboxed Solutions were doomed from the start.
That doesn’t mean that Apps will be or should be. Improvements to CSOM make it possible to write back to SharePoint just as easily as any other REST service (via POST, PUT, or DELETE HTTP verbs). In addition, the use of OAuth and App-specific permissions means that you’ll never have permissions discrepancies that necessitate a RunWithElevatedPrivileges delegate (and thereby a Farm Solution). All of this can be done with the web standards triad: JavaScript, HTML5, and CSS3. So there’s a lot of power built into the App model.
From a developer standpoint, this is huge because I can basically do everything I was going to do as a Farm Solution (aside from certain SharePoint-specific assets) from an App. As an administrator, I can control what Apps are deployable where, which allows me to control my system better. I can also be sure that Apps aren’t running against SharePoint, preventing some system and security issues. As a user, I can find and deploy apps (with the approval of IT) in a matter of seconds and the App need not know or care about SharePoint a whole lot to work. An App could simply be a window into another system.
When I first started working with SharePoint, it was billed as the hub in a company where collaboration and work would take place. You could surface information into SharePoint through various means (BCS, Search, etc.) and interact with that data without leaving SharePoint. With SharePoint 2013, that’s still the goal of SharePoint, but the addition of Apps improves upon those two different aspects by allowing already existing but previously segregated items to be surfaced from SharePoint as well as providing new avenues that are more lightweight to interact with data in SharePoint.
In essence, the only thing tying us to Farm Solutions over Apps in SharePoint 2013 is our own comfort with Farm Solutions. It’s easy to do something when you have Full Trust and complete access to everything through RunWithElevatedPrivileges. However, that’s a lazy way of doing things. It doesn’t require a lot of thought to generate such a solution and leads to bad programming practices. We as developers can do better and, with SharePoint Apps, we have that opportunity. So I say, call them Apps!
