Friday 1 November 2013

Where is MS taking SharePoint Development

The communities reaction to the app model for SharePoint 2013 has been interesting over the past year.  Please post your thoughts!

I got this email recently:
"I've been doing some 2013 development using the traditional farm solution approach.  using c# code behind. I think that this is the way most SP2013 projects will be developed. Why? because 99.9% of SharePoint developers know how to do it this way and that's everyone's skill set. I think Apps will be used when the clients requirements need functionality that needs to be isolated. You can't communicate cleanly between apps. I also think that using an Agile approach to development that is app based solution is dangerous in that the client nearly always changes the requirements. That could mean a complete rewrite of the App or change approach. Not good for consultancies who never give you enough time anyway."

My reply:
Using the SharePoint App model for development has no integration or ALM capabilities so it is fine for building little bits of functionality or for companies providing generic apps for say a generic intratent.  The 3 models have difference strengths, the best generally is the provider hosted and I feel this is not SharePoint but external development that I merely surface in SP.

Building complex system in SharePoint has been hugely successful and has great folks that can bend SharePoint, the app model has it's place but I don't see it replacing proper business solutions delivered thru SP.

Another person was complaining to me recently along the lines of "even if you know JS and the provider models it takes 5 times as long to develop functionality that using the solution approach."

Bill Ayers Provided a nice session on The Good the bad and the Ugly of the App Model for SharePoint.  He has a video that is hillarious.

 

7 comments:

David Lozzi said...

Hi Paul,

Thanks for the post. I too have been observing the landscape, rather the development-scape, around SP2013 Apps. Us seasoned SP developers using trusty C# can definitely have a huge question mark looking at this. I wrote my first app, it took much longer than busting it out in C# (but had to do it in the App model). It's been a few months and now I prefer a quick little SharePoint hosted app over a farm solution. Making my own JS libraries and cheats helps me pump out a functional app or POC in a day or two. Not too shabby. I lean towards trying to use an App over a farm solution, unless of course it's impossible (there are loads of things an App can't be used for).

There is a learning curve for sure, but once you get your head around the nuances of JS, and the API, it's a breeze.

Thanks,
Lozzi

Paul Beck said...

Great feedback Lozzi - so their is hope for me to be a convert to the app model!

Unknown said...

Great Post, I am sure it is reflecting the thoughts of many of us involved in SharePoint. I understand the reason for the App Model, I am currently working on an SP Online project. However, the whole (app model) thing just feels like a work around, that to be honest does not do a great job at "working around". I agree that you can do many tasks in an app. However, half the time it is better to use a Script Editor web part and just dump the code in, instead of building apps.

Paul, I am not sure that I will be the one to make an "App Model Convert" of you.

Cheers.. Mark

Unknown said...

Great Post, I am sure it is reflecting the thoughts of many of us involved in SharePoint. I understand the reason for the App Model, I am currently working on an SP Online project. However, the whole (app model) thing just feels like a work around, that to be honest does not do a great job at "working around". I agree that you can do many tasks in an app. However, half the time it is better to use a Script Editor web part and just dump the code in, instead of building apps.

Paul, I am not sure that I will be the one to make an "App Model Convert" of you.

Cheers.. Mark

Unknown said...

Hi Paul,

I can understand why MS is pushing the app model, and in principle I agree with the approach. By moving all custom code outside of SharePoint, the reliability and stability of the core platform is greatly improved. In a multi-tenant environment such as SharePoint Online you cannot afford the risk of custom code (even in the sandbox) from one tenant affecting the performance of others. Even in an on-premises scenario it reduces the risk of custom code having system-wide negative impact. There are still many scenarios where apps cannot provide the required functionality, but where it is possible I would advocate trying to use it as a first choice. I am sure over time the scenarios where farm solutions with full trust code is required will be reduced as the product develops.

I agree that the first few projects using the app model might be painful. But after building up a base of samples and tools the process becomes a lot simpler. If you really want to use c# you can still use it with CSOM in provider- or auto-hosted apps, but I would personally prefer the javascript route.

End-users expect slick and compelling UIs these days. Investing in building up the capability and a quickstart code base to use good javascript databinding and templating frameworks with the SharePoint app model will pay off in the long run. I also think there might be value in investigating how to combine typescript, TFS build and a javascript testing framework to improve the development lifecycle.

Paul Beck said...

Hi Conrad,

I agree with you point on stability of the farms, adding compiled code can and will make large farms creak. There are different approaches to build solutions and I suppose I tend to lean towards what I am most comfortable using.

Building complicated apps is going to be a tough skill set to find folks, they need to know SP, CSOM/JS, REST, OAuth/App model. Then to do "good" development practices we need to throw on TypeScript/Js testing framework and hook it into a TFS build. I feel to find high quality resources and the setup / learning curve it is going to be prohibitively expensive on large projects. It this approach does work some folks are going do pretty well out of the change.

I like the approach of Provider apps using MVC4, entity framework and hooking in AngularJS or KnockOut, think I need to focus some time in these areas. This approach still doesn't leverage SP and merely uses SP/app model as a container for your solution.

As always I guess it's "Horse for Courses". Cheers for the input mate.

Paul Beck said...

Anonymous: The simplest thing is definitely sharepoint hosted, other solutions rely on having another farm to host the solution. Don't forget, that in big solutions we are used to sharepoint handling the scaling for us, once you are outside of sp you are back to roll your own site and everything associated with it including scaling out. Apps are just complicated whichever way you go

Snippet on building apps:
If you try to deploy an App from Visual Studio to anything other than a developer site you will get this error:
“Error occurred in deployment step 'Install app for SharePoint': Sideloading of apps is not enabled on this site.”
This is due to a feature that is not enabled on any other site template apart from the Developer Site. This error will also occur if you are deploying to a host named site collection that is not at the root of the web application. You will also get this when you are deploying to a site in Office 365 that is not a Developer Site.
You might be developing a solution and you may want to deploy it to a site that is not a Developer Site.
To enable this for on-premises environments, run this PowerShell script:

Enable-SPFeature -Identity AE3A1339-61F5-4f8f-81A7-ABD2DA956A7D –url

Post a Comment