SPServices in the Office 365 Developer Podcast

Today Randy Drisgill (@drisgill) alerted me to the fact that Jeremy Thake (@jthake) and Steve Walker (@sharepointing) were talking about me in the Office 365 Developer Podcast: Episode 018 with Steve Walker on SharePoint UX developer guidance. While they do indeed say some very nice things about me (those payments to Redmond are working out), there’s actually a *lot* of great material covered in the podcast. If you just want to hear the part about SPServices, it starts around 28:00.

It’s good to hear that Jeremy, Steve, and I think about some things the same way:

• I’m awesome (just kidding)
• Everyone loves SPServices, even Steve
• “The SOAP services are deprecated, but unlikely to go away any time soon” (Jeremy)
• “Deprecated doesn’t mean you can’t use it; it means [Microsoft] isn’t going to invest in the future and [they] will take it away at some point.” (Steve)
• “Deprecated means that ‘no engineer is going to touch that’. It’s still running, it’s still in there, but we’re not going to be adding additional methods or functions.” (Jeremy)
• Changes to the DOM can break SPServices and Microsoft *will* change the DOM on Office365 – expect it
• Governance for script-based solutions is just as important as for anything else.
• This stuff isn’t unique to SharePoint and Microsoft. We’d deal with a lot of these things with anyone else’s Web-based software, too.

As far as the deprecation of the SOAP Web Services goes, as far as I can tell, there hasn’t been *any* work done on them since SharePoint 2010 was released. That was way back on May 12, 2010, making it over 4 1/2 years since anyone has messed with them. Effectively, they have been deprecated for that long based on the definitions above. That latter part is one of the reasons the SOAP Web Services are so awesome: since no one messes with them, they are incredibly stable. Also, since they were developed a long time ago, they are pretty darn efficient. (We had to work harder to get more out of with less hardware capability back then.)

Just as with InfoPath, deprecated is not a death knell. With Infopath we *know* that there’s a long, long runway out to 2023 before support stops for it: “the InfoPath 2013 desktop client and InfoPath Forms Services for SharePoint Server 2013 will continue to be supported through 2023 as part of our Lifecycle support policy.” It will have a healthy life for quite a while after that, too, just like Windows XP still does. We don’t know what the runway looks like for the SOAP Web Services, though. That may mean we have more time, but it may mean we have less.

For quite a while now, I’ve advocated offering FaaS – or “Functions as a Service” – to the organization. By adding things like jQuery into the master page and letting citizen developers know about it, you immediately get some accountability and even can start some collaboration around that type of development. I wrote a whole chapter about these ideas last year in the book Black Magic Solutions for White Hat SharePoint. If you’re on premises now, but think you may be moving to Office365 in the future, the more you (an IT person) know about the citizen developer work that drives your business now, the better. The work that those citizen developers do is *so* important – they build what the organization truly needs and they are unsung heroes.

Some things I am not on the same page with Jeremy and Steve on:

“Don’t use our DOM as an API” – This would be fine if there were good ways to alter the DOM via a “real” API. Maybe that’s coming and maybe it isn’t. Until it does, we don’t really have much choice if we want to extend (or fix) things in places like the default list forms, which so many of the SPServices value-added functions provide.

The rules aren’t back and white. Much of the messaging from Microsoft centers around SharePoint Online and Office365, as if on premises installations don’t even exist. If you’re running things on premises, the same things won’t happen to you at such a rapid pace, the pace driven by the regular updates to Office365. You have control , so you can make different decisions. I know that the podcast is “Office365 Developer…” but many people think of messages from Redmond as applying to everything. It’s all nuances.

I’m probably more concerned about all the existing code out there that uses SPServices on top of the SOAP Web Services than the services themselves. I’ve been promising Scot Hiller (@scothillier) a series of articles on this for ITUnity for months, but I just can’t seem to get it done. Watch for some material from me about it, though. I want to help you move from SOAP to REST in an organized and productive way. You will have to do it sooner or later. Preparing for that eventuality will help to address the concerns that Steve and Jeremy expressed in the podcast.

And thanks again for the kind words and support, guys.