Major changes for SharePoint developers may not be so bad

If anything, SharePoint is growing up

Mark Rackley

by Mark Rackley on 7/9/2014

Share this:

Article Details

Date Revised:

In the first article in this series I gave you an overview of why some people believe SharePoint may be on its last legs. In this post in the series I’ll talk about one of the biggest contributors to that mindset: the App Model. Being a SharePoint developer myself, this is the topic I have the strongest opinion about. One of the biggest (and loudest) reasons some people are proselytizing the dismal future of SharePoint is the drastic change to the developer landscape in SharePoint 2013.

Let’s start the discussion in the past. Do you know why I love development in SharePoint? Because it’s my box of Legos. I can create and configure a site for a client in minutes. This site can take advantage of all of the out of the box functionality SharePoint has to offer and give the client 80 to 85 percent of what they need. I can then open up Visual Studio (or write some client-side script) and totally transform the site to meet the client’s exacting standards and requirements. I can create custom web parts and event receivers and give them exactly what they need.  What’s more, as I’ve gotten really good at using SharePoint and developing in SharePoint, I can get a lot done very quickly. There was a lot of frustration while learning to get here. But now that I’m here, it’s great. Customers are happy, and I can provide maximum value.

That being said, if you did not understand SharePoint and tried to develop in it, you were going to cause some damage. A lot of developers out there do not know how to properly develop in SharePoint. These developers have created really bad solutions that were (are) creating performance nightmares and memory leaks and crashing farms. Let’s face it, one of the reasons I have a job is because of these bad developers (so thank you).

And that’s how things were. We adjusted, we learned, and life was pretty good. Rates were really good.

Along came Office 365 and SharePoint Online

Microsoft has a clear vision. They want you in the cloud. They want you in the cloud for many reasons. Many (all?) of those reasons are financial for Microsoft. Hey, they aren’t in business to lose money. So, they introduced Office 365 and SharePoint Online. Now, everyone has access to SharePoint for little money and no investment in hardware. In addition, there is a  less critical need for expensive SharePoint administrators in Office 365.

Sounds great? Right? But wait a second. If you put SharePoint in the cloud, what do you do with all that custom code sitting on your existing SharePoint farms? There is no way in the world Microsoft could allow some random developer to put custom code on Microsoft’s cloud-based servers. Can you imagine the chaos if some “SharePoint expert” deployed a solution in the cloud that affected your tenant on Office 365? 

How do you keep developers from trashing countless servers? Simple: You don’t let developers deploy any solutions to the servers in the cloud. Problem solved.

But, Office 365 customers still have development needs. How can you give companies the ability to develop powerful applications for SharePoint but at the same time keep them from installing any custom solutions on SharePoint in the cloud?

Enter Microsoft’s new App Model.

And there was not much rejoicing.

On the surface, the App Model may sound appealing. The App Model allows developers to integrate with SharePoint through a set of REST APIs and the Client Object Model. What’s more, you can now write SharePoint “Apps” in different languages (Java, PHP, .NET--you name it).

The way SharePoint development now works is that when you use the App Model, you are either deploying client-side code (SharePoint Hosted App), or custom code of your choosing and hosting it on your own web server (Provider Hosted App).

See what Microsoft did? They got the developers off Microsoft’s server in the cloud. Exactly what Microsoft needed. If you write a SharePoint Hosted App, you don’t have any direct access to the server, and if you write a Provider Hosted App, the only thing you might crash is your web server. Sounds perfect. Right? Problem solved.  What’s wrong with this approach?

SharePoint is no longer a development platform

What’s frustrating is that taking the App Model to its logical conclusion, you are no longer using SharePoint as a development platform. For example, you lose the ability to customize a Site Collection, which a customer may have been using for months (or years), by quickly adding a Full Trust Web Part or some other Server Side solution to handle some simple piece of functionality. 

The moment you need to create full trust code to interact with an external business system or elevate permissions in the App Model you’ll need to create a Provider Hosted App. If you create a Provider Hosted App you no longer have access to default forms for your application, or site settings, or list settings, or any of the SharePoint functionality that you had grown accustomed to in the UI. You have to develop it all from scratch! In this scenario, SharePoint has become a set of APIs. It’s become a place for data storage, authentication, and security. It is not the rich development experience it used to be.

Yes, I know that on-premises SharePoint 2013 can still deploy your custom solutions, but I’ve been chastised multiple times now about that type of development not being the future. And if you have any conceivable future plans to move to Office 365 you need to change the way you are developing for SharePoint today.

It’s almost like SharePoint is now two different products: The out-of-the-box SharePoint that allows you to create (but keep those customizations to a minimum) sites for collaboration; and an API that allows you to create “Apps” that piggy back off of SharePoint security and are exposed as iframes (yes, iframes) in your SharePoint environment. Again, if you are using SharePoint on-premises, you still get the legacy development options. But Microsoft has made it very clear that Apps are the future! They want you using the App Model.

In one sense, a big problem I have with the App Model is I feel that it actually can be an argument against making an investment in SharePoint if you don’t already have it. Why make the investment in SharePoint if it’s a now constrained collaboration platform and a set of APIs? You mean I have to set up a separate web server, write a web application (okay, I do that today), but now I have to do extra work just to display that same web application in an iframe in SharePoint? You seem to lose one of the most compelling reasons to jump over to SharePoint with this fundamental change in the way development is accomplished and with the loss of ease of integration with your other business systems.

And that Full Trust Web Part that I used to develop in a couple of hours? Well, now it’s going to take me two or three times longer to get the same functionality in Office 365. It’s going to cost my customers more money, and they aren’t going to be happy. Plus, if I have to write a Provider Hosted App for a customer who is on Office 365, they have to stand up a web server somewhere just for that little piece of functionality. Many small and medium business are going to be upset when they learn they made this investment to get rid of a bunch of servers and now they have to set another one up and administer it. That can be a deal breaker for a mom and pop shop. And that sandbox solution that I could do in half an hour? Nope, need to find another way of doing the same thing.

Life for SharePoint developers got harder.

A real-world example

Let’s take a look at a recent post by a brilliant SharePoint guru by the name of Waldek Mastykarz: Deploying Custom Actions using the App Model.

In his post, Waldek explains how to use the new App Model to create a Custom Action to deploy a script. Before you read his post, here are the steps to do the same process as a legacy Sandbox Solution using Visual Studio.

  1. Open Visual Studio

  2. Create an empty Sandbox Solution

  3. Add an element to the project

  4. Enter something similar to the XML below in your element

    <?xml version="1.0" encoding="utf-8"?>

    <Elements xmlns="">








  5. Save. Compile.Viola. You are done.

How easy is that? Now go read Waldek’s post, and take a look at all the effort you have to go through now to do the same functionality using the App Model. How can all this change be worth it in the end?

Let me be clear. You can still customize SharePoint. You can still throw a Content Editor Web Part on a page and link it to a script. You can deploy artifacts with Sandbox Solutions. If you have on-premises SharePoint, you can still create your farm solutions and easily integrate with your business systems. However, I am reminded often that the App Model is the future.

“All future investments will go to making the new SharePoint app model richer and more powerful. Accordingly, we recommend that all new development should use the new app model whenever possible. In scenarios where you have to develop a farm solution or coded sandboxed solution, we recommend that you design it so that it can easily evolve toward a more loosely coupled development model.” - Apps for SharePoint compared with SharePoint solutions.


Bottom line: You must start looking past the way you are doing development currently.

Is the App Model all bad?

Are you beginning to see why those entrenched in SharePoint for years are a more than a little frustrated? But is the App Model really that bad?? Is the future of SharePoint development really so bleak? 

First and foremost, it is important to remember that those of us who have been doing SharePoint development for years have invested many years into learning the ins and outs of SharePoint development. We take pride in that. There was a lot of blood, sweat, tears, cursing, and alcohol to get here, but we got here–doggone it. Not just anyone can be a SharePoint developer. We have our pride and our biases.

However, if we open our eyes and look at the situation for what it really is, we can see that things really aren't that bad. (Don't get me wrong; they are still really frustrating, but not all doom and gloom.)

It's not a bad idea

Here’s the thing. The App Model is a necessary construct for a successful deployment of SharePoint. By creating the App Model, Microsoft has removed one of the biggest problem factors from the SharePoint end user experience: us developers.

Have you previously had a bad experience using SharePoint? Has it been too slow? Too flaky? Not working right? There’s a good chance that your issues had nothing to do with SharePoint and everything to do with an uneducated developer. By creating the App Model, Microsoft is allowing SharePoint to run unfettered. You will see a more stable and consistent user experience moving forward.

Yes, we have to learn new skills and discard some old ones. Change isn’t fun, but it can be necessary.

Growing client-side API

The REST and Client-Side Object Model API for SharePoint is really powerful, and it just continues to grow as Microsoft invests in it and it continues to gain acceptance. This allows all developers to write SharePoint applications with little more knowledge than HTML and JavaScript. (Okay, you do need to actually be a good developer, though.)  In addition, since these APIs are growing, the amount of functionality we “need” traditional farm solutions for is shrinking.

For more information and to get started using REST for SharePoint 2013 check out: 

Get started with the SharePoint 2013 REST service

To learn more about the Client Side Object Model (CSOM) look at:

How to: Complete basic operations using SharePoint 2013 client library code

It's not just about SharePoint!

The App Model is not just about SharePoint development. It’s about Office 365 development. If you learn the new Office 365 APIs and the App Model, you are now equipped to develop apps not just for SharePoint, but for Exchange, Office, OneDrive, and, in the future, all applications on the platform (Yammer, Office Graph, etc.).

It's really time to come out of our holes as SharePoint developers and take a look at the big picture here. There is a plan. There is a reason. It's a pretty exciting time if you think about it.

Not everyone hates the App Model

If you just did a search online, you might think the entire development community is against the App Model. Newsflash. That’s just not true.

In the past month I’ve sat down with two different groups of Java developers and explained the App Model to them. Do you know what their response was? Did they turn up their collective noses and say it was a bad idea? Did they swear to never use SharePoint? Did they stomp around like spoiled brats?

NO!! They thought it was a great idea! These Java developers who were grumpy about having to do SharePoint development now felt relief and excitement to know that their current skills still mattered. They were happy that they didn’t have to learn .NET or some weird Server Object Model.

As much as I personally hate to admit it, the App Model does open up a world to non-SharePoint developers and many are actually excited about it.

Now of course, they are excited about the idea. Let’s see how they feel after 3 months of developing in it.  J

What do we make of this? What should we as developers do?

SharePoint Developers

Get over yourselves. It’s time to learn new skills (or in some cases dust off old ones). Time to work on a new set of templates we can copy and paste for our solutions. In fact, you can go get some App Model samples right now on codeplex at Office App Model Samples.

SharePoint is not going anywhere. In fact, it now has a much broader audience.

We can either whine and moan about the good ol’ days, or we can suck it up and learn the way things are done now. Yes, we might be more replaceable now. So, let’s get our hands dirty and show these youngsters how to take our knowledge of SharePoint to create the best SharePoint Apps.

It's time to grow. Time to give up the mantle of "SharePoint Developer" and work on becoming an "Office 365 Developer." (Yes, it hurt a little bit typing that.)

Non-SharePoint Developers

Now’s the time to jump in. Learn the App Model from the ground up without the biases of us old crotchety SharePoint developers who yearn to deploy directly to the GAC. The skills you have right now can be immediately put to use in SharePoint. A lot of the pain and grief the rest of us had to go through are simply not there for you. You Java developers will not miss the way things used to be because it was never a reality for you. Don’t let the naysayers detract you from learning a valuable and marketable skill.

If only there were some way to get started!

Hey! Lucky for you, Microsoft’s newly minted Technical Product Manager Jeremy Thake (@jthake) will be presenting a session at SharePointalooza in September: “Preparing for the Shift to the App Model.”

You can also get started with the App Model online at: Overview of apps for SharePoint.

My personal plea to Microsoft as a SharePoint developer

I’ll make you a deal Microsoft. I’ll make the effort to learn to do the things the way you want me to. I’ll use the App Model. I’ll try things your way (when I have time). But I have one thing to ask of you. As a developer and consultant affected by these changes, I have a plea. Don’t frown upon non-SharePoint apps.

People in the real world are using SharePoint every day to get their job done. Multitudes of “That Guy” in many organizations are responsible for all of SharePoint. In many instances, they are not strong developers, but they have a job they have to do! Don’t make their job harder! Allow them to continue to link to a script in a Content Editor Web Part without being shamed. Let them deploy a Sandbox solution with code so they can just get back to the thousand other things on their list. Find some way of making Timer Job functionality easy to replicate in this new world.

We understand you want us using apps, Microsoft. We get it, but we have jobs to do. Don’t tie our hands and force us to jump through hoops to do something that used to take 15 minutes. If you don’t want to enhance certain features going forward, fine! Leave them as they are and let us use them without scorn.

Far more real-world SharePoint developers are out there than there are academic developers who get to think of ideas but don’t have to live with the consequences day in and day out. The App Model is an essential part of the SharePoint online development experience, but it should not be the only accepted development tool now or in the future.

Let’s not throw the baby out with the bath water. Let’s build out the App Model and Client-Side API’s while still allowing the developers to get their jobs done quickly and easily and move on to their next task.

Obviously, I could go on and on about this topic. It affects me and my clients the most. The truth is, the more I examine the future and the purpose of the App Model, the more I soften up to it. Or maybe I’ve just been beaten into submission. Regardless, I hope you now understand where most of the negativity is coming from and realize that while things may be more difficult to develop at times. SharePoint is maturing platform. More examples will be created, processes will get streamlined. (Remember manually creating your .DDF and Manifest.xml files for SharePoint 2007?) Give the new model some time.

In many ways, this blog post is my own personal pep-talk. I’ve been fighting the use of the App Model. I’ve been one of the ones to pitch a fit. However, when you take a step back and realize there is a reason and a plan, it does make the changes easier to accept. There is just so much more to learn now.

SharePoint is definitely not dying because of the changes to development. If anything it's finally growing up.

Topic: Cloud

Sign in with

Or register

  • And yes... Existing Legacy Systems still matter. We just may need to alter our strategy, or go Hybrid. There ARE options... if we can be open to them.
  • If your "On Site Private Information" can be accessed outside of your network then I'd argue it's less secure than if it was in Office 365. In the next article deals with some security concerns.
  • I have one word: Legacy
    I have another word: ON Site Private Information not willing to be "shared" in the cloud
    I have one more: Existing legacy Systems with millions spent on them - ALL MATTER
  • I'm in the process of architecting an enterprise application that I want to run on both on-prem and O365. I am diving deep into the rabbit hole! I'll let you know if I see the Mad Hatter.
  • Great article Mark. I was in the process of writing a book about App development when my frustrations with it stopped me after only four chapters. I'm slowly coming around though!
  • Bravo!! Respect you that you wrote my heart out in this blog post. Going through the same frustration. And watching my clients moving to Google Sites.
  • You are definitely not in the wrong field by choosing SharePoint. The field has just gotten a lot broader. I'd start off by learning all the ins and outs of Client Side Dev. Look at REST and CSOM
  • I'm really curious to read the rest of this series. As someone who is just starting out in SharePoint, I wonder if I chose the wrong field, or the wrong time to join. I guess it's a blessing/curse.
  • For a SharePoint developer that's just starting out, where would you recommend increased focus? Does it make sense to learn to develop in all SharePoint environments, or learn the new techniques.
  • Bravo, love the post!