I’ve been thinking again, and even read a bit, which is unusual for me, because I don’t read much. This time, I’ve read Doug Ware’s blog post on. In this article, Doug, a renowned developer and now seemingly proponent of the App model, ends up concluding that for certain definitions of ‘better’, Apps in SP2013 are indeed ‘better’.
To me, the issue is not whether one model is better than the other, but rather what problem a new model solves. In the case of the App model, I have yet to see anyone come up with real problems that aren’t readily solvable using other methods. I don’t actually see why I need an App solution at all; it’s a solution to problems that don’t exist.
Let me briefly respond to Doug’s points.
Modern Web Development Techniques
He is correct in one thing, in that a Farm solution has no downside compared to Apps. Farm solutions has always been able to output pretty much whatever you want, including but not limited to what’s currently defined as ‘modern’. In fact, I’ve shown this by pulling a completely HTML+JS+CSS based web page for an invoice and with a couple of hours of jQuery work, made that page work directly with SharePoint data for SPInvoice, shown below.
Granted, it’s not HTML5, but that’s just because I couldn’t find one readily available.
This is a farm solution, and it works in SP2007 (or should, I didn’t actually test). No need for a new model to build ‘modern’ anything.
In simpler terms, there’s nothing that the App model gives you that you cannot already do in SharePoint, within the topic of ‘modern’ UI development.
Doug favors Apps when it comes to scalability. His argument is that code running in Farm solutions must run on the farm and thus taking away performance from the farm. Increase the load and your farm will eventually suffer. This, Doug claims, is solved in Apps.
The truth is that this is again a non-problem and Apps solve this no different than you can solve it in Farm solutions.
There are two scenarios to keep in mind here. First is when you are working with SharePoint data and the second is when connecting to external data.
When you access SharePoint data, it doesn’t really matter too much whether you access that data using an App or a Farm solution. The performance impact does not come from the rendering of the data on the page but rather from accessing the data. That access needs to happen regardless of whether your client is an App or a Farm solution. Apps scale no better than other access methods, they query the same data, hit the same SQL servers, loads it over the same network, and SharePoint needs to work just as much to retrieve that data.
One key argument for the App model is that it’s easier and more scalable to offload performance intensive work to external services. If you have data stored in web services on another farm, a public web service, or a ‘potato-powered’ web server running on GEOS, according to the arguments, Apps are better because they allow you to integrate that data into SharePoint pages.
Again, this is simply not true, at least the ‘better’ part. SharePoint has long been able to integrate external data in Farm solutions, both on the server side, but of course also on the client side.
On the server side, you have decades (at least one and a bit) of experience in .NET development to aid you in integrating external data, whether that is access to SQL servers, SAP, Exchange, or any other external service. This puts load on the server, but if that’s of concern to you and you’re not willing or able to solve that on the server side, you can always fall back to exactly what the App model is doing; running it on the client side.
So, Apps solve no problem that you can’t already solve with Farm solutions in the exact same way. What Apps cannot do, however, is centralize caching, load balancing, performance management, and all the other benefits you get from server-side code. Loss again for the App model in terms of options for scalability.
Doug’s final argument in favor of Apps comes from its maintainability over Farm solutions. I’ll quote Doug’s argument verbatim as of today:
The downside to farm solutions is that they use a very powerful but comparatively rigid combination of file systems and a SQL databases in conjunction with lots of XML files. In order to use a solution, it must be installed on a farm and put files directly on each server. The XML files are features, site templates, list templates, and a wide variety of other artifacts. This system works really well unless the same solution is installed on multiple farms and used by many site collections and needs to change to accommodate new features or bug fixes. Furthermore, some things, like site and list templates, are very dangerous to change once sites and lists exist that use the templates.
These issues with farm solutions, in short the ability to maintain bug fixes, changes to solutions, site and list templates, and so on, have been solved years ago, and is simply a result of lack of maturity in SharePoint understanding. Although others have come up with similar solutions, I explained a method or framework for building maintainable and agile solutions in SharePoint in 2009, in Professional SharePoint Development and have since used that method for virtually every solution I’ve built.
The argument is thus void and a bit of a straw man argument against farm solutions.
Doug further goes on and argues that
The app model makes it possible to centralize and serve content to as many farms as is necessary and if you use CSOM to provision everything instead of XML you remove the coupling between concrete instances of sites and lists and their definitions. CSOM allows the creation of fields, content types, lists, web part pages, and other types of files. In my app everything, with the exception of one page, is provisioned by the application server running on Azure. The app server is capable of updating these items and of adding new items. It makes no difference how many farms use the app from an update perspective, each can be patched centrally whenever a user launches the app.
This isn’t true for two reasons. First, the App model does not make this possible; the client side object model (CSOM) does. CSOM is available to Farm solutions as well, both as traditional Farm solutions, as Sandbox solutions, and again through client side code, if you so desire. You don’t even need to run this from the server, you can again output the CSOM code from a PHP page, a text file loaded from a mobile App, or from any other source you like. Completely possible from 2010 onwards, which marked the introduction of CSOM.
The second reason why Doug’s argument is false is that when you are creating artifacts, changing the definition of those artifacts after the fact won’t change the artifacts. Put in a simpler analogy, if you change a recipe for a dish you cooked, the dishes you’ve already cooked based on the previous recipe won’t change. You can ‘patch’ the recipe by, for example, creating a second recipe to add sprinkles on your cinnamon rolls, and you can even change the innards of those cinnamon rolls by specifying that you should inject some vanilla custard into them, but you can’t ‘uncook’ and ‘recook’ an existing dish by changing the recipe.
The same applies to SharePoint, especially when it comes to templates, but even if you have scripts or code that creates artifacts. For templates, you avoid this by having ‘no content’ templates (or as I like to call them, the perfect templates) and create the content using code.
Sorry for ruining the arguments for everyone, but again, the App model fails to add anything that cannot already be done, and be done quicker, easier, and with more options, with Farm solutions.
What About the Marketplace?
Ah, I knew that was coming. Apps, of course, are the only solutions available through Microsoft’s App marketplace. Unless you build Apps, you can’t really get access to the gazillions of SharePoint installations out there. Must be a great opportunity, right?
This is true, the ‘opportunity’ part only to the extent that you believe that somewhere in the future, organizations will jump at the chance to buy critical business applications through a dollar store.
However, again, the App model doesn’t solve this problem. It’s perfectly feasible and possible to build App stores for SharePoint prior to SharePoint 2013 too. Below is my SP SIN store running on SharePoint 2007.
In fact, the App store isn’t even related to Apps per se; it’s simply an interface to distribute Apps and has nothing to do with the App model as a development platform. It is, despite all it’s glory, nothing but a marketing tool to get people to jump on Apps as a development model. You can run Apps perfectly well without the marketplace; they are completely technologically unrelated.
Do I Hate Apps?
Before you start your flame wars about how I must hate Apps and must be stuck in the stone ages, I don’t hate apps at all. However, I have yet to see real arguments for
- What real problems do Apps solve that you cannot solve already using other models?
- What are the technical benefits to using Apps compared to existing models?
In other words, I just don’t see the point of Apps. I fully understand them in terms of Office, I can understand them as extensions of closed frameworks (think Facebook, Hootsuite, Yammer, etc) where you don’t really have the option of building server-side code. I don’t see the scalability issues because these are easily solved in current models too and nothing done in Apps cannot be done already.
So, there you have it. My jury is still out, and they’ve been trying to find evidence that the App model is a useful tool.
They haven’t decided against it yet, though.
Found this article valuable? Want to show your appreciation? Here are some options:
a) Click on the banners anywhere on the site to visit my blog's sponsors. They are all hand-picked and are selected based on providing great products and services to the SharePoint community.
b) Donate Bitcoins! I love Bitcoins, and you can donate if you'd like by clicking the button below.
c) Spread the word! Below, you should find links to sharing this article on your favorite social media sites. I'm an attention junkie, so sharing is caring in my book!