SharePoint Framework is a very powerful model for extending SharePoint... in the cloud. On-premises, it's a whole different story.
Over the last few years, we've been having regular updates to the SharePoint Framework - the latest model for extending SharePoint. We went all the way from the generally available version capable of building web parts to v1.10 which supports extensions, library components, and connected web parts. Unfortunately, on-premises, we're still stuck with v1.4.1 which is limited to web parts and extensions. Here is why.
SharePoint Framework on-prem
SharePoint Framework is 100% client-side development model that runs in the browser. The solutions we build using SharePoint Framework depend on the framework itself that is not included in the solution but is loaded from the server. In Office 365, every time there is a new release of the SharePoint Framework, Microsoft updates the SharePoint Framework assets so that our solutions can use the latest version. But the SharePoint Framework version that is available on-premises remains the same. So why Microsoft won't just update it? Well, it's not that easy.
Updates to SharePoint Server are released as a new major version, Feature Pack, or Cumulative Updates (CU). Sometimes these updates are incremental, sometimes they're more intrusive. No matter the scope of their changes, they're infrequent, because they're hard and the cost of failure is significantly higher than it is in the cloud with its weekly release cadence. What's more, newer versions of the SharePoint Framework depend on the functionality that isn't available on-premises, like Office 365 CDN or tenant-wide deployment. Sure, some things could be theoretically released to SharePoint on-premises, but shipping just a few pieces out of a complete product is rarely feasible and often at a high cost. So in the end, SharePoint Framework v1.1.0 in SP2016 and v1.4.1 in SP2019 is what we have.
Should you use SharePoint Framework on-premises?
Newer versions of the SharePoint Server ship with the modern UI, which can be extended only using the SharePoint Framework. Even if your organization uses the classic SharePoint experience, there is a benefit to using the SharePoint Framework. Whatever you build today, will be guaranteed to work tomorrow both on-premises and in the cloud. Not to mention, it has a significantly lower impact on your platform hygiene. You cannot say the same of your Farm solutions.
The SharePoint Framework capabilities available on-premises are rarely sufficient for real-life business solutions. But even in the cloud, you would combine them with the add-in model or Azure AD apps to support long-running operations, provisioning, or operating using elevated privileges. So it's not quite the matter of if you should use the SharePoint Framework, but where do you stop using the SharePoint Framework and start using the add-in model. Where you draw the line will likely differ between SharePoint Online and SharePoint on-premises but the general idea remains.
If you want to build robust and reliable solutions that are guaranteed to work in the future, you should extend the UI using the SharePoint Framework. Coming from Farm solutions and custom Master Pages you will likely find it limiting, but it's for a reason. It's what allows Microsoft to keep the pace of innovation, guarantee service uptime in the cloud, and operate Office 365 in a cost-efficient way. You can have the same benefits when using SharePoint on-prem, as long as you're willing to use the cloud-ready mindset when designing your SharePoint solutions.
Photo by Thomas Jensen on Unsplash