When to Choose SPServices vs. the Client Side Object Model (CSOM)

imageMark 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.

This post also appeared on NothingButSharePoint.com‘s EndUserSharePoint channel on 2012-04-25. Visit the post there to read additional comments.

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

26 Comments

  1. I think listdata.svc should have its place here. It offers the same cross-site/cross-domain capabilities as the legacy Web services, plus built-in support for JSON.

    What I find misleading in the post is that Web services are associated with SP 2007. It is absolutely not the case, and Web services are supported in SP 2010 and Office 365. Keep in mind that Office 365 won’t be replaced until at least 2014 or 2015…

    Cross-posting might not be the best choice to ensure a healthy follow up discussion, but this Marc vs. Mark debate is a fun idea!

    Reply
  2. Nice Pro/Con list. However, if you are going to cite maturity as a ‘Con’ (for web services), you must also cite immaturity (for Client Object Model) as a ‘Con’ as well.

    Having worked with SharePoint data services for 6+ years now, and having rolled my own Client Object Model that is compatible for both SharePoint 2007 AND SharePoint 2010 I can safely state that web services perform MUCH better– especially for querying.

    Not that I am a fan of CAML for querying, but newer technologies should, philosophically speaking, show syntactic and performance improvements (call me crazy).

    Also, I don’t believe the MS Client Object Model has the same breadth of service support as the web services, so in some cases it’s not even possible to replace the old with the new.

    Further, working on Windows 8 development right now, the new and the old isn’t even supported! Hopefully that will change soon or we will quickly need the ‘Ueber New’.

    Reply
      • Consider OLE DB, ODBC, ADO, Linq, etc..

        There is no reason to think the MS Client Object Model is the end-al-be-all. I’m willing to make a large wager that something will replace it too :)

        Reply
        • John:

          Those of us who have been around the block more times than we can count might point out how many “this changes everything”s we’ve been through. And so it goes…

          M.

          Reply
  3. Marc, your post reminds me that I have never seen any confirmation from Microsoft that anonymous access is supported for Web services (cf. your pros). Any news on this front?

    Reply
    • Nope, I never got any information one way or the other. However, there are many people replying on the capability and successfully using it. I think at this point in the SharePoint 2010 (and certainly 2007) lifecycles, we can reasonably assume that it’s legit and won’t change.

      M.

      Reply
  4. I don’t think it’s a pro the COM coding patterns mirror .net at all. There’s a hell of a lot of inefficient javascript code in the COM just so it “looks” .net-ish. It’s a JavaScript framework and should use Javascript syntax and JavaScript best practices! As it is, we”ll end up with a bunch of JavaScript Frameworks to allow easy calls into the JavaScript Framework which is a bit silly.

    Reply
    • Joel:

      It’s probably not suprising that I agree with your view on this. It takes a lot of .NETish script to accomplish things with the CSOM. To me, coming at it more from the JavaScript side, it feels cumbersome.

      M.

      Reply
  5. This was my reaction to the “pro” that CSOM mirrors .NET as well. Frankly, I think .NET has done more harm than good when it comes to Microsoft’s web products (hello tables for everything, duplicate id’s on a page, overly-verbose CSS, etc). If you’re going to write HTML, CSS, and JavaScript, I think it should be done using best-practices for those specific technologies, and the people writing it better know what they are doing or find someone who does.

    One other PRO for SPServices that I haven’t seen mentioned yet is the fact that it comes with built-in form enhancements and some handy utility functions.

    Reply
    • Josh:

      To you, it’s probably not a pro, nor is it really to me. I think the fact that the CSOM is so .NETish is definitely the case to help .NET folks make the transition to scripting against SharePoint. If you don’t come from the traditional SharePoint development side, then it’s not a pro at all.

      I think we’re going to be stuck with the .NETish CSOM approach for the forseeable future, though we do have other alternatives – like SPServices.

      M.

      Reply
  6. I was reading through this post again and stumbled on this sentence: “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.”. Well, I’d be curious to see the proof…

    Reply

Leave a Reply