Office 365 Client-side Devs: Be Heard

Mark Rackley

by Mark Rackley on 7/10/2015

Share this:

Article Details

Date Revised:

Applies to:
client side development, Office 365 API, SharePoint add-ins

Sponsored by

I had the opportunity and honor to be a guest on Jeremy Thake’s and Richard Richard DiZerega’s Office 365 Developer podcast a couple of weeks ago while I was at SPTechCon DevDays in San Francisco. Jeremy and I spoke at length about a topic that I have a bit of experience with: client-side development.

Office 365 Developer Podcast: Episode 052 on client side dev with Mark Rackley

I’ve been writing code for over 20 years now and I’ve written my fair share of Full Trust solutions for SharePoint. However, it’s no surprise to anyone who knows me that I’ve gravitated toward client-side development and JavaScript over the last several years.

It’s a no brainer really; developers can create powerful scripts using JavaScript along with web services, REST or CSOM and upload those scripts to a document library. Then those scripts can be referenced on a page in SharePoint using a Content Editor Web Part or a Script Editor Web Part and bam… you’ve made SharePoint more usable, you’ve made your SharePoint form stylized with extensive business logic, you’ve called web services to create powerful dashboards AND it works in SharePoint 2007, 2010, 2013, and Office 365… PLUS, you don’t need Visual Studio or any complicated IDEs. You don’t need server access, you don’t need to worry about OAuth. You can get your job done in minutes and move on to the next project. What’s more, thousands of developers are using these development techniques every single day to get their jobs done quickly and effectively.

Sounds simple enough; what’s the problem?

The problem is that this development approach does not actually fit in with Microsoft’s ideal of using SharePoint add-ins and Office 365 APIs. To be fair, Microsoft is not against us sticking a script in a library and linking it to a page. It’s not a “no no” but if you go and have a conversation or two, you’ll get a lot of “Why on earth are you doing that?” and “You SHOULD be doing it this way.” So yeah; it’s “supported” but I’d say it’s not encouraged.

And to be honest, there are reasons NOT to encourage it. Putting a script in a document library and linking to it in a Content Editor Web Part is not without its issues. Chief among these issues is enterprise deployments. It’s not simple to automate the deployment of these scripts if you need to replicate it across 30 sites. If you aren’t using Visual Studio, you don’t have easy integration into TFS and other source code control options. When you scale out this type of development, there are a few cracks. Yes, you can use Visual Studio and sandbox solutions to deploy your scripts quite effectively, but you have complicated the process for those not comfortable in Visual Studio. Throw in the add-in model and you’ve lost a huge chunk of SharePoint client-side developers.

There is also the issue that a lot of times using this technique you are modifying the Document Object Model (DOM) to manipulate elements on a page. It’s rare, but Microsoft can change the elements on a page without warning. If this happens, it could break any script you have executing a page. Is this a reason NOT to use this approach? Absolutely not; it’s just something to be aware of.

So, I understand they would like us to do something more deployable and less dependent on the DOM and let’s face it, I would like that too… but man… it’s SO simple. SharePoint add-ins and the Office 365 APIs are not nearly as straightforward.

What Microsoft needs to understand

Yes, I know where Microsoft wants us to go, and I’m totally not against it. There are just some hard truths that need to be understood about why the add-in model and Office 365 APIs are not the best approach (yet).

It’s not about fear of change

I know I hear often that the main reason for not going to add-ins and the Office 365 APIs is a fear of change. This is simply not true. Change is good. Change keeps us on our toes. Change leads to innovation. I love change. I also love being able to be effective and efficient at my job and serving my clients to the best of my ability. I want to enhance what SharePoint does, NOT build a whole new application for every scenario. Let SharePoint do the heavy lifting and support/enhance SharePoint with client-side development. Make that easy for us, and I’m all in.

Not everyone is Enterprise

It’s the truth. There are so many businesses out there with less than a thousand users, and they don’t need a solution that can be deployed 30 times. They need it deployed once. Why go to the headache of creating a deployable add-in that takes so much more time and is much more difficult? It’s overkill for a lot of people out there who simply don’t have the time.


The minute you need to open up Visual Studio to create a solution, you’ve lost a big chunk of people who are getting stuff done by writing a little JavaScript and linking it to a page. It’s simple with low overhead and you don’t have to be a seasoned developer to do it. By forcing these people to use a tool like Visual Studio you will send them into a tailspin. I understand Visual Studio Code has the possibility to help here, so I’m excited to see how that grows.

Legacy support

There are still a large percentage of people on SharePoint 2010 and even SharePoint 2007. These people need to get their job done and the last thing they want to hear about is the Add-in model.

Time and budget

The most critical factors: time and budget. I can deploy one of my solutions in minutes on any SharePoint farm. It can be tweaked in a text editor in a few more minutes. I can point clients to my blogs to drop in my scripts and make a few tweaks to them for their needs. I can provide SOWs to clients at a lower cost. Microsoft needs to figure out how to make add-ins that are simple and fast to develop and deploy. Maybe it’s just taking the time to build up a library of add-ins instead of scripts? Maybe, we’ll see.

What can we do?

Good question. Jeremy created a new Yammer Group Office 365 Dev Client Side for the purposes of furthering this discussion and help “us” make the transition to add-ins and Office 365 APIs. This is great news. We can voice our opinions and our frustrations in a constructive way and be heard. At the end of the day, we need to be aligned with what Microsoft is doing in order be best serve our clients. Plus, Microsoft needs to hear from us and understand this is a real development approach used by many developers.

I plan to spend some time trying to rewrite a couple of my solutions as add-ins and give some very honest feedback about the experience. Maybe our feedback will help Microsoft understand how critical this type of development is so they can best support us in our endeavors.

The goal of this article is NOT to bash add-ins and the Office 365 APIs. I would actually like to use them more. The goal is to let those of us who are not in the space be heard, so that our efforts, skills and time are taken into account.

Microsoft, find a way to tweak the tooling to bring us into the fold and we’ll be more than happy to jump on board. Get us pigeon-holed, client-side devs excited about using add-ins for our clients.

And if you are one of us, join the Yammer group, let your voice be heard and let’s get our jobs done…efficiently, effectively and in the best way possible.


You can find Mark’s original blog here.

Topic: Development

Sign in with

Or register