First off, let me be very clear about a few things: I don’t have any special knowledge here (probably, even though I’m a SharePoint MVP) and I’m probably making a few things up. But recently I’ve been thinking about where the future of SharePoint development lies, and I’ve connected some dots in my head.\
Let’s look at some fairly recent developments, shall we? A while back, Microsoft “guidance” said we shouldn’t customize SharePoint master pages anymore if we could help it. It started as a strong suggestion, but for SharePoint Online, it’s really become a “must not.” We can still make master page customization, but if we do, we may not get future improvements in our Site Collections that require changes to the out-of-the-box master pages to work.
The latest SharePoint development model, which is currently in preview, is the SharePoint Framework (SPFx). This model runs entirely client-side, and you can use whatever client-side frameworks you choose to build your SPFx-based solutions.
The latest “experiences” in SharePoint Online don’t use a master page at all. Instead, they are developed using SPFx. If you dig into the new pages for document libraries, Delve, site contents, etc., you’ll see the usage of Knockout.js, React, and other client-side development frameworks. Nary a bit of .NET is in sight except the outer shell of the pages.
.NET and ASP.NET were open-sourced in late 2014. This fits into the whole ethos of the new Microsoft, where they have really opened the doors and become a far more open and collaborative company. At the same time, pushing these major development platforms out to the open-source world may well mean they have less strategic importance for them.
When I add these things together, I can see a not-too-distant future where .NET isn’t in the SharePoint picture at all. Now, a shift of this magnitude isn’t going to happen fast. There’s legacy code to support and hundreds of thousands of SharePoint developers still toiling away in .NET for on-premise farms. Some of those farms are running older versions of SharePoint, sure, but many dyed-in-the-wool SharePoint developers keep plowing ahead in .NET because it’s what they know.
The decisions we make about which technologies should never be made are entirely based just on what keeps us comfortable, but they are indeed a factor. I’d say the top three reasons for development decisions ought to be:
- Business requirements: What is it we need to build?
- Best technology for the job: What is the best toolset to accomplish it?
- Organizational skills: What do we already know how to do?
If all of your developers have been doing .NET for years, then they are likely to swing the .NET hammer at anything that comes near them. (I suppose I can be accused of the same when it comes to client side development.)
But what if the future is .NET-less? There’s a veritable army of SharePoint developers out there who need to rethink their skill sets (if not for their organizations’ benefit, but for their own benefit) to increase their marketability in the modern workplace.
I’m not trying to scare anyone here, but all technologies come and go. .NET has been around a lot longer than most, and it’ll be around for a good long time to come. But shouldn’t you as a SharePoint developer be preparing yourself for the time what .NET is truly waning and not just becoming one part of the landscape?
I expect I’ll get some rebuttal on this (“They would never...” “No dev platform even comes close...” “The .NET toolsets are just so much more powerful...”), but those rebuttals will likely be based on the “what we already know” thinking that can get people in trouble. Change is usually a hard thing to handle, but we see industry disruptions all the time. Don’t let yourself become roadkill on the journey of SharePoint development. Get your skills buffed up for new ways of doing things and embrace the changes as they come. You may well thank me for this advice later.