SP2013: apps versus sandbox
Hi SharePoint friends! It’s been a while. The last few months I was changing jobs (more about that in a seperate blog post) and taking vacation. Just before that, Microsoft released the first bits of SharePoint 2013. As is the case with 2010; this new version comes in two flavours: an on-premise installed version for which you need a server, and an online hosted version within Office 365, which is offered as a service. As we developer have become used to: development options differ.
I’ll leave the normal solution building to what is was for now, since that’s not the most eyecatching change. Then what IS, you ask? Apps! Since a few years, the terms “apps” is hot and happening, so Microsoft decided SharePoint and Office needed apps too. And they we’re probably right.
So, what exactly is a SharePoint 2013 app? I’m not sure if there’s an official definition out there somewhere, but here’s my view. An app for SharePoint is a solution (collection of files) which is meant to run client side; in the users browser. You cannot deploy server side code like codebehind, webservices, that kind of stuff. Where a sandboxed solution let’s you use a limited part of the server object model, an app only allows you to use the client side bits (i.e. the JavaScript ECMA model).
Update! There seems to be somewhat of a definition (found here): “So what’s an app? It’s best described as a solution that carries a light footprint and uses standards-based technologies such as HTML5, JavaScript, and OAuth.”
My initial response was: why would you want to build a solution with even less options as opposed to a sandboxed solution (which is already pretty limited and thefeore sometimes pretty annoying)? But after thinking about it twice, it might be even better than sandboxed solutions because of the extra limitations. I’ll try to explain why.
If you’ve ever tried developing solutions for Office 365 / SharePoint online, you know the limitations of the object model in the sandbox. Especially when you’re used to building “normal” onpremise farm solutions, these limitations are sometimes frustrating. You’re used to solving problems in a certain way and suddenly Microsoft decides your way of working isn’t going to work any longer. You need to find other ways of doing the same (which feels like a workaround to you), which takes time and learning. So a task which you already knew how to implement in a normal solution suddenly takes more time to build for the sandbox.
Because an app is fundamentally different, it doesn’t resemble a standard solution. The way of creating one is different, the goals are probably different, the tools are different (ok, you can also use Visual Studio of course). Being forced to use the client side bits, you start solving problems in a completely different way instead of using your standard object model knowledge. That’s a good thing.
Because of the client side, disconnected nature of apps, you’re forced to implement asynchronousity in a proper way. I don’t like doing async stuff in JavaScript (scripts easily get bloated and unreadable), so for Sandboxed solutions I tended to just write some server side code for stuff which I probably should have better handled client side instead. I still don’t like async stuff, but now I’m forced to do it and I’m forced to do it in a proper way if I want to remain writing maintainable code. The skillset for writing apps differs from my current skillset. So I need to learn how to do it properly using JavaScript. And was about time I did 🙂
I’m not sure yet how much time I’m going to be able to put into SharePoint 2013 the coming months. But I’ll definitely share some insights and hopefully code here. Towards the end of November I’ll be attending the Dutch SharePoint conference, which will probably feature a lot of SharePoint 2013 content. So stay tuned; there’s more to come!
Leave a Comment