What Happens When Radix, Floating UI, and MUI Join Forces?

Base UI isn’t just another “unstyled components” library. It’s a deliberate architectural synthesis — the first production-grade output of a formal collaboration between three foundational React infrastructure projects: Radix UI (primitives-focused, behavior-first), Floating UI (positioning engine for popovers, tooltips, menus), and Material UI (MUI) (design system scale, enterprise adoption, and component ergonomics). With 10,031 GitHub stars and active maintenance as of June 2026, it signals a quiet but decisive industry pivot: away from opinionated styling and toward composable, accessible, framework-agnostic primitives — all implemented in TypeScript and licensed MIT.

The Pain It Solves

Before Base UI, developers faced a tradeoff triangle:

• Radix gave you perfect ARIA compliance and behavioral correctness — but required manual positioning logic for overlays.
• Floating UI solved dynamic positioning flawlessly — but offered no component structure or keyboard navigation scaffolding.
• MUI delivered polished, production-ready components — but its styling layer and theming model made deep customization costly and accessibility guarantees harder to verify.

Base UI collapses that triangle. It ships pre-integrated Radix primitives with Floating UI positioning baked into components like Menu, Popover, Tooltip, and Select. And crucially, it does so without prescribing CSS-in-JS, class naming conventions, or theme abstractions — leaving styling fully in the developer’s hands while guaranteeing that every rendered element meets WCAG 2.1 AA requirements out of the box.

Key Architectural Decisions

At its core, Base UI is built on three interlocking layers, each inherited and refined from its parent projects:

1. Behavioral Primitives (Radix lineage)
   Every component starts with Radix’s @radix-ui/react-* packages — meaning automatic focus management, roving tab index, proper aria-expanded, aria-haspopup, and keyboard interactions (e.g., ArrowDown to open, Escape to close) are non-negotiable defaults. No custom hooks needed; it’s encoded in the render contract.

2. Dynamic Positioning (Floating UI lineage)
   Instead of rolling its own getBoundingClientRect()-based logic, Base UI uses @floating-ui/react under the hood — with sensible defaults (middleware: [offset(8), flip(), shift()]) and full escape hatches via floatingOptions. This means Popover automatically avoids viewport edges, flips orientation when space is constrained, and respects scroll boundaries — all without exposing low-level Floating UI APIs unless you need them.

3. Composition Model (MUI lineage)
   Unlike Radix’s strict “one component per use case”, Base UI adopts MUI’s pattern of split components: ButtonRoot, ButtonSlot, ButtonProps, and useButton — enabling both high-level convenience (<Button />) and granular control (<ButtonRoot /> + custom slots). This reflects MUI’s hard-won experience scaling design systems across thousands of internal consumers at Google and enterprise clients.

All components are implemented as zero-runtime, zero-dependency exports — meaning no bundler magic, no peer dependency footguns. You import only what you use (e.g., import { Button } from '@mui/base/Button'), and tree-shaking works reliably because each export is a standalone module with no shared context provider.

Typical Usage: A Realistic Example

Here’s how you’d build a fully accessible, styled-from-scratch dropdown menu — using only Base UI’s primitives, no CSS-in-JS, no theme providers:

import * as React from 'react';
import { Menu, MenuItem, MenuButton, MenuList } from '@mui/base/Menu';
import { Popper } from '@mui/base/Popper';
 
// Custom slot components — style-agnostic, behavior-guaranteed
const StyledMenuButton = React.forwardRef<HTMLButtonElement, React.ComponentProps<'button'>>(
  (props, ref) => (
    <button
      ref={ref}
      className="bg-blue-600 text-white px-4 py-2 rounded hover:bg-blue-700 focus:outline-none focus:ring-2 focus:ring-blue-400"
      {...props}
    />
  ),
);
 
const StyledMenuItem = React.forwardRef<HTMLLIElement, React.ComponentProps<'li'>>(
  (props, ref) => (
    <li
      ref={ref}
      className="px-4 py-2 cursor-pointer hover:bg-gray-100 focus:bg-gray-200 focus:outline-none"
      {...props}
    />
  ),
);
 
export default function DropdownExample() {
  return (
    <Menu>
      <MenuButton slots={{ root: StyledMenuButton }}>
        Options
      </MenuButton>
      <MenuList slots={{ list: 'ul', root: Popper }}>
        <MenuItem slots={{ root: StyledMenuItem }}>Edit</MenuItem>
        <MenuItem slots={{ root: StyledMenuItem }}>Delete</MenuItem>
        <MenuItem slots={{ root: StyledMenuItem }}>Share</MenuItem>
      </MenuList>
    </Menu>
  );
}

This example demonstrates Base UI’s composability: MenuButton handles click/toggle logic and ARIA state; MenuList renders inside a Popper (Floating UI-powered); MenuItem manages keyboard navigation and selection — all while letting you define exactly which DOM elements get which classes and behaviors.

Who It’s For

Base UI targets three overlapping audiences:

• Design system authors who need auditable, testable, accessible foundations — not just “styled components” but spec-compliant building blocks they can extend and brand without compromising conformance.
• Framework-agnostic library maintainers, especially those shipping React wrappers (e.g., for Svelte or Vue via adapters), who rely on stable, minimal, well-documented primitives.
• Enterprise frontend teams standardizing across dozens of apps — where consistency, auditability, and long-term maintainability outweigh short-term DX wins from opinionated styling.

It’s not for developers who want turnkey UIs — there’s no default theme, no createTheme() API, no built-in icons or typography helpers. But if your priority is guaranteeing that every interactive element passes axe-core audits, respects platform conventions, and remains trivial to restyle with Tailwind, vanilla CSS, or Emotion — then Base UI isn’t just an option. It’s the emerging consensus, codified.