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