SPServices and SharePoint 2010

I got a question today via email that I though would be good to address in a post. The person who sent it didn’t want to publicly ask the questions so that s/he wouldn’t be “sowing any seeds of doubt for using” SPServices.

Now that 2010 is here with its WCF services and Client Model, do you see any future in your [SPServices] project? As I’m not using 2010…I can’t spend the time investigating for 2010, so it could hold some value for me in my 2007 work, but then if we migrate to 2010, is it obsolete or does accessing via the standard web services and hence by your library have any advantages over the new 2010 methods?
I can think of perhaps for compatibility providing parts that will run on 2007 and 2010.

First, a general comment. You can post any questions/reservations/concerns about SPServices anywhere, anytime. It’s good to have a healthy debate about these topics. If you’re being particularly caustic, I’ll probably hear about it and will be interested in your comments.

SharePoint 2010 does indeed give you new options for doing some of this stuff. The Web Services are also still there, and in fact there are new ones you can work with, like the SocialDataService Web Service. I still see SPServices as totally viable and useful. It’s important, as it always has been, to use the right tool for the job. Yup, just like everything else in SharePoint, “It depends”.

It depends on:

• Your governance model – What limitations do you have on code deployment for users, power or otherwise? What’s your policy on third party tools? (SPServices is one, even if you don’t pay for it.) What’s your permissions model?
• Your software development lifecycle (SDLC) – How do you deploy code? How many environments does your code have to move through? Do you already reference jQuery already in the master page/page layouts/individual pages?
• Your skill sets – The reason some people love SPServices is that it allows them to do things themselves rather than replying on IT support. Working in the Middle Tier also means using more ubiquitous Web development tools (see: The Middle Tier Manifesto: An Alternative Approach to Development with Microsoft SharePoint) But if your team is made up of all hardcore .NET developers, then SPServices may not be for you.
• What you are trying to accomplish – Calling the Web Services isn’t the answer to everything, and sometimes its just plain a bad idea. You have to understand how they work and what you’re asking the client browser to process for you.
• Your hardware capabilities – Sometimes using Web Services calls can be a good way to offload processing to the client. (I always get debate on this.) If there’s functionality that is in your page which is used a very low percentage of the time and you can replace it with a Web Services call on demand, you offload workload from the server.
• and more…

I’m looking at how SPServices can work better with SharePoint 2010 more and more these days, while not giving up its usefulness in 2007 and even continuing to enhance things for 2007. I’ve been getting some excellent code submissions lately that will allow me to add new functionality and/or enhance existing functionality. Check the Issue Tracker for details if you’re interested. SharePoint 2007 isn’t going way anytime soon in many organizations (some are still running SharePoint 2003) so these development techniques still have a firm place in the array of options.

Expect that I’ll continue to add functionality which is targeted specifically at 2010, as I did by wrapping the SocialDataService Web Service in SPServices v0.5.8. I’ll also start spending more time certifying functions for use with SharePoint 2010. (I’ve let that effort slip a bit.)

Finally, to keep SPServices useful and viable for SharePoint 2010, I’d love to hear from YOU about what you’d like to see it do, especially if you’re already an SPServices user in 2007. If no one sees any use for SPServices in SharePoint 2010, then I won’t bother, but I doubt that will be the case.