What it is
SPFx is the short name for the SharePoint Framework, Microsoft's model for building custom pieces of SharePoint that run in the browser. An SPFx solution can contain web parts (components people place on a page) and extensions (headers, footers, field customisers, command sets). The code is packaged, uploaded to the tenant app catalog, and loaded by modern SharePoint pages. It replaces unsupported patterns such as script-editor injection and old full-trust farm solutions.
People ask "What is SPFx?" because the acronym hides the product name. Expanding it matters: SPFx is not a separate cloud, not Power Apps, and not a general Node server. It is a client-side framework hosted by SharePoint.
Why and when it is used
Use SPFx when a SharePoint page needs behaviour the built-in web parts do not offer: a custom dashboard, a branded list view, a button that files a request, or an extension that changes how a column is displayed. It is the supported route for intranet customisation that must be deployed and governed by tenant admins.
Do not use SPFx for a public marketing site, a mobile app, or a backend API. Those belong in ordinary web stacks (React, Next.js) or Azure. Do not use it when a list form plus Power Apps is enough. SPFx pays off when you need real front-end code, source control, and a package your admins can approve or remove.
How it works
The toolchain scaffolds a Node project. You implement a web part class and, in the React template, a React component. SharePoint gives the part a context object: the current site, the page, an spHttpClient for SharePoint REST, and a way to call Microsoft Graph once permissions are granted. At build time the toolchain bundles TypeScript into JavaScript assets. heft start (SPFx v1.22+; gulp serve on the legacy gulp toolchain) opens the hosted workbench so you can see the part without uploading a package every edit.
Does SPFx use React? Yes for the default and best-documented path. The generator asks which framework to use; React is the standard choice and Microsoft's own samples assume it. Other frameworks are possible, but you leave the paved road. There is also a no-framework option for tiny parts. If the question is whether React knowledge transfers, the answer is yes: components, props and state work as they do in other React apps, with SharePoint context added.
SPFx TypeScript: projects are TypeScript-first. Manifests, the web part class, props and React components are .ts and .tsx files. You are not required to be a TypeScript expert on day one, but the compiler is part of the build and loose any everywhere will hurt. Types for SPFx packages come from Microsoft's npm packages (@microsoft/sp-*).
Technologies and dependencies
An SPFx version locks a Node.js version range. Using a newer Node than that SPFx release supports is a classic failure. The scaffold uses Yeoman (yo @microsoft/sharepoint from the @microsoft/generator-sharepoint package) and npm; from SPFx v1.22 new projects build with the Heft-based toolchain (Rush Stack Heft + webpack), while v1.0–v1.21.1 projects use the legacy gulp-based toolchain. Typical dependencies are TypeScript, React and React DOM, plus Fluent UI for controls that look like Microsoft 365. The package is an .sppkg file deployed to the app catalog.
Runtime dependencies are SharePoint Online (or a supported SharePoint Server for older SPFx versions), Entra ID sign-in, and optionally Graph permissions approved by an admin. The bundle runs in the user's browser, so it cannot read server-side secrets. Calling a private API means a separate backend that performs its own auth; do not hide production keys in the SPFx bundle.
How to get started
Install a Node.js version your chosen SPFx generator supports, then install the generator and the build CLI for your toolchain (Heft for SPFx v1.22+, Gulp CLI for older versions). Run the generator, pick SharePoint Online, a web part, and React. Trust the developer certificate when the workbench asks. Change the React component's render output, save, and refresh the workbench.
Read the manifest: it declares the part's id, alias and properties. Properties the author can edit in the property pane should be typed. When the part needs list data, call SharePoint REST or Graph with the context client rather than inventing a second login. The full path from scaffold to app-catalog install is how to build an SPFx web part. Keep the SPFx version, Node version and generator version written down in the repo README so the next person can build the package.
Cautions and trade-offs
SPFx versions move slowly and are not interchangeable. A sample from the latest generator may not compile on an older tenant baseline. Upgrade on purpose; do not mix major versions inside one solution casually.
The code runs as the current user. It cannot bypass SharePoint permissions. That is a feature: a web part should not become a backdoor. It also means a part that needs broader access must call a backend, and that backend must enforce its own checks.
Bundles grow quickly if you import a large component library carelessly. Test in the workbench and on a real modern page; they are not identical. Tenant app-catalog deployment needs an admin. API permission requests for Graph sit unapproved until an admin consents. Finally, SPFx is not a place for business logic you cannot explain: if the part writes to a list, validate inputs and expect throttling when everyone on the intranet clicks at once.