We SharePoint developers have had a bit of a hard time. The administrators don’t like us because our solutions can be complicated to deploy and we get blamed for bringing down the farm (sometimes with justification). Our managers don’t like us because we are more expensive than ASP.NET developers. Our product owners don’t like us because their favourite wish list item doesn’t really fit in with the way SharePoint does things. And the users don’t like us because, well, they’re just never happy. And now it feels as though Microsoft doesn’t like us either!

Why else would they come up with sandbox solutions to constrain us, and then kick us off the server completely with the SharePoint App model of development? Anyone would think they didn’t want us to build custom solutions on top of SharePoint.

But when you calm down and disregard the years of accumulated frustration, it does start to make some sense. When SharePoint became a serious development platform with the MOSS 2007 release the essential unit of customization was the web part. The idea was that we would build custom components of functionality that could be combined by end users or power users in composed pages to make a web application, adding, moving, configuring and connecting the component web parts like Lego™ bricks. It was an elegant solution to building websites that users could adapt to their needs, although we weren’t always successful in communicating this elegance to our users. And fundamentally this is server-side technology based on ASP.NET Forms.

Come to the Client Side (we have cookies)

But in recent years the rest of the web industry has moved to more of a client-side model based on AJAX and now accelerated by the rapid adoption of HTML5 and CSS3, along with a visually simpler page structure which users perceive as “Web 2.0” (whatever that means). The work happens on the client in ever-more-sophisticated JavaScript, and pulls in data on demand, possibly from several different web services. For example we might have a Twitter feed or Facebook data on the page.
When you start to think about SharePoint in the same way, as just a web service to be consumed, then the SharePoint-hosted App model starts to make a lot of sense. We wouldn’t expect Twitter or Facebook to let us install our code on their servers, for example. But it means we have to start thinking differently. If we look at our existing SharePoint farm solutions and try to map each component, each web part to an App Part, and try to move piecemeal to the client it probably isn’t going to be very satisfactory. We need to think in terms of re-packaging that functionality as a single application that runs on the client, and make use of the rich tools and frameworks that are available for JavaScript. That client-side application takes responsibility for pulling data from SharePoint, probably asynchronously on demand, and manipulating it and caching it locally. We need to stop thinking of JavaScript as somehow part of a “no code” solution and treat it as a first class programming language, and learn how to use it properly [1]. Sorry, but we do.

Cloud-hosted Apps for SharePoint

Of course there was always more to SharePoint development than web parts and page rendering. There are the timer jobs and custom workflows and event receivers. How to do that without running code on the server? Microsoft has come up with a solution to this which is the Cloud-hosted App model. Your code will still run on the server; just not the SharePoint server. That server might be truly in the cloud using an automatically provisioned Azure service (auto-hosted), or it could be an on premise or cloud server running any technology you choose (provider hosted). While the SharePoint-hosted model seems like a continuation of the process of moving more code from the server to the client, seeing your way around the cloud-hosted version takes a bit more work. Actually a lot more work, because now we have another server to scale and make resilient and fault tolerant, in addition to a fairly complex story around security. Right now it seems like a lot of effort to build working applications using the cloud-hosted model, and where possible I am inclined to wait until the model becomes a little more mature and some best practices have emerged. This is an area where a lot of us will probably continue using farm solutions for some time.

Time for some REST

If we are going to continue to use our server-side development skills, and also dive head-first into the world of client-side development, we’re going to have to be a bit selective in our choice of technologies. We can’t learn everything, and there just seems to be too much with the Client-side Object Model for C# and another one for JavaScript. Then there is the REST interface and a choice between XML/Atom and JSON. My view is that REST and JSON offer the biggest scope for re-use across different platforms, and that is my preferred technology at the expense of CSOM. Although CSOM/JSOM (with an ‘M’) is initially attractive in that it seems to resemble the server-side object model, it really isn’t that similar, and in addition there are limitations about where you can use it. I want something I can re-use in web development, Windows 8, Windows Phone and potentially iOS and Android, and that I can also use against endpoints other than SharePoint. REST is also easy to use and can be tested using nothing more than a browser. There are still a few things CSOM can do that are not supported by the REST interface but I believe that Microsoft will close the gaps.

The App Store Story

SharePoint on the Move

By the time of the European SharePoint Conference in May 2014 the majority of global users of the Internet will be using mobile devices (i.e. phones and tablets) as opposed to desktop computers, according to Morgan Stanley. In the future we will be using mobile devices to access SharePoint data and that probably means that we will be building mobile apps to do this, because this is what users of mobile devices expect. Responsive design is a step in the right direction but what users really want is an app. A rather convenient by-product of the introduction of SharePoint Apps is that the new REST services in SharePoint 2013 have suddenly made mobile app development a lot easier. I think mobile apps for SharePoint are going to become increasingly important over the next few years. And that is why I am very excited to be talking about “Delivering SharePoint to Portable Devices with Mobile Apps” at the European SharePoint Conference.
I hope to see you there!

References

A couple of slim volumes to get you started on the path to the client-side:
[1] JavaScript: The Good Parts, Douglas Crockford
[2] SharePoint 2013 App Development, Scot Hillier and Ted Pattison

If you have any questions or feedback on Bill’s article please leave a comment below. We would love to hear from you.

Bill Ayers

Bill Ayers is a consultant developer and software architect who has been working on SharePoint since the 2003 version of the product, and is a Microsoft Certified Master and MCSM, SharePoint. He specializes in web content management and Intranet portals. He has over 20 years’ experience in the software industry, and speaks regularly at international conferences and user groups. He is also a moderator on SharePoint.StackExchange.com, and blogs at http://SPDoctor.net/ and can be followed on Twitter @SPDoctor.