The ultimate SharePoint Question – do I custom code or not?

As a developer, more particularly a SharePoint developer, this is my ultimate struggle. SharePoint is built on .Net, I can code anything I want in .Net, I understand the SharePoint platform very well; ipso facto – I can manipulate SharePoint for my needs. But should I is the question!

I preach the defacto line for SharePoint Developers – out-of-the-box first. But, in the end, I am a consultant. I need to make things work for my client. I rarely say no. Thus, I do custom development sometimes.

Let me be clear – out-of-the-box first, period! It usually covers 90% of my requirements. It’s amazing what you can do. Even with a little extra client side code (as long as you are using the built in tools like JSLink, XSLT, etc…). Point is – I think a lot of developers move on to custom code too quick. So, really make sure your requirements can’t be met with out-of-the-box first. Then, only if you are sure, move on to custom code. Don’t believe me – check out this site we did: https://getcovered.illinois.gov/en/get-answers/glossary. That glossary is an out-of-the-box SharePoint list with JSLink and Display Forms making it look the way it does. Very maintainable, very supportable. No real custom code other than JSLink which is really part of the product starting in SharePoint 2013.

So, article done – out-of-the-box first, then only if that is not possible – custom code. But wait, there’s more to this story. What is custom code in SharePoint? Is it server side code, client side code, WebPart development, Add-Ins? Oh my, so much to choose from. How do I make the right decisions?

Before I start preaching my thoughts on this subject, let’s take a step back. I started SharePoint in 2001. The first thing I did was a custom site. Custom design, custom functionality. The client asked me to. Nobody really knew SharePoint at that time. So, I went into the “hive” and started messing with files. Oops. They sure had a problem when they went to upgrade to 2003. So, I learned best practices for SharePoint Development. I learned solutions, manifest files and all sorts of good information. In 2003 I was using Visual Studio plugins from CodePlex to deploy SharePoint solutions. I even wrote some very populate blogs on that subject. That lasted through 2007. In 2010 Microsoft finally started integrating SharePoint development into Visual Studio. I was a happy camper. No more third party plugins. My techniques are now legit.

Then SharePoint 2013 rolls-out (more importantly – Office 365 becomes big). Microsoft has this new technique – SharePoint Apps (I mean SharePoint Add-Ins – don’t you hate it when they change the name on us?) This is new I think. Development is not happening on the SharePoint Server anymore. In the Provider Hosted Add-In model development happens on a separate web server and oAuth connects it to SharePoint. In the SharePoint Hosted model development happens through client side code in a different web application within the SharePoint Farm – still means it’s not happening on the actual SharePoint Server because it’s client side code (that happens on the users browser). This changes my thinking. At first I am mad – how can Microsoft do this? This is horrible. We won’t be able to do anything anymore. So, what do I do – I learn it and embrace it. Our company even won a contest in it – the first annual Microsoft App Development contest. Pretty proud of that I might say.

OK, choices, choices, choices – if we are in an on-premises SharePoint environment then we can still do custom server side coding or we can use the Add-In model (Provider hosted or SharePoint hosted). If we are using Office 365, then we can use the Add-In model only (Provider hosted or SharePoint hosted).

Let’s talk about on-premises Server Side coding first (old school). This still has merit. There are just some things you can’t do with the Add-In model. For instance: a real WebPart. Sure, the Add-In model has the “App Part”. But, that’s just a fancy iFrame. Very limiting in certain situations. If you really want a reusable WebPart across multiple sites that acts the same, sizes appropriately, yada, yada – a true WebPart is the only way to go. The issue is – I rarely see business requirements for reusable WebParts. Usually it’s something you build once, for one site. A WebPart is not needed. So, think about that before you build a server side WebPart – are you going to reuse it over and over again?

Ok, now we’ve decided we don’t need a reusable WebPart. Is the server side coding still an option if I am on-premises? Sure. Sometimes you need complicated server side logic that a browser just can’t support. For example: the other day we needed to generate an Excel file for the user based on an action. I’d like to see you do that client side. So, your only two options (that I know of) is to do server side code or the Provider Hosted Add-In model where the code is actually running on a different server (yes, before you smarty pants comment on this, I realize there are some other approaches – web services, etc.. But, you get the point – code on a server is needed somewhere). But, maybe your client doesn’t have a different server to run the Provider Hosted model on. Now you have no choice but to do it using the server side model. So, reason 2 for using Server Side code – you need to do something that can only be handled (or is more performant) when done on a server and the Provider Hosted model is not an option.

Now we get to the new Add-In model of SharePoint. If you are Office 365 – you could have just skipped over my on-premises section and jumped right to this. It is your only choice because you don’t have access to the servers. But, if you are on-premises, these options might be good for you too.

The SharePoint Hosted model is simple – it’s JavaScript using the JSOM (JavaScript Object Model) of SharePoint. JSOM is pretty powerful. You’d be surprised how much you can do with it. I’ve been able to complete most of the tasks I regularly have with JSOM. So, don’t let the model keep you away from this option. The biggest issue with this option is that it’s JavaScript. I LOVE JavaScript. I’ve been a proponent of it for a very long time (before it was cool). I use to take heat in SharePoint Saturday’s from the other presenters about it. I am happy to say – I was right. All SharePoint devs are getting into JavaScript now. It is the future. The browsers have caught up. And, Microsoft is pushing it. The problem with JavaScript is that it’s hard to do correct. One mistake and the page might not load. One mistake and the page could be super slow. You have to consider performance, page load, asynchronous calls, etc., etc. when making this decision. The better your devs are at JavaScript, the less likely you have issues. But, it’s no guarantee. Just the other day I built an internal timesheet application for our company using the SharePoint Hosted model. I am now re-writing it in the Provider Hosted model. Why? Loads a little slow – but, I can fix that. The bigger issue is security. I need a server layer to beef up security. I thought long and hard and realized the Provider Hosted model is better for this particular situation.

OK, we are down to the Provider Hosted model. Now we are talking about setting up a different web server. Us .Net developers usually use IIS. But, I even have a client doing Java development for this. It is possible. The point is – we need another server. If you are lucky enough to get Azure (or another cloud provider) – this is no problem. If you are lucky enough to have an easy, internal virtual environment – this is no problem. But, if you are a Government or large business contractor like me – this can be a problem. So many rules to get a new server. So many hoops to jump through. Is it worth it? Let’s just say it is – now you have to let the SharePoint environment know about the new server. There are certificates for that. But, more often people use Secret Keys. Did you know those expire eventually? I didn’t for the first client I set this up for. Wow, it was a surprise when my site went down exactly 1 year after we implemented. Now I know to put a calendar reminder in for all the Provider Hosted Add-Ins I build. My point is Provider Hosted Add-Ins probably work and make a lot of sense. But, are they more hassle then they are worth?

I have found that both Add-In models are good for resusability. Building something once and reusing it on a separate site. Or, building something to sell on the Office Store – reusing it across multiple farms. But, when building something for a single, internal page – they can be more hassle than they are worth.

OK, have I lost you yet? Point is – all of these techniques come down to one thing – reusability and custom code. I see companies jumping to the conclusion of one of these models so much when they don’t have a reusability requirement. Let’s say I was tasked to build a single webpage for a client (this is typically the kind of requests we get – they might call it a single application). Then lets say I determine I should use the SharePoint hosted model because one part of that page needs to be custom code. The question is why? Let me explain…

I’ve come to the conclusion that if you don’t have a reusability requirement and you don’t have a server side development requirement, then none of the above models are the way to go. It is so much easier to piece a page together. What do I mean by that? First off – remember – we tell our clients “out-of-the-box first.” So, let’s embrace that mantra. Let’s use out-of-the-box when we can. If you are building a page with three separate functionalities on it – try to use out-of-the-box when you can. Maybe 2 of the 3 can be done with out-of-the-box and a little custom styling. So, now you have one component left – let’s just write the JavaScript, using JSOM, directly in a Script Editor WebPart or at least point a Script Editor WebPart to our file. Or, let’s even get more advanced and use something like the SharePoint Wrangler http://bob1german.com/2016/01/13/flexible-sharepoint-development-with-widget-wrangler/.

Point is – we have options. The frameworks Microsoft put together for us are for large efforts. But, typically we build pages and single applications for clients. Think through what you are doing when you make the choice. Don’t overdue it. Plan for the future. Make things simple for yourself.

I am sure there are people that can poke holes in my argument. I even can in theory. For example: I love the idea of a Provider Hosted Add-In. Strip out all that nasty SharePoint stuff. Start with a clean slate. Maybe even use the newest and greatest framework like Angular or Ember. But, in practice I am not finding this scalable and maintainable. Secret keys expire. Lots of redirects happening behind the scenes. Reliant on multiple servers to stay up and running. Sometimes the easiest answer is the best. And, if you are already committed to using SharePoint, let’s use the product and weave in custom code slowly, through the client side, in the SharePoint page itself.

My name is Greg Galipeau. This is my new mantra and I am sticking with it until I see a better way (in practice – not in theory)!