The future of SPFx on SharePoint Server?
This article explores the different options and future scenarios for SPFx development on SharePoint Server.
Some customers simply refuse to aim for the stars to land among the cloud(s), and would rather stick to SharePoint Server (2016, 2019 or the Subscription Edition - SP16, SP19 and SPSE later in the text, respectively).
This is understandable. We all know the feeling when the status board looks like this:
(Just for the record, there being an outage when I was writing this was completely coincidental and I had nothing to do with it, that's just how the cloud is)
That's ok. When someone else breaks the cloud, we feel helpless. Not much we can do about it. And if there's something customers hate, it's feeling helpless. They need someone they can yell at to make things right. And it doesn't help to yell at the clouds.
Well, okay - it does help a little. But it's far better to have an actual server you can kick. The sound, and especially the physical feedback of metal bending before you makes it much more satisfactory. You really do feel like you're having an effect. Quite different from just hitting F5 repeatedly on the cloud status page showing all red.
And to avoid making this introduction just a joke, there are also plenty of valid reasons to stay on-prem instead of embracing SharePoint Online. Better control, proper accountability, (possibly) higher security and in some cases, higher availability are all valid reasons for using SharePoint Server instead of SharePoint Online. And some customers simply are not allowed to move their data to the cloud.
But how DO you actually develop webparts on SharePoint Server?
SPFx development on SharePoint Server now and in the future
Okay - now that we've got the reasoning for staying on-prem out of the way, what does the picture look like for SharePoint on-premises in 2023?
Well, in short, it looks pretty bleak.
Microsoft themselves said it like this (in 2021):
it's important to note that the goal of SharePoint Server Subscription Edition isn't to close the feature gap between SharePoint on-premises and SharePoint Online. That gap will likely grow over time. Instead, the goal is to provide a product that meets the unique needs of our on-premises customers. The feature investments we've made in SharePoint Server Subscription Edition are based on the feedback we've received from a variety of on-premises customers over the past few years. That includes feedback about why they need to stay on-premises and what capabilities and experiences are most important to them. (https://techcommunity.microsoft.com/t5/sharepoint-server-subscription/modern-webparts-in-sharepoint-server-subscription-edition/m-p/2928761)
Okay. Doesn't sound unreasonable, right?
You need to read between the lines a bit here. What Microsoft is saying is that SharePoint Server will not get many features unless big customers, who pay big money, threaten to use M-Files or Jive or IBM HellScape Server Premium or whatever licensing nightmare Oracle now has in their offering.
And that brings us to SPFx. Apparently, no-one with a lot of money has wanted Microsoft to update SPFx from 1.4.1, so they didn't. For SP16 & SP19, that is.
SharePoint Subscription Edition DID in fact get a new Feature Pack in March, and SPFx support finally got a massive bump to... 1.5.1. So now SPSE is running the latest and greatest code from the year 2018, and that's what you'll be working with for a while.
Microsoft themselves put it like this:
This is the first step on a long-term journey to continue investing in SharePoint Framework for SharePoint Server Subscription Edition.
https://techcommunity.microsoft.com/t5/microsoft-sharepoint-blog/what-s-new-for-sharepoint-server-subscription-edition-march-2023/ba-p/3768752
There's a bit of future commitment in there, but I think it sets
SPFx support in SharePoint Server Editions
A quick re-cap: which versions of the SPFx Framework can you use in your on-prem SharePoint development?
| Sharepoint version | SPFx version |
|---|---|
| SP16 (FP2+) | 1.4.1 |
| SP19 | 1.4.1 |
| SPSE (pre-23H1) | 1.4.1 |
| SPSE (23H1+) | 1.5.1 (yayy!) |
As an additional little tidbit of information - Yeoman generator for SPFx stopped supporting generating on-prem solutions from 1.14 onwards. Up until 1.13 you could generate solutions for on-prem - but they'd be using SPFx 1.4.1 instead of whatever version of tooling you were using to create them. And your tooling might not be able to build the solutions even if you're able to generate them.
Is it safe to use the same SPFx version your grandfather used before retiring?
The good news is that SPFx 1.4.1 (and 1.5.1) will work, and are very likely to work for quite a while. Working with them might occasionally be tricky, but it's not like they're from the 80s.
And unlike SharePoint Online, on-prem doesn't change that much (if at all), and updates are less likely to break any extensions you might've built. Microsoft claims that SPSE can and will get updates incrementally, but the actual effect of that remains to be seen.
The bad news is that it's now really clear the update cadence is... Slow. Close to non-existing, really, for on-prem.
It honestly looks like supporting later SPFx versions would require so much backporting from SharePoint Online to SP19, that Microsoft is unlikely to make that investment. I'd be surprised if SP16 got any SPFx updates before its end-of-life in 2026.
And when Microsoft is moving Windows more or less back to the good-old "big-ish update every 3 years"-model that IT hates but vendors love, I really can't see SPSE getting their updates "bi-annually" (unless they mean "once every 2 years", that is).
Again, that's unless a big customer with enough seats to affect someone's scorecards directly, contacts their local Microsoft sales people. Then all bets are off.
What else can we do?
So what are the alternatives to SPFx?
You... Could build a provider-hosted add-in. You probably shouldn't, though. They're horrible, and I think nobody at Microsoft has tested their compatibility with SPSE, or even SP19. But they should, in theory, work.
You could just show your stuff in a normal iframe without bothering with the whole add-in model. That should, in a lot of cases, work just fine.
And of course if the customer is using Teams - why wouldn't you build it in Teams instead?
But if your solution needs to sit nicely on a SharePoint page, you're left with SPFx.
SPFx 1.4.1 (and 1.5.1), with all of their limitations and really outdated tooling, are still pretty solid frameworks to build on. You won't have the newest features, but you can't use most of them with on-prem SharePoint anyway.
Andrew Connel from Voitanos has pretty good overviews of SPFx support for SharePoint Server versions and even some setup instructions. See the articles here: https://www.voitanos.io/series/definitive-guide-sharepoint-framework-sharepoint-server/
Conclusion
SPFx is to this day a valid choice for extending on-prem SharePoint, even if the version you're stuck with will be old. Luckily, most of the functionality in later versions of the Framework would only be useful in SharePoint Online or Hybrid scenarios.
And you can always try to steer the customer away from building extensions on SharePoint Server and instead using something more developer-friendly, be it Teams, Outlook, SharePoint Online or something else altogether - if they are allowed to use any of those tools, that is :)
