I have been working on custom branded SharePoint intranet sites for a long time. And for the past year or so, the only type of customizations I have developed have been those that involve CSS, HTML and JavaScript. And these are not just UI customizations but ones that involved complex requirements and functionalities and require a lot of heavy-lifting.
And it’s just not me…
If you look at the job descriptions for SharePoint developers in the market, they clearly indicate that most of the hirers are looking for experience with JavaScript frameworks, CSS styling, MVVM modular design, JSOM/CSOM, REST, etc.
The historical SharePoint developers who had been working with C#, ASP.NET, farm based solutions, etc. are being clearly and steadily replaced by developers who see SharePoint and Office 365 as another web based JavaScript platform.
Microsoft has been encouraging this shift to Client side development from Server side development for several years and with the advent of Office 365 this push is accelerated like never before and the development community has embraced this model heavily.
Office 365 does not allow farm based solutions and server based code.
SharePoint 2016, however, still allows the use of C# coding to create farm based solutions but those kind of developments are only used for backward compatibility, or by clients who are running an older version of SharePoint and want to migrate to SharePoint 2016 while still keeping their existing farm based solutions.
There are many reasons that back up this trend:
As SharePoint platform continues to evolve, tasks that needed a lot of heavy lifting can be achieved using either configuration tools or light weight customization such as CSS changes, JavaScript or HTML templates instead of .NET coding.
Office 365 is moving to an incremental release approach so instead of waiting for three years for the next version, the feature you need might be available in a couple months.
A focus on ensuring that user interfaces work just as well on tablets, phones and laptops means that user interfaces need to be more responsive, fluid and dynamic.
Microsoft has clearly moved to a more open model and recognition that they can no longer own the entire platform and must share with other players.
In a similar way, Microsoft has also been integrating on the backend with Salesforce, Dropbox, SAP and many others. Expect more integration with other SAAS providers as Microsoft attempts to be the core integrator of all these disparate services into a unified portal hub.
For organizations, like mine, who are still investing in Web Parts WSPs, Server side Object Model etc. from SharePoint 2010 days or are maintaining legacy code, they should be prepared for a new archetype – as the world has changed to a JavaScript, client-side, HTML 5, JSON/CSOM, Rest model and is here to stay.
In my next post, I will talk about what is the client side development paradigm and how it compares with server side.