RSMUS.comAs we have seen with the introduction of Office 365 and the trend to move from on-premises environment to a cloud environment, the future of SharePoint is changing. With the move to a more cloud centric model, the tools, technologies and frameworks traditionally used in your on-premises version of SharePoint for custom development may not, or in some cases will not, work in Office 365.
Below I have listed are some changes you should begin to implement in order to sharpen your development skills as well as prepare you to work with both Office 365 and SharePoint on-premises configurations.
- REST is everywhere. With the introduction of SharePoint 2013 and the latest enhancements to Office 365, virtually everything is a REST endpoint that can be accessed. Migrating from the traditional CAML way to querying information to REST is definitely something you’ll want to focus on. There are some great references on MSDN and browser plugins to test our REST calls. Not only will you use REST to get information from SharePoint but you can also execute CRUD operations on data and invoke methods such as creating a library or a site. This coupled with the, “Call HTTP Web Service,” method that is included in SharePoint designer workflows (and several other 3rd party products) using REST should be at the top of your list to learn if you haven’t already.
- JavaScript frameworks. Many of us thought that with the strongly typed SharePoint object model, JavaScript wasn’t a “real” language and its implementation within applications would start to die off. We’re seeing just the opposite. With the sophistication of browsers and their ability to support the enhanced features of JavaScript, plus the demand from users that web applications function more like traditional desktop applications, it appears that JavaScript is here for the long haul.
- Some frameworks that are trending include: Angular.js, bootstrap and Knockout.js. They have started to rise as the leading frameworks to manipulate objects and data that are rendered on your pages (or page since many of them promote single page applications.)
- CSOM – Client Side Object Model. What is the “client?” In this case, it can be a true client side .exe that uses the CSOM object model in your Visual Studio solution, or it can be a JavaScript framework that you include in SharePoint. Both provide similar functionality and the ability to interact with SharePoint objects. If you’re already familiar with the SharePoint object model such as SPWeb and SPList then you’ll feel at home with CSOM.
- C#. As much as we all love the strongly typed object model and true object oriented programming, save your C# skills for another platform. Web parts are being replaced by app parts, timer jobs can be handled with a PowerShell script running as a scheduled task and code behind application pages are using the JavaScript frameworks described above. Like all technologies, the only constant is change. This certainly holds true for SharePoint as we’ve seen it become a mature and essential part of the Office ecosystem. If your solution requirements dictate that custom functionality is needed, keep these development considerations in mind. If you do have a hybrid environment because you need to communicate with a line of business system or use advanced functionality that the JavaScript frameworks can’t handle, C# solutions are still the way to go.
Like all technologies, the only constant is change. This certainly holds true for SharePoint as we’ve seen it become a mature and essential part of the Office ecosystem. If your solution requirements dictate that custom functionality is needed, keep these development considerations in mind.
To find out more about this or other ways that RSM can assist you with your SharePoint needs, contact our professionals at 800.274.3978 or email us
