Why SharePoint Framework still runs on React 17

Fourteen consecutive SharePoint Framework releases have shipped with React 17.0.1. Fourteen.

That sounds like stagnation. It is not, and it is rarely discussed as anything else.

The facts first

Microsoft publishes a compatibility table for every SPFx release. Here is what it says about React, checked on 5 August 2026 (SPFx platform and toolchain compatibility):

Three major versions of React in ten years of SPFx, and the current one has held for fourteen consecutive releases. The release that changed it is dated and explicit: SPFx 1.16.0, released on 15 November 2022, "SPFx now supports React 17 by default" (v1.16.0 release notes).

One comparison makes this sharper. React 18 was released in March 2022, eight months before that. Microsoft did not pick the newest version and then fall behind. It shipped a version that was already a generation old on the day it arrived.

Whatever this is, it was never a bet on novelty.

We know what a major React move costs, because it already happened

The obvious question is why it takes this long. The answer is in the release notes of the last time it happened.

SPFx 1.16.0 is the release that moved SharePoint from React 16 to React 17. During that transition, Microsoft fixed issues including:

• list extensions failing from a React version mismatch (#8482)
• invalid hook call errors in web parts (#8487)
• the property pane not displaying (#8496)
• a minified React error #321 (#8510)

Those are Microsoft's own release notes. Not a forum complaint, not an anecdote.

Moving one major version of React broke customer code in production, and the fixes shipped alongside the change that caused them.

The sentence that changes the story

The SPFx roadmap lists dated releases through September 2026. React 18 is in none of them. It sits in a separate section called Top of Mind, with no version and no date, and this text (SPFx roadmap, checked on 5 August 2026):

React 18 support for SPFx solutions. This update is dependent on updating Microsoft provided web parts and experiences to use React 18 version. This work is in progress.

Read the dependency again, because it runs in the opposite direction to the one usually assumed.

Customers are not waiting for Microsoft to finish a framework upgrade. Microsoft cannot offer the framework upgrade until its own web parts have moved.

The first-party surface is the blocker.

Every organisation with a custom web part is downstream of an internal migration it cannot see, influence or schedule.

Read together with the previous section, the picture becomes clear. If moving from 16 to 17 broke list extensions, property panes and hooks in production, the absence of a date on 17 to 18 stops looking like neglect and starts looking like an accurate estimate.

This is not about npm

From the outside, this looks like a dependency update. It is not.

What actually has to hold together at the moment React changes:

• Microsoft's own web parts, which render on hundreds of millions of pages that nobody is going to test individually;
• Fluent UI, which SPFx projects have used at v8 since 1.18 (using Fluent UI in SPFx);
• every customer solution ever deployed, built against a runtime contract that was true when it was built;
• the runtime itself, where first-party and third-party code share one page and one React instance.

That last point is the whole problem. A SharePoint page is not an application with one owner. It is a shared runtime where Microsoft's code and your code execute side by side, and a major version of React is not a private implementation detail when both halves have to agree on it.

React 17 is no longer just a framework version in SharePoint. It has become a platform dependency. Platform dependencies do not move when one party is ready. They move when every party is.

Why this matters outside Microsoft

Everything above describes Microsoft's challenge. This part is yours.

The constraint does not stay inside the platform. It lands in your repository, in the version you install, and in what your web part does on a page you do not control.

The failure mode is silence

Microsoft's compatibility page carries this warning:

Using incompatible React versions can cause silent runtime failures without clear error messages during the build process.

It goes on to recommend pinning exactly:

npm install react@17.0.1 react-dom@17.0.1 --save-exact

Silent is the operative word. A solution built against React 18 can compile. It can run locally. It can pass review. And then it renders a blank area in production, with nothing in the console to explain it.

There is no error to search for, because there is no error. If you take one instruction from this article: pin the React version your SPFx release specifies, exactly, and check it in review. Not because a newer React is worse, but because the runtime you are deploying into has already decided.

What AI changes here, which is less than you would think

An agent will write your web part in seconds. It will write the JSX, the props, the hooks and the tests, and it will do it well.

None of that is the constraint. The constraint is that a page has to load first-party and third-party code into one runtime and have both work. No amount of generated code makes an ecosystem compatible with itself, because compatibility is not a coding problem. It is an agreement between parties who ship on different schedules, and one of them has hundreds of millions of users who never agreed to anything.

AI writes components. Platforms still have to agree on the runtime.

What we do not know

We prefer an explicit "we do not know" to a confident guess that will be wrong six months from now.

• When React 18 arrives. Microsoft says the work is in progress and gives no date. At the time of writing, the official SharePoint Framework roadmap does not associate React 18 support with any released or scheduled SPFx version.
• Whether the next move is to React 18 at all. React has continued to evolve since React 17. Skipping a version is a legitimate strategy, and Microsoft has not said either way. The interesting question is not what React released next, but what has to change before the SharePoint Framework can move with it.
• How much of Microsoft 365 has already moved. "In progress" is the whole of the public information.

The question underneath

The question was never why Microsoft still uses React 17.

Microsoft's problem is not upgrading React. Microsoft's problem is upgrading an ecosystem: a first-party surface, a component library, a shared runtime, and every solution any customer ever deployed, all of which have to agree on the same day.

Many organisations discover they have exactly the same problem. The dependency is different, the runtime is smaller and the audience is measured in thousands rather than hundreds of millions, but the shape is identical. Something foundational needs to change, and the answer to "what would break" is not written down anywhere.

If it takes an organisation with Microsoft's resources more than four years, it is worth asking what would have to move, and who would have to agree, before you could change one foundational dependency in your own estate.

Most organisations have never counted. That is usually the answer.

Why this article should age. We expect the SharePoint Framework to support a newer React version at some point. When that happens, this article stops being about React 17 and remains about something else: why platform dependencies move more slowly than application dependencies, and why that is a property of the platform rather than a failure of the people maintaining it.

If this kind of engineering analysis is useful, the SharePoint Migration Field Guide follows the same approach: decisions first, documentation second, marketing never.