When to Choose SPServices vs. the Client Side Object Model (CSOM)
Mark Rackley (@MrAckley) and I had a Twonversation with Jeff Jones (@SPJeff) about a month ago about when it is good to use SharePoint’s Client Side Object Model (CSOM) over SPServices. You can see the important bits of that conversation in the image to the right. (Yeah, it’s taken us forever to get this post done. I blame Mark.)
In fact, Mark and I often are asked “When should you use SPServices vs. the CSOM?” Both technologies are script-based, and both allow you to talk to SharePoint through its Web Services. However, there are some important differences to consider when you are deciding which to use,
In this post, Mark and I will try to give you some pros and cons for each. Many of these statements are subjective on purpose; it’s the way the two of us view the two technologies and shows some of the considerations we take into account as we make architectural choices for our clients.
Why You Should Be Using SPServices (says Marc)
SPServices is a jQuery library which I wrote and continue to work on, so I have to admit a strong bias. However, I think there are some clear reasons that you should use it in some cases. It’s not the only answer, but it’s a great tool you can use to solve real business problems.
SPServices exposes a wide range of SharePoint’s Web Services in either SharePoint 2007 or 2010, letting you interact with the Webs, Users and Groups, Permissions, UserProfileService, and Workflow Web Services, and more. This interaction is consistent between SharePoint 2007 and 2010, so there’s no relearning when you upgrade. (Yes, Virginia, there are still a lot of organizations out there running some flavor of SharePoint 2007.)
SPServices supports anonymous access to read from lists, and it works cross-site and cross-domain by simply specifying the webURL in the Web Service operations where it makes sense to do so. Of course, your authentication model has to allow cross-domain access.
The syntax in SPServices is relatively simple and pretty consistent with the way jQuery and other mainstream scripting libraries work these days. All you have to do is pass the Web Service operation you want to call, along with the required parameters in the options. No fuss, no muss. The SOAP Web Services, upon which SPServices is built, return XML and parsing XML with jQuery is old hat for most Web developers. SPServices’ reliance on the jQuery library ensures great cross-browser consistency as well. Most of the code you write using SPServices is going to work exactly the same way regardless of the browser your users have.
Finally, because I continue to develop SPServices – most frequently based on user input – it’s highly likely that I’ll make a new option or function available to meet your needs. I put out new releases of SPServices regularly (there were five releases in the last year) and aim to keep the library evolving and staying current with newer versions of jQuery. Obviously, keeping bugs to a minimum is an ever-present goal. Oh, and it’s free to use on Codeplex, under the MIT License.
Why you should be using the Client Object Model (says Mark)
Yeah.. yeah.. yeah… SPServices is groovy and all and Marc did a great job with it, but if you are using SharePoint 2010 it should NOT be your first choice when it comes to client side development. Why? I’m so glad you asked!
Unless you need anonymous access or cross site access, SPServices is actually a detriment to your SharePoint sustainability. COM is the only way to go.
Like it or not COM is the future and .asmx web services are the past. You need to learn the current technologies and let the outdated stuff go away. Main stream support for SharePoint 2007 ends in October and vNext is just over the horizon. Microsoft has some pretty smart people and I would not be surprised in the least if they addressed the anonymous access issue in SharePoint 15 as well as some of the other limitations. So, if you don’t use COM and rely on older technologies you may very well find yourself rewriting a lot of code when you could have been ahead of the game.
Additionally COM uses RESTful Web Services and can return your data as JSON which means better performance and less data being passed over the wire. Performance is a huge issue with JavaScript and jQuery so from this standpoint alone COM is the better choice. COM is also structured much more like .NET and has a nicer “feel” to it for the average .NET developer plus it’s more developer friendly (“ows_Title” anyone?). Lastly, COM is NOT jQuery based. It is written in ECMAScript (JavaScript to the rest of us) so there are no additional libraries or overhead needed. How’s THAT for compatibility?
I think it’s pretty black and white. SPServices is a great tool that I have used quite effectively, but if you are using SharePoint 2010, want better performance, a better development experience, and a technology that will definitely exist in vNext then you have to use the Client Object Model.
Summing it up…
And because I’m typing this, I get to say that Mark is all wrong. No, that’s absolutely NOT the case, All of Mark’s points are valid, but there isn’t a one-size-fits-all answer to everything. To help you decide which directions to take for your own organization, we’ve compiled this list of pros and cons for each option. Do you have other ideas for pros and cons? If so, please post the here in the comments or on Mark’s post on his blog.
SPServices
Pros
- A wide range of SharePoint functionality is exposed with the SOAP Web Services, much of which is not available in CSOM
- Allows anonymous access (assuming it is enabled for the underlying objects)
- Works cross-site and cross-domain, assuming that the authentication model you are using allows it
- Simpler syntax than the CSOM. Simply pass the required parameters to the Web Service operation, e.g., GetListItems
- Built on top of jQuery, which is very good at ensuring cross-browser compatibility
- Regularly updated and refined to be compatible with new versions of jQuery and to add new functionality based on user input
- Works identically in SharePoint 2007 and 2010 (where the same Web Services exist – see chart)
Cons
- The SOAP Web Services which SPServices wraps is “old” technology which only returns XML
- Because the SOAP Web Services are older technology, they may not be supported as long as CSOM
CSOM
Pros
- Provides access to the “modern” RESTFul Web Services which return JSON or XML based upon your need
- Coding patterns mirror .NET, which may make more sense to .NET developers
Cons
- No anonymous access
- No cross-site or cross-domain capabilities
- Complicated syntax which mirrors .NET coding patterns, which may make less sense to Web developers
- Have to create your own success and failure methods
Recently I did some sort of background studies for comparing Web Services with COM by checking memory utilization for execution of same query by using COM and Web Services, result I found is COM uses a huge amount of memory while executing the query as compared to web service call. After replacing all the COM calls from our application to the web services calls, we earned lots off less memory utilization on server.
Amogh:
Did you look at the effect on the client side? Saving memory utilization on the server is great, but you probably ended up pushing processing to the client side. If your client machines can handle it without a degradation of the user experience, then a job well done.
M.
That’s exactly the problem I’m facing right now. We have a ton of outsourced code from vendors and SPServices shows up a lot. We also have a lot of really old machines (talking 32-bit, 1gb of ram) present in our ecosystem. All that jQuery over xml on the client frequently renders the pages unresponsive, and due to the amount of xml processing that goes on, we also see async calls failing to process at all due to simple thread unavailability. As with everything, people have to be cognizant of the code their writing as well as the environment they’re targeting or it will run horribly.
Ugh. Writing stuff that runs client side can be a horrible idea for lots of reasons.
Knowing what your lowest-capability machine can do should be the first step before you write any code at all.
Unfortunately I see SPServices used in odd ways. I also see managed code used in odd ways. (By odd, I probably just jean bad.) either you’re good at what you do or you aren’t.
One last point: in SPServices 0.7.2 I introduced simple client-side caching. Upgrading to that version *may* help. In the upcoming 2013.01 release I’m implementing deferred objects and returning promises which may help even more.
M.