Fluent UI by Microsoft

Fluent is best understood as a language with several native speakers, not as a component library with ports. Microsoft maintains a React implementation, a web components implementation, Swift and Kotlin libraries, and WinUI for Windows, and Fluent 2 is the design language they all target. That structure is the main thing worth studying here, and also the main cost of adopting it.

Tokens carry the language Fluent's token system has two layers, and the split is doing real work. Global tokens store raw values with no context: this hex code, this radius, this stroke width. Alias tokens sit on top and say what a value is for, and for shadows and type they condense a bundle of values into a single named token. Because components consume alias tokens, Microsoft can ship light, dark, high-contrast, and branded themes as token sets rather than component variants, and the Figma side mirrors the same structure: the Fluent 2 design language file holds the global and alias variables, so a designer toggling a Figma file between light and dark is using the same mechanism a developer gets from swapping a theme. Most systems claim design and code share tokens; Fluent's two-layer model is one of the clearer public examples of how that is actually organised.

The web story is React v9, with a second door New web work starts with Fluent UI React v9. The install is one suite package, @fluentui/react-components, which re-exports the per-component packages, and the setup is a FluentProvider with a theme at the root of the app. Styling runs through Griffel, a CSS-in-JS engine that renders styles and inserts CSS when needed; styles are written as JavaScript objects beside the component, which keeps them scoped and type-checked, and asks the team to learn that model instead of plain CSS. Teams that are not on React are not locked out, but they take the second door: @fluentui/web-components, custom elements built on FAST Element, themed by setting token CSS variables. It is a real implementation, not a wrapper, which also means its component coverage and documentation are their own thing to evaluate.

The honest costs Three of them. First, per-platform means per-platform: an organisation shipping web, iOS, and Android maintains three Fluent codebases that share tokens and guidelines, not code. Second, the v8 to v9 move is a migration, with its own documented topic, not a version bump; a large @fluentui/react codebase should budget for it as a project. Third, licensing needs one careful read: the code is MIT, but Microsoft's notices carve out the fonts and icons the components reference under separate asset terms, so a team shipping a product should not treat the MIT file as the whole answer.

Bottom line Building a product that should feel at home next to Microsoft 365 and Teams, or a multi-platform product that needs one design language with native implementations? Fluent 2 is a strong public option, and its token architecture is worth studying even if you adopt nothing else. Building a single-platform web app with a strong brand of its own? You will use a fraction of this system and carry its styling model and visual identity anyway, so weigh lighter libraries first.