SharePoint 2013 App Model Solves Non-Problems Only?

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 which model, Apps or Farm solutions, is better. 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

Doug states that between farm solutions and Apps, there is a tie in the case of modern web development techniques, and by this he is referring to HTML5+CSS3+JavaScript, and stuff like that.

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.

However, the App model, in terms of ‘modern’ development is actually more limited, simply because JavaScript lacks maturity in tooling, robustness, and flexibility. It’s a bit like being told to build a house using only your right hand, which, although possible and certainly something you could learn, is still far more limiting than having both hands available, which is what you have with Farm solutions.

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.

SharePoint 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.

I’m guessing that someone will think that when you’re accessing and rendering data using JavaScript, you’re taking a load off the web server and putting that on the client. That may be true, but if this is a real problem, you can solve it using JavaScript output from a Farm solution just as easily as you can using an App. Marc Anderson’s SPServices is a great example of this, and it’s working all the way back to SharePoint 2007.

In fact, with Apps, you have _fewer_ options for rendering data, because you _must_ use JavaScript on the client. A server can much more easily cache data, rendered or not, and has far more options for providing scale than Apps have. With an App, you essentially turn the responsibility of caching or optimizing over to the clients, over which you have no centralized control.

External 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.

Keep in mind that Apps do nothing beyond what is already possible in the browser, and you can do exactly the same things by outputting the same or similar JavaScript and HTML code from a Farm solution, in a page. You can put your ‘App parts’ anywhere, including on the potato-powered CBM64 wannabe, and still include it on any page using the same iframe and JavaScript tricks that an App would do. You can use jQuery and SPServices to bridge multiple SharePoint farms; you can use VBScript for crying out loud, if you really want to shoot your foot off.

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.

However, even if you write code to create for example lists and content types, changing the code will not change the lists and content types. You still need to create new code to modify those lists and content types. This applies equally to JavaScript with CSOM, Farm code with server-side code, Apps calling CSOM, or anything other combination that creates artifacts in SharePoint.

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

  1. What real problems do Apps solve that you cannot solve already using other models?
  2. 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!

Pin It

Published by

Bjørn Furuknap

I previously did SharePoint. These days, I try new things to see where I can find the passion. If you have great ideas, cool projects, or is in general an awesome person, get in touch and we might find out together.

32 thoughts on “SharePoint 2013 App Model Solves Non-Problems Only?”

  1. One advantage of apps I can see is that they are the only thing (other than sandbox solutions) which can be used in solutions for SharePoint Online.

    I think apps fill a business gap more than a technical gap. Apps are the better choice (again, other than sandbox solutions) for many SMEs which cannot afford to host their own SharePoint Installations and opt for Office 365/SharePoint Online.

    Allowing farm solutions on a multi tenant environemnt like Office 365 is simply not possible for Microsoft and I think apps have been introduced to fill that gap.

    1. I see your points, but keep in mind, this is a hosting problem that is realated to a hosting platform provided by someone, and not related to SharePoint nor to the business. From that perspective, it is a solution to get people to buy a specific hosting platform. FPWeb, RackSpace, and others have long provided hosting platforms capable of running custom farm solutions; in fact, they’ve built up a substantial hosting portfolio long before SharePoint 2013 and the App model came along.


  2. You say “I can understand them as extensions of closed frameworks”, which I think is an important point. In many larger installations, SharePoint can be a pretty closed framework. If you are to deliver solution that you would like to integrate with SharePoint (for simplicity, say all you want to do is get the users identity and be able to easily launch the app through SharePoint), you really do not want to get mixed up in the team that maintains and develops the core of the SharePoint solution.

    With an app, you can communicate with the team in respect of a manifest-file, and you just go ahead and do your work on another server. You can restart and redeploy your application without taking down the SharePoint servers. You can deliver on another schedule, and changes you do can’t break anything but your own stuff. Once you start introducing risk into another project, and especially if that other project runs core document functions for the entire business, you have all sorts of issues building your software…

    I guess, what I’m trying to say, is that this could bring a model of small, composable web applications to the Enterprise. Which I think is a very cool thing.

    1. Bjørn Einar,

      These things have been possible all along, yet nobody have done this. If this was a real problem, I strongly suspect that a market would have seen the value in providing a solution. To some extent, they have, in that there are plenty of ‘no-code’ solutions out there using script, HTML, CSS, and other magic tricks to make stuff that doesn’t involve doing farm level deployments.

      As for protection, this is also already handled through SharePoint. Microsoft has gone to hell and back twice to ensure SharePoint Designer can’t muck up too badly while enabling users to modify their sites, including adding elaborate ‘Apps’ through script and HTML.

      In fact, this points to a second problem with your argument. Microsoft explicitly says they don’t want people to go too crazy with SharePoint Designer (their words were more or less “Don’t muck about with the design, we’ve done it right”) and yet, we are now to believe that it’s OK after all as long as you just do it in a way that makes Microsoft money when you do it.

      Apps aren’t necessary to make this happen. Isn’t now, hasn’t been in the past, probably won’t be in the future, unless Microsoft decides to kill server-side development completely (and, I suspect, SharePoint along with it).


  3. Bjørn – The ‘app model’ does solve a very real problem – you’re just looking in the wrong place.

    Its got nothing to do with technical abilities or ‘modern techniques’ or app stores or business problems for customers – its all to do with Microsoft.

    Now they are running farms of ‘bazillions’ of servers for SharePoint Online they can’t have your problems becoming their problems.

    The App Model is an attempt to ensure your problems stay your problems and all other arguments are just bluster and marketing fluff.

    Of course Sandbox Solutions were an attempt to do the same – but a hastily put together bodge that didn’t really achieve the goal.

    Anyways – Your smart and cynical (in a good way, one persons cynical mind is another persons investigative mind) so I am guessing you’ve already come to this conclusion.

  4. I was just about to write the very same thing as Ryan, so instead I will just add one thing.

    It is easy to conclude that “this is just an Microsoft Office 365 thing” however Microsoft’s need to isolating the Platform from the Business applications – which is the main driver behind the new App model – is also a growing need in many large global organizations running SharePoint.

    This is because these organization does not have the ressources available on the operations side either to thoroughly analyze and qualify every Farm solution that the business divisions have built or purchases from external parties. They are meet with increasing requirements for availability and stability as the SharePoint platform becomes more and more business critical and to allow for faster changes in business applications running on SharePoint.

  5. Ryan, Flemming et al

    All solid points.
    This is an important discussion and typically I usually ‘agree’ or ‘disagree’ with Bjorn behind my computer monitor and that’s it. His blog post, we’ll just say is a lightning rod at times when he decides to take on a topic, a post, or a person, and I say that as a person who knows Bjorn personally, and respect his points of views. He and I were tweeting back and forth last night on this very topic, to set the tone, I agreed with his conclusions even before reading @dougware (another friend of mine) blog because I understood the points he was trying to make even though I didn’t know if Doug was arguing a topic counter to what Bjorn was arguing against. After reading Doug’s blog, and as a fellow developer as well, I saw where Doug used words like objective/subjective/qualifier in his post. I use words like that myself when answering questions or taking a position that I KNOW can be totally right, and totally wrong at the same time, it just depends on your perspective.
    Indeed, I agree with Doug’s points as well, if it look at it purely from a technical perspective, I pointed out as much to Bjorn in my tweets. My argument was and still is, even though the App Model didn’t really give us anything that couldn’t have been done with existing technologies years ago in fact, and have been able to do albeit to a degree with SPServices from @sympmarc Marc Anderson, what it INDEED DOES provide are OPPORTUNITES such as
    1. Richer API that you can consume better and newer data/information
    2. Tooling Support in SPD 2013 and VS 2012 that makes API consumption better
    3. A Model that promotes a true SOA platform
    But in the end, I, let me say it again “I”, believe that this came out NOW, because it is part of a Business Strategy moreso than to solve a technical barrier. But, in the end, what will “I” do, I will follow along, because I have hitched my wagon to Microsoft, it has took care of me in the past, and I am sure as long as I keep learning how to keep up with their strategy and technology, Ill keep doing what I love to do, which is develop solutions and write code 
    PS. @Dougware is coming back with his retort soon, you all should know that 

  6. Aw shucks and by golly, @furuknap and @fabianwilliams.

    In my head I’ve started using the tag line “The first SharePoint client side object model” for SPServices. That’s not totally true, as there were a few others out there (jPoint and SPAPI, at least), but it seems to be the first one that gained wide acceptance. That’s a really cool thing for me, I’ve gotta say.

    Getting code off the SharePoint box is one of the main reasons I think SPServices is successful. To me, deploying crappy code to an often unstable server is just a really bad idea. By moving toward the “app” or “off box” model, we at least can try to ensure that the servers run as best as possible.

    Bjorn is right that if you are a good SharePoint developer, you won’t endanger the way the server runs at all by deploying your code to it. Unfortunately, I have yet to see that case out in the wild. Custom code almost always turns out the be one of the issues with broken SharePoint farms in my experience.

    At least when we write crappy client-side code, we can’t break the server. (@MrAckley swears he can break the server with client-side code in 5 seconds, but I’m not talking about maliciousness, just crappy code.) Yes, we can give every user a crappy user expeiences, but we fix the script and reload the page and all is well. There’s no digging around in the server’s GAC to try to figure out what ended up in the wrong place and is uninstallable.

    So I’m all in favor of the new app model in theory. I haven’t done anything with it in practice because to me it seems like it has far too high a barrier to entry, as do many Microsoft things. I think in its current incarnation it complicates things rather than simplifying them. I’ve been reading @dougware’s posts and I think he’s got some excellent points about the app model. I’m also pretty sure that he’s spending a HUGE amount of time figuring it all out.


    1. Marc,

      Not only can you easily break the server with JavaScript code, you can also break all the clients. That, however, is also no different whether the HTML+JS was delivered in a package having an extension of .zip, .wsp, .app, or .sin. Apps don’t change that.

      Malicious or unskilled, that’s simply a matter of whether you go to jail for it afterwards.


    2. Marc,

      You are not the only one who has seen poorly written server code causing issues with a SharePoint farm. I have also seen where a poorly written solution actually ended up costing a client quite a bit more than necessary due to the early deployment of the solution and the wide adoption.

      I would agree that the App Model has a high barrier to entry. As it matures and more guidance is developed by the community I think we will see a wider adoption. However, we do have to be clear when working with clients to help them choose the best approach for their solutions — the app model offers a new approach but it may not always be the best approach.


  7. Bjørn,

    I would simply ask one question concerning how you would approach a client that is maintaining a farm with a policy that does not allow any third party code to execute on the SharePoint server, effectively keeping the developer from deploying any farm solutions? I have come across this scenario multiple times in my career, usually at a larger client where SharePoint has become or is becoming a strategic part of their business.

    With SharePoint 2007, developers could use SharePoint Designer to augment the capabilities of the site. SharePoint Designer allowed developers to do a lot focused on the client and services architecture, thanks to projects like Marc Anderson’s SPServices library. However, this often resulted in a site that was not easily maintained or became difficult to duplicate for other groups within the organization.

    SharePoint 2010 introduced sandbox solutions to try to give developers a way to create code that could be easily deployed and managed without running “on the server” (in reality, without the necessity of the SharePoint farm administrators to install the solution). SharePoint 2010 also provided CSOM and OData giving developers more capability to build client based solutions. Theoretically, this provided a better way to deploy complex solutions, but most developers agree it didn’t quite go far enough. So developers again turned to SharePoint Designer.

    The SharePoint 2013 app model is attempting to do what Sandbox solutions failed to accomplish in SharePoint 2010. The expanded capabilities of the App model, especially the ability to build provider hosted applications, allow these large organizations to build custom solutions that are not executing in violation of the “no farm solutions” policy that they may have adopted. Additionally, allowing Apps to become part of the App catalog solves the problem of redistribution.

    I believe this is one of the problems that the new SharePoint 2013 App model solves.

    1. Chris,

      To those people, I would first ask them to fire their previous advisors who are stupid and ignorant people with self-interest in mind before that of their clients.

      Let me turn the question around: What would you say to a client that prohibits the use of the letter E or the period character (.) in code? It’s a totally random prohibition that has no sensible rationale. If ignorants unite and start chanting that “all client-side exploits have included the letter E and a period and those things should thus be banned”, then our clients will develop that same fear, much in the same way children inherit the fears of their parents.

      To your other issues. All of the things you mention, as I’ve said, are not just doable but easily doable in previous versions of SharePoint without a new deployment model. There’s no magic going on; it’s simple HTML+JS. You can deploy that with copy+paste, for crying out loud, no need for farm solutions at all if that’s what your (or your client’s) irrational fear is really about.

      We, as the technical experts, are easily distracted and exited by new technology. It is we, not our clients’ needs, that dictate whether we’re going with a new model. We, as sheep of Microsoft’s marketing, now run out to our clients and say “sorry, all the advice we’ve given you before has been wrong, now you need to buy a new gizmo, but this time, we’re right, promise, scout’s honor, etc”.

      We know we could have solved these problems before, had they been real problems. We have solved similar problems before, heck I’ve done it lots of times, long before Microsoft had the need to herd us all into their new pen. Why haven’t we done this already then? Is it just because we’re bad developers who didn’t know how? Is it because we’ve been waiting for someone to create a packaging method for us because we didn’t know how or couldn’t be bothered?

      What the heck has held us back from doing this already, if it was a real problem?


      1. <I know the answer/raises_hands>, in fact, I surmised as much in my last few sentences. When it comes to MS Technology, I am one of the sheep, I allow myself to be herded, you know why, it pays the bills. I can buck, yeah.. but I know there are ‘legitimate’ arguments to be made for the shift in philosophy, standards, technology, strategy… it probably is just one I don’t want to hear or believe. Sad… but true, but I know I what pill I am swallowing ahead of time.

        1. Let me pose a follow-up question to that, Fabian,

          If someone gave you a gazillion dollars right now, taking the money out of the equation. Would you still follow Microsoft’s lead into whatever they pointed you? Would you offer the same advice to your clients if you had no personal gain from recommending one above the other?

          If you say no, then essentially you are doing what you’re doing because you get more of the client’s money from doing so, not because it’s the best choice for the client. I find that a despicable attitude.


      2. I don’t disagree with your stance. However, I have come across a few clients that were burned by poorly written farm solutions that did bring down their farms or created situations in which an upgrade became very expensive. Farm solutions have a place in the SharePoint ecosystem and I’m not questioning a developer’s ability to accomplish the same goals with a client side solution (crated in SharePoint Designer or by the use of content editor web parts).

        I have written MANY farm solutions for clients (and deployed many more), so I am not opposed to them. I have also written many client side solutions for clients using SharePoint Designer, Content Editor Web Parts and even just performing a few CSS tweaks.

        Any approach taken should be evaluated as part of a larger process to determine the proper model to use. Just as the client should not view all farm solutions as dangerous (I’ve shaken my head a few times when I have received that mandate from a client) — we, as the experts, shouldn’t just paint with a single color and instruct our clients that all they really want is a red room. It doesn’t matter if that “red” room is a Farm Solution or a SharePoint App.

        For example, clients that are considering moving to SharePoint online (or are already in SharePoint online) cannot make use of Farm Solutions, so they will have to evaluate the best approach to building a solution. Does it make sense to build a SharePoint 2013 App? Maybe. Should we use HTML+JS? Perhaps.

        Then we have clients that are attempting to integrate LOB systems or other “fringe” technologies into a more seamless experience, and the client has selected SharePoint as the integration point. Often, the client will have a team dedicated to these systems who have no experience in SharePoint. As experts, we need to help the client determine the best way to integrate these systems — and the SharePoint 2013 App Model becomes yet another tool in our toolbelt as an option to choose.

        As much as I love Microsoft and built my career around the Microsoft technology stack, we must also acknowledge there are many who do not land so solidly in our camp. Microsoft has provided a wide toolset for use by developers and we should never exclusively say this ONE tool is always right for the job. It doesn’t matter if that tool is a farm solution or the new SharePoint 2013 App Model.

        1. I think that’s the best explanation of what I tried to communicate in my comments above. Infact, I will use that “red room” analogy when I am faced with those situations from now on. One additional point I will raise on this and hopefully let it go is this, Developers are sometimes, well most of the times prejudiced by what technology they either love, or know the best. I know I fall into that camp, and it takes real EFFORT to break out of that mold, indeed it is what best (or better) practice preaches. Start with OOB, then look at tweaking the OOB, then look at Add Ins, then look at Custom Solution, in that order. I think the problem arises however when the goal post gets moved i.e. new technologies are introduced into the equation.

          I like this spirited discussion, I for one am learning a lot of point of views.

  8. I don’t disagree with your stance at the technical level as previous people have said, the excellent Marc Anderson (@sympmarc) produced his SP_Services a good number of years ago which meets most people’s needs. So the App model is not bringing anything new to the table technically.

    However, as Fabian Williams (@FabianWilliams) says a lot of us have decided to nail our mast to the Microsoft Ship and that has what has paid my mortagage and holidays for the last 20 / 30 years. Microsoft has decided that in order to make Office 365 (and SharePoint Online) work we need to get the custom code off the SharePoint Servers so that if anything goes wrong with the SharePoint Servers its a Microsoft issue not a customer issue. There was no other way that they could go. Sandbox solutions were so restrictive in what a developer could do they had to find another way to allow developers access to the SharePoint Servers which gave the developer as much functionality as the “Full Trust” model, whilst not letting them (inadvertently or maliciously) to bring down the whole farm.

    So there is no technical reason for the App Model, the reason for the App Model is to provide Microsoft a way to get the developers off the SharePoint Farm, In the cloud AND on premise because a number of reported reliability and performance issues with SharePoint were due to bad (or inadequately trained) developers and that was giving SharePoint a bad name. Which gave the likes of Google and Apple marketing ammunition.

    Anyway, a new App Model keeps the training companies in business, which keeps the SharePoint ecosystem in business. (as one who has just completed an developers upgrade course)

  9. Really interesting lightning-rod topic! I agree with many of the points in this post.

    On the pro-app side, there is one consideration that I haven’t seen discussed yet. When you use farm solutions, you are married to the version of the .Net framework that the particular version of SharePoint you are targeting supports. There were so many times in SharePoint 2010 development that I would have loved to use some of the .Net 4.0/4.5 features, such as MVC, Routing, Async Tasks, WebApi, NuGet packages, the dynamic keyword (dynamic would have been awesome in dealing with list item columns, a little puppy dies every time someone codes item[“ColumnName”].ToString()). Always felt stuck in the past doing SharePoint 2010 development.

    I think the real limitation with apps is that the only way you can see them in a non-app-web are via list item dropdown custom actions, ribbon actions, and app parts – that’s it. My customers want information more seamlessly integrated – they want to put visuals into places that aren’t web part zones, like the left nav, or the bar where you see Share and Feedback buttons, or they need to open modal dialogs, or alter a blog post layout, or put things under their profile picture on the MySite Host, or in a static footer, or use other custom actions like the Welcome menu, Site Actions menu, or Site Settings links. They want to make things consistent, for example all MySites look the same with their corporate branding applied. They want the kind of integration that is really only possible with a delegate control, or feature stapling, or the other tools in the farm solution toolbox.

    I don’t see many scenarios where it makes sense to take a user out of SharePoint to a completely different area and sequester them there in your “app”.

  10. Not to be a smart aleck here, but for all you suggest we don’t even need SharePoint! And, even if we continue to use SharePoint for whatever reasons, I don’t even need web parts to do what you have done in the past.

    Bottom line for me: farm solutions are a pain in the arse. They have tendencies to do things like modifying the web.config files and, often times, they do this badly. And that’s just the Microsoft Gold Partner vendors out there, never mind what some guy’s kid might do for them in the basement.

    Yes, yes, you scoff at the notion that apps solve this problem, and maybe they don’t really, but it may be a step in the right direction. It seems to me that creating objects that execute somewhere other than your main web apps reduces risks. Since I am essentially a team of one for a rather large farm with no developers at hand and no testing department, this seems like a good thing.

    And, since the apps model does not preclude do-it-yourselfers like yourself, everyone should be able to develop an approach that they are capable of maintaining.

    So, I challenge you: what would you do to improve on the app model to make it truly beneficial all around?

    1. Collin,

      Your challenge is non-sensical because it assumes that the entire premise for the article is incorrect. Why would the App model need improvement? It doesn’t solve any problems so improving it would mean that it would have to solve something else, which would not make it the App model.

      Let me put it in another and somewhat silly way. Let’s say Microsoft said that squirting citrus juice on your keyboard would make you a better SharePoint developer. I would argue that such a thing is nonsense, but your challenge would then be for me to tell you what exactly I would do to the squirting of citrus juice to ensure it makes me a better SharePoint developer. You’re assuming the answer and ask me to prove you right, which simply doesn’t make sense 🙂

      As to your other comments, they’ve been answered many times over in different posts over the years. For example, farm solutions ‘often times’ do not behave any better or worse than they people authoring them. How would getting yet another way of doing something make those authors better developers? I could just as easily argue that “sometimes Apps do things in a bad way” and your entire argument would be void. However, neither Apps nor farm solutions behave in any way; a poorly written App is just as bad and dangerous as a poorly written farm solution.


      1. I’ve actually tried this citrus juice trick and it does indeed make you a better SharePoint developer 🙂

        Joking aside, I agree that the new app model seems to solve no business problems, other than Microsoft’s. I’m trying to keep an open mind and figure out how this new model fits into my development arsenal. So far I haven’t seen any compelling feedback to your post to help me figure that out. I’m afraid that after all these months with the new app model if as a developer community this is as far as we have gotten, then it seems to be headed for the way of the dodo bird.

  11. I found this to be a great post and right on target. There are also tons of good points/counterpoints made in the comments.

    The one consideration I would add (in favor of Full-Trust Farm solutions) is that enterprise solutions are not very useful if they operate in a silo. Inherently the “App Model” will lead developers to create “Apps” that solve, one-off business problems. Then ultimately, these Apps will need to work together at some point to provide a truly integrated, solution.

    Just look at some of the Apps available in the Marketplace today, or available for Yammer. You can get an App that will allow you to create and Manage Ideation, and you can get an App for Badging and Recognition, but these Apps will likely NEVER work together as they are provided by two separate vendors, so you can not (and likely NEVER) Badge a user for submitting or contributing to ideas in your organization.

    Now certainly, you could write your own apps that provide the full functionality, but very quickly you will find that any of the potential gains that are mentioned in this article and comments will be outweighed by the time/cost to implement them versus a Farm Solution.

    Companies will have to decide to build these solutions and/or create some custom integration layer between apps and both of these options will cost more than had you gone with a scalable Farm Solution to begin with.

    Good Stuff guys !


  12. Pingback: CorasWorks Products & Solutions » Microsoft’s Moving the Cheese….. Understanding The New SharePoint App Model
  13. How putting things in an iFrame is any good or modern?
    It ruins accesibility standards, to begin with. Something we know Microsoft has ruined over and over again in each version of non standards compliant ECM’s.
    At least, with Farm solutions and control adapters, page adapters, custom controls, custom field controls and so on you can solve this rendering mess, but, if the rumours are true and Microsoft will ban farm solutions in 2015, they will shoot in their own feet.
    Public administrations in my country, will have to ditch Sharepoint as their ECM.
    It is utterly stupid. Besides, I have developed a custom control that actually embeds html from other servers in a seamlessly way. I didn’t need a crappy iFrame spitting platform at all.

    Stop it, please stop it!!! Nobody wants the fricking cloud, nobody who is interested in keeping their information secure anyway….

    Sorry, I had to throw it up

Leave a Reply

Your email address will not be published.