SPServices' future: 'I’m not dead yet!'

Posted by Marc Anderson on Jun 17, 2015 9:00:00 AM

SPServices has been a mainstay of SharePoint client-side development since 2009. Yup, that’s when I first posted the fledgling library on Codeplex. It’s only recently that I’ve realized how important it’s been to people in the SharePoint community. I’ve always known it was getting a lot of use, but I didn’t realize how pervasive that use was.

In case you don’t know what SPServices is:

SPServices is a jQuery library that abstracts SharePoint's Web Services and makes them easier to use. It also includes functions that use the various Web Service operations to provide more useful (and cool) capabilities. It works entirely client side and requires no server install.

When I’m feeling cheeky, I call it “The first and most reliable client-side API for SharePoint.”

But this article isn’t about me blowing my own horn—I don’t own one. I get a lot of questions from people at conferences, via e-mail, and in the SPServices discussions on Codeplex about where SPServices is going.

Where have we been?
When I first started writing SPServices in the SharePoint 2007 days, the only client-side API that was available was the SOAP endpoints. My primary goal for SPServices at the time was to “wrap” those services and make them as easy as possible to use.

The purpose of wrapping the services wasn’t just to provide a developer tool set, though. The services themselves are useful, but by combining them in interesting ways, I was also able to offer some end-user tools like SPCascadeDropdowns, which lets you set up relationships between columns on forms.

After the first few releases, it became less “I” and more “we.” Members of the SharePoint community made contributions to SPServices, and I’ve tried to give them credit on the Credits page (though I’m certain I’m missing some people).

All along, the SOAP services have been the focus. They are available in all extant versions of SharePoint (2007-2013 and SharePoint Online), so they provide a ubiquitous set of tools. But in SharePoint 2013 and SharePoint Online, the SOAP services have been deprecated by Microsoft in favor of REST, CSOM and JSOM. I’m doing a session at SPTechCon Developer Days in Burlingame, Calif. next week called “Moving from SOAP to REST – You’ll Have to Do It Sometime.” It’s time for us all to think about using REST instead of SOAP.

Where are we going?
Since the early days of SPServices, SharePoint has evolved and SPServices has evolved, too. When SharePoint 2010 came out and had some new SOAP endpoints, we wrapped those as well.

SPServices is not a static thing. I’m always working on it in the background. Early this year, I started moving it over to a new home on GitHub. My goals in doing this were myriad:

  • Codeplex seems to be dying a long, slow death. It seems to run worse all the time, and fewer people are adding code to it nowadays. It was a great platform in its day, but that day has passed.
  • JavaScript development has come a long way since 2009. By moving to GitHub, we can set up a build process and develop SPServices in a modular way rather than as one monolithic file.
  • In this re-architecting process, we can update SPServices to be Asynchronous Module Definition (AMD) capable.
  • It’s time to give an option in the “value-added” functions (like SPCascadeDropdowns) to use REST rather than SOAP calls.
  • We can take advantage of modern code evaluation capabilities like bitHound and Code Climate to improve code quality.
  • GitHub is where all the cool kids are putting their code; SPServices needs to be there to stay cool. I also wanted to understand the GitHub platform, and I learn best by doing.

So where are we on all of this? Paul Tavares (@paul_tavares), one of the least-known superheroes in SharePointlandia, has lent immense assistance into help me reach some of the goals above. To wit:

  • All of the SPServices code now lives on GitHub in a single, master branch, and we’re starting to migrate the documentation.
  • We have a build process using Grunt you can use on your own clone of the GitHub repository.
  • Every module is now AMD compatible, as is the result of the build process. This lays the groundwork for custom builds of SPServices based on your particular needs. Stay tuned on this.
  • We’re re-architecting the modules so that we can offer various build capabilities, like choosing REST over SOAP for the value-added functions.
  • We’re working on the older, crusty parts of the code that bitHound and Code Climate (plus other tools like SPCAF) flag as issues.
  • SPServices is cool again because it’s on GitHub? Maybe?
How can you help?
The biggest help we get from the community is feedback on what works and where there are issues. For now, the discussions on the Codeplex site are the best place to ask questions or discuss new ideas.

As we come up with a plan to migrate the documentation, it would be great to have some help with the process. Keep an eye on the GitHub repo for information on what you can do to help.

If you’re a heavy user of SPServices and want to accelerate the move to providing REST-based capabilities, get in touch and we can discuss how you can help.

We’re all in the journey together, so if you’re not sure how you can help (but want to), get in touch and we’ll come up with something.

Conclusion
Finally, it’s been a very fun ride for me with this little library. It seems to pop up everywhere, and that’s extremely gratifying. In fact, right now there’s a survey being conducted by my friends at SPCAF about the state of SharePoint and Office 365 development. It’s cool to see SPServices in the frameworks list of what people use to develop on top of SharePoint!

SPServices still has legs, and I think it may also show you some new tricks over the next few months. Stick around: It’s still a fun ride!

Marc Anderson is a Microsoft MVP and an enterprise collaboration strategist.

Topics: SPServices

Thoughts? Leave a comment: