Where Should SPServices Go Next? Common Question at SPC12

This is just a quick post I’d like to use to gather your thoughts on where SPServices should go from here.

At The Microsoft SharePoint Conference in Las Vegas, going on right now, many people I’m talking to are asking me about my plans. I’ve been mulling it over for a few months now, and I have my own ideas. But I’d love to hear where you’d like to see SPServices fit into the SharePoint 2013 landscape. Let me know what you think in the comments, or over on Facebook here or here.

Here’s a photo of Jeff Teper speaking at the keynote today. I had a great view from the front row, center.

20121112-211403.jpg

Similar Posts

3 Comments

  1. Marc, as you may or may not know I’ve been a long time evangelist for the fenominal work you have done and employed this as a foundational footing for many enterprise implementations. One arena that I’ve always struggled with between this or restful service interface was hands down the decision of cross domain script acces layer. Seeing the deep integration with oAuth stack in the app model i feel like there is a place in an app catalogue or store model that could bridge the two. Giving ease in or out of any service layer while providing authenticated access (brokered or client context) to/from other domains. Who knows there may already be something like this that

  2. Make it easier to make new SP2013 “Apps” with less coding? C# is popular in part because it’s concise. Looking at the Napa sample App.js on Office 365 Dev Preview it seems there’s a lot of overhead code to do simple tasks. Yes, part of that is the async nature of the CSOM … but isn’t there a better way?? Devs are lazy and “App” adoption will be reduced if it’s too much effort. My two cents.

  3. I have not looked at SP2013 or what it offers, but do know that the future in SP custom apps is shifting to client side technologies… I also don’t know how robust the RESTFull api is but I bet it is lacking… Although I think SPServices initial goal was to provide an easy interface to the SOAP API, you have provided significant functionality in value added utilities that tackle real everyday challenges and do it very well. Perhaps it is that space that will continue to justify the existence for SPServices or making the RESTFull API “easy” to use (I realy don’t know if it already is or not).
    I know that in my own usage of SP, I have developed my own widgets/tools that themselves wrap around SPServices in order to have an easy reusable toolkit that I can apply to any project.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.