The Future of Client Side Development in SharePoint and Office 365

Home » SharePoint Development » The Future of Client Side Development in SharePoint and Office 365

The Future of Client Side Development in SharePoint and Office 365

Posted on

Ther​e is a lot of discussion lately in the SharePoint community regarding the future of pure client-side applications (meaning those comprised entirely of HTML and JavaScript). Most of the posts I see are negative, with complaints centered around the lack of compiled code, complexity of app webs, perceived security weaknesses and inability to support forms-based authentication. Many of the detractors would have you believe that client-side applications, and specifically SharePoint Hosted apps, have no place in the enterprise and a limited future in both SharePoint and Office 365. But these complaints ignore some of the very significant advantages of client solutions and the benefits they offer developers. They also fail to account for the fact that SharePoint Hosted apps, like Sandbox Solutions before them, already have a supported lifecycle well into the 2016 release and beyond, meaning tens of thousands of SharePoint customers can and will continue to use them for the foreseeable future. But beyond that, the client solution model is at the core of every new API Microsoft is releasing in both the Azure and SharePoint space. It even forms the backbone of important applications like Visual Studio Code, the Azure portal, the Napa development toolset and many of the mobile app​​lications that Microsoft has recently released.

So on the one hand we have an admittedly less-than-ideal client solution model in SharePoint Hosted Apps but an incredibly robust set of web, mobile and even enterprise applications that use the same fundamental framework. Microsoft has made it clear that their preferred route is legacy .NET applications running on IIS outside of the SharePoint framework entirely, which makes sense considering the company wants to sell as many Windows server licenses as they possibly can. But is that approach realistic in light of the fact that the entire web is moving in the opposite direction? Are we once again going to be put in a position where SharePoint is years behind every other technology on the market (remember having to suffer through .NET 2.0 when 3.5 was already in widespread use everywhere else)? And just what is it that so many people, including those within Microsoft, seem to have against pure client-side applications? 

I’ve collected a few of the most common complaints I hear when speaking to developers about the App/Add-In model. Naturally, most of them come from existing SharePoint and .NET developers, who have a vested interest in the status quo of compiled server-side code, but I’ve even heard a few from so-called “architects”, IT professionals, system administrators, and developers transitioning from other platforms.  These are my thoughts on the subject, which will most likely generate some controversy, so feel free to add your own perspective in the comments and tell me why you think I’m right, wrong, or missing the point entirely.  

JavaScript Isn’t a “Real” Programming Language

This objection seems to be at the core of almost every complaint regarding client solutions. SharePoint hosted apps (SHA’s) by design don’t permit compiled code – that means no ASP.NET, no WebAPI, no classic MVC, no Java and so on. Proponents of Provider-Hosted Apps (PHA’s) are quite adamant that unless the code can compile then it IS a pile – of junk. They actually have a point in that JavaScript was never meant to be used the way it is being used today. Brendan Eich certainly never envisioned things like jQuery, AngularJS and Knockout when he cobbled to together the underpinnings of a simple browser-based scripting language. It doesn’t compile. It’s not strongly typed. It’s hard to debug. It doesn’t handle advanced (ok, even simple) math operations. You can’t create proper classes, namespaces and inheritance. All true (for now – ECMAScript 6 will change much of that). But guess what? NONE OF THAT MATTERS. It’s 2015 and the world runs on JavaScript. If you are clinging to ASP.NET MVC and Java the world has already passed you by. Is that to say server-side code no longer has a place? Of course not – it has a very valid place as the backbone of web services that actually make all that web and mobile front end goo work. But it’s not how front ends are written anymore and it’s not what user’s expect (when was the last time you encountered a postback from changing a value in a drop-down list?).

People can argue that real enterprise applications don’t run on JavaScript and they may have had a valid point a year or two ago. But that is rapidly changing. JavaScript is at or near the top of employer demand in every staffing survey. In Silicon Valley nearly everything runs on JavaScript and all of the various frameworks that support it. Google is a JavaScript machine and has thrown their support behind TypeScript, an abstraction framework (created by Microsoft, no less) that makes writing JavaScript much more akin to object-oriented programming. Angular 2.0, which is quite an important initiative for Google, is based on TypeScript.  The JavaScript train is gaining momentum and steamrolling everything in its path – already Angular is rocketing to the top of the GitHub and StackOverflow charts, running just barely behind ASP.NET and Ruby. It’s getting harder and harder to find a job without knowing at least one of the popular JavaScript frameworks. And some of these frameworks – like Node.js, Angular.js and React.js – are really, really good.

In the SharePoint world we have long been insulated from what is happening “on the outside”. We’ve traditionally lagged behind even the latest ASP.NET releases by at least one major version. With it’s heavyweight ASP.NET underpinnings and extensive server-side API SharePoint forced us to write compiled code if we wanted to get anything done. But all that is changing. The JSOM and REST API’s in SharePoint 2013 and Office 365 are iterating rapidly, delivering more and more functionality with every monthly release and quarterly update. Combined with advancements in the Azure space like the ADAL.JS libraries we can actually write end-to-end applications without ever clicking “build” in Visual Studio. The rest of the world has already moved solidly in this direction – you cannot argue with a straight face that sites like Facebook, Twitter, YouTube, The Weather Channel, Quickbooks Online and hundreds if not thousands of others are not “real” applications. Not to mention many popular mobile applications that have millions of daily users. And with the introduction of new ECMAScript features like classes, modules, and native promises, many of the old complaints about JavaScript fall to the wayside.

Sorry, folks – JavaScript is real, it’s in the enterprise and it’s here to stay. As a classic server-side developer I may not like it any more than you do but it’s long past time to get over it and get on with it.

SharePoint Hosted Apps Aren’t Secure

Complaints regarding app security are really complaints about OAuth, which replaces the tried-and-true method of every app having distinct authentication with a token-based authorization scheme designed to operate – sacre bleu! – over HTTP. Is this scheme inherently secure? Of course not! It’s susceptible to all kinds of attack vectors, from Man in the Middle, to Session Fixation, Covert Redirects and more. All those tokens flying around are just begging to be hijacked and exploited.

But guess what? None of that makes any difference. All – and I do mean ALL – of the major web players have embraced OAuth as the de facto standard for interoperability. So it doesn’t really matter that it’s inherently insecure or susceptible to exploits because everyone is using it and will continue to use it until something else comes along. For years Microsoft has forged their own path in the web standards world, going it alone even when they were sometimes in the right, and they’ve been marginalized in the greater web development community for it. They have now, wisely, chosen to change their ways and go along with what everyone else is doing. That means if you’ve written apps that integrate with Facebook or Twitter you know pretty much all you need to know to write Office 365 and SharePoint apps. That’s a win for Microsoft no matter how you look at it.

Besides, those who proclaim that SHA’s are any less secure than PHA’s are dangling a massive red herring. Guess what PHA’s use for authorization? That’s right – OAuth. There’s really no difference between authorization token requests made via an HTTPWebRequest method in C# and those made from JavaScript via AJAX – the POST operation looks the same to anyone sniffing the wire. You could argue that calling a compiled web service from JavaScript and letting the web service handle token management is a better approach but since there are no credentials being passed either way, it’s really a distinction without a difference; once the client is compromised, an attacker can keep making authorization requests to the web service and collect the returned data, which is the only thing they can do if they manage to hijack the authorization process anyway. The only real difference between SHA’s and PHA’s when it comes to OAuth is the inability to explicitly establish client context – in an SHA it’s inherited from the current HTTP context whereas PHA’s go through a token exchange process to obtain the requisite context object. But this doesn’t make an SHA any less secure; in fact, the end result is exactly the same.

One thing the detractors of SHA’s often forget is that from the customer’s perspective an SHA is actually MORE secure because it runs inside of their SharePoint environment (or Microsoft’s, in the case of Office 365) and they don’t have to worry about a third-party vendor’s servers being compromised. Is this more perception than reality? Certainly. But that doesn’t change the fact that each add-in the customer installs increases their risk profile because it explicitly allows a third-party access to sensitive company data. But don’t take my word for it – sit down with a Chief Information Security Officer and tell them you are going to permit vendors to copy company data to their servers with the only barrier being a single “Trust It” button clicked by a site administrator and see what they say (it’s worth it just to watch their face turn purple). Just because an app vendor tells you they aren’t copying your data who is to say that’s the truth? Every PHA that runs on a server not owned by the company is acting with full permissions on behalf of the user or as agreed upon by the site admin; you may think all is well because your users are happily clicking away on that fancy CRM add-in but behind the scenes it’s downloading every document in every library in the site and storing it away on somebody else’s servers. And you’ll never know it’s happening because it’s all being done outside your firewall; even worse, you blindly accepted a set of generic permission statements so you gave the vendor permission to do it! Could this also happen in an SHA? Potentially, yes, but the data can’t be stored in the SHA itself so the perceived risk is much  lower (the app could, of course, just upload the data to a remote endpoint from the client). Remember, there is no cloud – it’s just somebody else’s computer and one little click can give them the keys to your kingdom. 

The App Web Concept is Terrible

On this one we can all agree. App webs ARE terrible. They make lifecycle management a nightmare because developers cannot predict the URL of each app across farms or even across multiple deployments in the same farm. Users don’t understand them because they kind of look like a regular site but they really aren’t. A nonsensical proxy method is required just to communicate with the host web, which is where we all want to provision assets in the first place. And configuration makes IT Pros gnash their teeth dealing with wildcard certificates and DNS. They really, really suck. And don’t get me started on app parts because those are even worse. But that’s what we have to work with so until the situation changes there’s no point in getting all worked up over it. 

It’s no secret that a lot of people, including many within Microsoft, would like to see the app web concept – and SHA’s along with it – go the way of Sandbox Solutions (which, when you really think about, is all the app web concept really is: Sandbox 2.0).  There’s a reason nearly every sample in the Office Dev PnP GitHub repo is a PHA even though most of them don’t require any PHA-only features like remote event receivers; however, PHA’s also require an app web if they want to communicate with the host web in any way so this problem isn’t applicable only to SHA’s. I’ll agree with half of the sentiment, that app webs do need to go away. Like, right now. Today. But just scrapping them altogether doesn’t actually solve any problems. In many (actually, most) enterprises it is very difficult to get a web server provisioned. It requires numerous approvals, business justifications, allocation of scarce resources, etc. And before you say it, no, Azure is NOT the answer. Business units and IT shops can not increase costs from a usage-based resource any easier than they can spin up a new virtual machine. Just because an EA has Azure on it doesn’t magically transform compute units into freely available (or free) resources. Those costs have to be justified and applied to a cost-center; they are coming out of somebody’s budget somewhere and whomever holds the purse strings has to approve the spend. Besides, the customer bought SharePoint in the first place so they wouldn’t have these kinds of problems. Force them into spinning up a bunch of web servers alongside it and they’ll just go back to Full Trust Solutions. Guaranteed.

SharePoint Hosted Apps Don’t Support Forms Based Authentication

Very true. SHA’s and FBA don’t play nice together. But, when you stop and think about it, PHA’s don’t actually support FBA, either. You can create a PHA that uses FBA but it’s not the same credential that’s coming from SharePoint. There is no true single sign-on for apps unless you are building Azure web applications. So even if the user can login to SharePoint via FBA they still have to log into your app separately. Which doesn’t actually achieve anything since OAuth is required to communicate back to SharePoint. So the reality is that apps don’t support FBA period. The only difference is one of perception – the user thinks FBA works because they log into SharePoint once and get redirected to a PHA that uses OAuth behind the scenes to establish context. An SHA, because it runs on a separate web application, hits them with another login prompt so it appears not to work with FBA. But apply forms auth to the PHA and the user gets the same result. What is really needed is for Microsoft to fix the FBA problem altogether instead of developers fooling users into thinking something works when it really doesn’t.

I’m sure there are other arguments that people can raise against SharePoint Hosted Apps but those are the ones I hear most often. Now let’s move on to some of the positives, shall we?

Ease of Deployment

There is no denying the reality that SHA’s are so much easier to deploy than PHA’s, especially on-premise. Add the app, trust it, and you’re done. No certificate issues (well, no additional certificate issues, anyhow). No Client ID’s, Secrets and hidden expiration events. No PowerShell scripts with arcane TrustedSecurityTokenIssuer commands. No vendor servers and uncomfortable conversations with InfoSec. And despite the fact that they run inside of SharePoint, no WSP’s or IISRESET operations. 

It. Just. Works.

That’s not to say SHA deployment is perfect. Iterative deployments can wipe out configuration settings in the app web. That can be a real pain. And there just isn’t any effective way to perform automated deployments via a build server. Another bummer. Finally, modifications require re-provisioning of the app, a real downer if you are an ISV shipping frequent updates. All this is true. But there are some ways to mitigate these limitations. Configuration settings can be stored in the host web or a web service. Core JavaScript and resource files can be hosted in a private CDN or globally accessible location for ALM, with minimal markup in deployed HTML files to reduce update frequency. 

Most importantly, SHA’s don’t require any additional infrastructure. There is no need to request a new web server or justify additional cloud compute expenditures. They run where SharePoint stuff should run – in SharePoint (what a concept!). You can leave your resources free for those apps that actually need their own servers and which shouldn’t ever have been deployed to SharePoint in the first place. And you never need to have this ridiculous conversation:

     DEVELOPER: “We need to deploy a solution for SharePoint branding.”

     IT MANAGER: “Ok. Schedule a maintenance window and do it.”

     DEVELOPER: “Um, we need to provision a web server for our solution.”

     IT MANAGER: “What? Why? Can’t you just deploy the WSP via PowerShell?”

     DEVELOPER: “Well, Microsoft says we shouldn’t do that anymore and instead we should be building provider hosted apps now which don’t run in SharePoint. So we need a separate web server.”

     IT MANAGER: “Let me get this straight. You need to stand up a web site in order to apply branding to another web site?”

     DEVELOPER: “Um, yeah. And we also aren’t supposed to modify master pages so we have to do JavaScript injection. And, um, if a site admin removes the app the JavaScript modifications get orphaned and we have to redeploy the app in order to run our custom code to remove them.”

     IT MANAGER: “Come back to me when you have a WSP.”

Modern App Development

SHA’s run on JavaScript just like pretty much everything on the web these days (as can a PHA if you build it properly but – seriously, but – refer to my previous point). You can build them with whatever framework you fancy – Knockout, Angular, React, Breeze, it’s up to you. There are no restrictions on external web service calls like there were in the Sandbox so they can communicate with server-side endpoints hosted anywhere on any platform. There are an endless number of IDE’s for JavaScript development, from the venerable but eminently capable Visual Studio, to WebStorm, Eclipse, Sublime, and even good ol’ Notepad. And most of them run on platforms other than Windows. Microsoft even has their own play in the cross-platform segment with Visual Studio Code. If you really want to go whole hog, you can even run your server-side services on JavaScript with Node.js (which seems completely ridiculous to me, by the way – why rewrite yourself what Apache, IIS and other web servers already do very well?). 

Even better, the code you write for your SharePoint add-in can be virtually the same as what you write for that fancy mobile app that’s going to take the world by storm one of these days (as soon as you get around to writing it, of course). Have an existing mobile app that is mostly an HTML + JS front end that talks to a set of distributed web services (perhaps even running Azure)? Put it on a web server, code up a quick App solution and it runs with minimal modification as an App Part in an Office 365 site. Boom! Mic drop. 

Or, you can fire up Visual Studio and keep cranking out big, heavyweight ASP.NET applications that don’t run anywhere but on IIS and will never become mobile (or modern, for that matter). Sure, they are familiar and lots of organizations still use them but that’s not the direction the rest of the world is moving in. Even the tried and true MVC stack is becoming more JavaScript friendly with native support for Angular and other JS frameworks, along with UI methodologies like Bootstrap which is specifically designed for modern apps. We can never really know what the future might bring, and JS frameworks are notorious for not lasting any longer than a Dallas Cowboys playoff run, but what is clear is that we won’t be going back to heavy server-side code and postbacks ever again.

Availability of Resources

Just about every web developer nowadays knows at least one JavaScript framework, even if it’s only jQuery. They also know how to create and exchange data with RESTful services. Translating JSON into model objects and binding them to the UI via a ViewModel is second nature to them. The only thing they don’t know how to do is deal with the weirdness of SharePoint. That’s where we come in, all of us SP coders who have been mind-melding with the big black box for the last decade. We can show them how to turn their code into an add-in, how to get data from a list (what do you mean the field name needs to have “_x0020_” in it?), what a site collection is (wait, wait – tell me again: what’s the difference between a site and a web?), and so on. One senior SharePoint dev and a team of good JavaScript coders can crank out some seriously cool apps in far less time than it takes to get .NET web form developers to understand web parts and application pages. 

For companies trying to manage an ever-shrinking IT personnel budget (which is pretty much every organization on the planet) this is a huge boon. For years the biggest complaint about SharePoint development has been the inability to find people who actually know what they are doing. With apps, especially SHA’s, that’s no longer such a huge concern. Sure, you still need some quality SharePoint devs to lead the charge but you can now pair them up with web and mobile devs and watch the semi-colons fly about in a swarm of productivity.

Does this mean, as is often claimed, that Full Trust solutions are dead? Heavens no. Not by a long shot. On-premise SharePoint development still requires proper compiled solutions for implementing serious customizations. There just isn’t any real replacement for timer jobs, feature receivers, web parts and web templates in a real-world SharePoint deployment. But apps give you options, like not having to completely rewrite a web application as a set of application pages and web parts. Instead, that web app can continue to stand alone but gain some nice hooks into the company’s Intranet, such as remote data integration and ribbon integration. 

[It’s worth sounding a bit of an alarm on this subject before anyone gets the impression that it’s all wine and roses on the other side of the Golden Gate bridge. Most JavaScript developers have no idea how to produce quality, manageable, supportable code with real lifecycle management. The senior developer skills that result in code running mission-critical things like nuclear reactors and aircraft are almost completely lacking in the “modern app” space. This has to change and change fast – all this client-side goodness will crumble to dust if we don’t get some adults in the room to show the hipsters why grey hair matters. That’s why I’d personally like to see a lot of classic .NET developers move over to the client-side space so they can show the youngsters some proper development techniques.]

So what’s the takeaway from all this? From this developer’s perspective, client-side SharePoint Hosted Apps play a vitally important role in SharePoint and Office 365 extensibility. They are modern, easy to deploy, require less infrastructure and fewer scarce personnel resources. Are they perfect? Nope, there are important security concerns and the product engineering team really needs to come up with a better solution for hosting them than the app web concept and find a way to implement PHA-only features like remote event receivers. But in my opinion the advantages (or potential advantages) outweigh the drawbacks. The deployment story alone is enough to proclaim them superior to Provider Hosted Apps for on-premise and hybrid environments in my opinion. I’m sure many people will disagree with me on this but if you find yourself coming down on my side of the argument then you need to make your voice heard to the powers that be inside Microsoft lest they really do become the next version of the Sandbox and suffer a similar fate.