O365 Client Side Devs: Be Heard

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, I’ve gravitated towards 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 IDE’s. 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 API’s.  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, 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 API’s are are not near 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 really hard truths that need to be understood for why the add-in model and Office 365 API’s 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 API’s 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 dev. 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.

Non-Developers

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 SOW’s to clients at a lower cost. Microsoft needs to figure out how to make add-ins that 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 API’s.  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 real development approach used by so many developers.

I plan to spend some time trying to re-write a couple of my solutions as add-ins and give some very honest feedback on 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 blog is NOT to bash Add-Ins and the Office 365 API’s. 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. 

8 comments

  1. Anindya Chattopadhyay - Reply

    I completely agree with this. Add-ins are probably more relevant when they are self-contained independent modules for solving particular business problems. The moment we need to develop related dependent modules, I think scripts referenced on a page in SharePoint using a Content Editor Web Part or a Script Editor Web Part, become much easier. However one good thing is all these scripts can later be easily used for developing related Add-ins. Just my thought!

  2. Pingback: Office 365 Developer Podcast: Episode 053 on micro services with Bob German | nokipedia.com

  3. Pingback: Office 365 Developer Podcast: Episode 053 on micro services with Bob German • PC Portal

  4. Etienne Bailly - Reply

    I really agree with your concerns. It’s not that easy and not allways possible to do. I guess we don’t have choice. Old school full trust solutions (wsp) will die with SharePoint OnPrem . Let’s admit it the next SP2016 will probably be the last and obviously just a simple way to slowly send us and all of our customers to O365. The SharePoint addins with their iframes (App parts) don’t really looks like innovation but that’s it… And i totally agree with you instead of enhancing SharePoint engine we will have to create each time a new full application/azure web site. Addins are cool for reusing perspectives but honnestly our customers don’t ask for that, they ask for what SharePoint have allways been : an evolutive tool, easy to link with their business applications, easy to enhance…

  5. Paul Tavares - Reply

    I too have resisted the ‘app/Add-in’ model because of its combersum approach and VS requirement. My wish for MS, when they first announced it, was for them to release some tooling (node npm packages) that would allow us web devs to continue to build apps the way we have been for years, but now package them into a App Store deliverable. I was close to try and reverse- engineer that packaging process and create a Grunt NPM package, but did not take the leap. I have found that ASPX files (and packing them with the app code) can fulfill that need just fine for now – and perhaps far into the future.

    I hope that your experiences in converting some of your own solutions will provide Jeremy and others with ideas on how to make that entire process better.

  6. Pingback: Office 365—monthly Dev Digest for July | nokipedia.com

  7. Pingback: Office 365—monthly Dev Digest for July | Triptoirvine69 Blog

  8. Pingback: Office 365—monthly Dev Digest for July • PC Portal

Leave Comment

Your email address will not be published. Required fields are marked *