Theming, tokens and brand reach: MUI vs shadcn/ui vs Mantine vs Base UI in 2026

Decision. For a Tailwind-4-native, multi-app design system (itenium-ui), only shadcn/ui and Base UI make the Tailwind @theme block the source of truth for brand tokens — everything else is downstream of a JS object. Since shadcn/ui switched its default primitive to Base UI in July 2026 [1], the two are now the same substrate with a different amount of pre-written CSS: shadcn = Base UI + an opinionated token layer you own. Mantine is the strongest “batteries-included” option that still emits real CSS variables, but its token names are Mantine’s, not yours. MUI bends furthest to a brand and hardest against Tailwind 4: its tokens originate in a JS createTheme object and only reach CSS variables through a hand-maintained bridge file [2].

The one question that decides it

Tailwind 4 has no JS config. Design tokens are declared in CSS with @theme, and each theme variable is simultaneously a CSS custom property and a generated utility class — --color-brand: #3f3cbb produces bg-brand, text-brand, border-brand [3]. A plain :root { --brand: … } gets you the variable but no utility.

So the axis is: where does the token live?

The “bridge” is the same trick in both directions — @theme inline { --color-primary: var(--mui-palette-primary-main); } [2] — but it means the brand palette is defined twice: once in TypeScript so the components see it, once in CSS so Tailwind can mint utilities. Drift is a matter of when, not if.

The 2026 realignment you have to price in

• Base UI 1.0 shipped 11 Dec 2025 with 35 accessible unstyled components and a maintenance commitment; the package renamed to @base-ui/react [8].
• shadcn/ui made Base UI the default primitive in July 2026 — npx shadcn init picks Base UI, docs open on the Base UI tab, Radix stays supported [1].
• MUI paused Pigment CSS (its zero-runtime CSS-in-JS successor) to concentrate on Base UI; Material UI v8 is still only “drafting and shaping” [9]. Material UI’s theming model in 2026 is therefore the v7 model plus a CSS-variables mode, not a rewrite.

Practical consequence for itenium-ui: “shadcn/ui vs Base UI” is no longer a fork in the road — it’s a decision about how much of the token/CSS layer you write yourself versus adopt from shadcn’s registry and then own.

Per-kit token model

shadcn/ui — tokens are the product

Semantic background/foreground pairs (--primary + --primary-foreground, --card, --muted, --destructive, --border, --ring, --sidebar-*, --chart-1..5), declared in oklch() under :root and re-declared under .dark, then exposed to Tailwind through @theme inline [4]. A single --radius base derives sm/md/lg/xl via calc(). Adding a brand token is three lines: define under :root and .dark, add to @theme inline, get bg-warning for free [4].

Brand distribution is a first-class feature: a registry item carries cssVars: { theme, light, dark } plus raw css (@layer base, @utility, @keyframes), and item types registry:theme / registry:style exist specifically to ship a design system [10]. That is precisely the itenium-ui shape: a private registry publishing the Itenium token set + component set to N apps.

⚠ The escape hatch is also the tax: you own the component source, so a shadcn upgrade is a diff against files you have edited. Note also that shadcn now distinguishes styles from themes — “Rhea” (May 2026) is a denser style that adjusts component sizes/gaps directly rather than moving Tailwind’s --spacing multiplier, explicitly so that p-2 keeps meaning the same thing app-wide [11]. That is the right instinct to copy for a corporate density mode.

Base UI — no tokens, no theme, no opinion

className (string or a function of component state), state data-attributes ([data-checked], [data-open]), a style prop, and a handful of layout CSS variables like --available-height / --anchor-width on Popover [5]. There is no theme object, no dark mode, no color token — dark mode is whatever you write, e.g. Tailwind’s dark: variant [5]. Brand reach is unlimited because there is nothing to bend. Multi-brand is “whatever your CSS does”. Typed theme augmentation is not a concept — your tokens are typed by whatever you build (or not at all).

Mantine — JS theme, CSS-variable output

MantineProvider takes a theme object; cssVariablesResolver: (theme) => ({ variables, light, dark }) lets you rewrite Mantine’s variables and add your own, with automatic scheme switching [6]. Mantine emits a broad, well-named surface: --mantine-color-{name}-{0..9}, --mantine-spacing-*, --mantine-radius-*, --mantine-shadow-*, --mantine-font-*, z-index layers [6].

Brand colors must be 10-shade tuples — fewer and you get a TypeScript error [12]. generateColors / colorsTuple synthesise the ramp from one hex, and virtualColor({ name, light, dark }) maps one semantic name onto different ramps per scheme [12]. primaryShade: { light: 6, dark: 8 } picks the shade per scheme [12].

The deepest brand hook is theme.variantColorResolver — a function returning { background, hover, color, border } that governs how every color-aware component (Button, Badge, ActionIcon, ThemeIcon, Alert, Avatar) renders each variant, and can define entirely new variants [13]. That is genuinely more expressive than MUI’s per-component styleOverrides for the “our brand has a weird tertiary button” problem.

Material UI — deepest bend, heaviest coupling

Three override layers in createTheme: defaultProps, styleOverrides keyed by slot with nested selectors, and a variants: [{ props, style }] array for prop-conditional styling; ownerState callbacks in styleOverrides are now discouraged in favour of variants [14]. Per-instance escape is sx and slotProps. Custom variants and custom palette colors require TypeScript module augmentation to typecheck [14].

cssVariables: true turns the theme into --mui-* custom properties, auto-generates channel tokens for alpha compositing, lets you rename or drop the prefix via cssVarPrefix, and swaps runtime palette.mode checks for theme.applyStyles() [7]. It’s a real improvement — but the CSS variables are an output, not an input. Tailwind cannot see them until you write the bridge, and the token names are MUI’s taxonomy (palette.primary.main), not DTCG’s.

Dark mode

⚠ The MUI default is the trap. Out of the box MUI keys dark mode off prefers-color-scheme while Tailwind keys off .dark. A user who toggles your app to dark gets Tailwind-styled surfaces flipping and MUI-styled surfaces not. Fix: createTheme({ cssVariables: { colorSchemeSelector: 'class' } }).

Design-token pipeline (Style Dictionary / Tokens Studio / DTCG)

The DTCG Format Module is JSON with $value / $type / $description, .tokens.json files, {group.token} aliases and composite tokens [18]. It is still a Community Group draft — the June 2026 editor’s draft carries an explicit “do not implement this version” preview banner [18] — but tooling has converged anyway: Style Dictionary v4 has first-class DTCG support ($value/$type vs the legacy value/type; you may not mix the two in one instance) [19] ⭐ 4.7k.

Style Dictionary ships both output shapes: css/variables (a :root block of custom properties) and javascript/es6 / javascript/module / TypeScript declarations [20]. So every kit here is technically feedable. The difference is how many hops:

Tailwind 4 also gives the monorepo its distribution mechanism for free: a brand theme is a plain CSS file (@theme { --color-itenium-500: …; }) that any app @imports [3]. No JS package, no provider, no bundler coupling. For an Nx library publishing a design system, that is a materially simpler artifact than an exported Theme object.

Per-component override ergonomics and escape hatches

Multi-brand / white-label

Typed theme augmentation

⚠ This is the one axis where MUI and Mantine genuinely beat the CSS-variable kits: a typo in --color-brnd is a silent no-op in Tailwind, whereas theme.colors.brnd is a compile error. Mitigation for a CSS-first stack: generate a .d.ts of allowed token names from the same .tokens.json Style Dictionary build [20], and lint class names.

Where each model fights a Tailwind-4-native token setup

Material UI — three distinct fights: (1) tokens are born in JS, so Tailwind can’t mint utilities from them without the hand-written @theme inline bridge listing every palette/typography/shadow token [2]; (2) you must enable enableCssLayer: true and declare @layer theme, base, mui, components, utilities; or Tailwind utilities lose to Emotion’s runtime styles [2]; (3) the default prefers-color-scheme dark mode desyncs from Tailwind’s .dark [7][15].

Mantine — one fight, two chores: under Tailwind 4, Mantine’s own styles win over Tailwind utilities unless the layer order is fixed (community-recommended theme → base → mantine → components → utilities), a regression relative to Tailwind 3 [25]; and --mantine-color-* variables must be re-declared inside @theme to become bg-* utilities. Mantine’s dark mode is a data-* attribute, so Tailwind needs @custom-variant dark [15].

shadcn/ui — no fight; it is the Tailwind 4 token model. The only friction is the one it creates: styles vs themes vs --spacing scale (Rhea’s density problem) [11].

Base UI — no fight; also no help.

What this means for itenium-ui

A publishable Nx library carrying the Itenium brand, consumed by multiple apps, on Tailwind 4:

• Brand tokens should be a CSS file — @theme in a libs/itenium-tokens package, generated by Style Dictionary from .tokens.json [19][3]. Every consuming app @imports it; no provider, no JS coupling.
• shadcn/ui on Base UI (its 2026 default [1]) means one primitive layer, tokens in the currency your build already speaks, and a registry mechanism designed for exactly the “ship a branded component set to N apps” job [10].
• Mantine is the fallback if the team wants a theme object and a large component set out of the box and will accept duplicating the token names into @theme plus a layer-order fix [25].
• MUI buys the deepest per-component override surface and the best TypeScript story, at the price of a permanently double-maintained token definition and a cascade you have to keep negotiating with [2].