Nicholas Lim | Blog | Prop-Based vs Utility-First React Component Libraries

React component libraries has reached a turning point. According to the 2024 State of React survey, "while MUI maintains in top rank in terms of usage, shadcn/ui is making huge gains, doubling from 20% to 42% in a year; as well as topping the positivity chart with 80%!" This shift signals two fundamentally different approaches to component styling: prop-based systems like MUI versus utility-class systems like Tailwind CSS.

The choice between these approaches affects not just how you write styles, but how you think about component composition, maintenance, and team collaboration.

Props vs Classes in React Styling

Approach	Description	Example Framework
Prop-based	Uses specialised props to apply styles directly to components	MUI (`sx` prop)
Class-based	Uses CSS utility classes applied to HTML elements	Tailwind CSS

The prop-based approach uses specialised props like MUI's sx prop to apply styles directly to components. This creates a direct connection between your styling intentions and the component, with styles defined as JavaScript objects passed through component props.

The class-based approach uses CSS classes, typically utility classes from frameworks like Tailwind CSS, applied to standard HTML elements or unstyled components. This leverages the traditional CSS class system but in a highly granular, utility-first manner.

Prop-Based Styling: The MUI Approach

MUI has long been a popular choice for React developers, offering a comprehensive suite of pre-styled components and a robust theming system. One of its core styling mechanisms involves using props, particularly the sx prop, to apply custom styles directly to components.

Advantages of Prop-Based Styling

Advantage	Description
Clarity of Style Source	Direct visibility into where styles are defined
Complete Design System	Comprehensive components with built-in theming
Type Safety	TypeScript integration for style properties

Clarity of Style Source: MUI's approach offers clear visibility into where styles come from. When you see an sx or style prop, you know exactly where the styling is defined. For instance, applying a blue background and white text to a Button is straightforward:

import Button from "@mui/material/Button";

function MyButton() {
  return (
    <Button
      sx={{
        backgroundColor: "blue",
        color: "white",
        "&:hover": { backgroundColor: "DarkBlue" },
      }}
    >
      Click Me
    </Button>
  );
}

This explicitness is a hallmark of the MUI approach, where the styling intent is co-located with the component's definition.

Complete Design System: MUI provides a comprehensive set of pre-styled components with consistent theming, accessibility features, and responsive behavior built-in. This reduces development time for teams that want production-ready components without custom design work.

Challenges of Prop-Based Styling

Challenge	Description
Complex Targeting	Requires knowledge of internal component structure
Variant-Specific Complexity	Different variants need different selectors

Complex Targeting: MUI components often have nested internal structures that require specific selectors to style effectively. For example, styling icons within buttons requires knowledge of MUI's internal class names like .MuiButton-startIcon.

import ArrowBackIcon from "@mui/icons-material/ArrowBack";
import ArrowForwardIcon from "@mui/icons-material/ArrowForward";
import Button from "@mui/material/Button";

function MyStyledButton() {
  return (
    <Button
      variant="contained"
      startIcon={<ArrowBackIcon />}
      endIcon={<ArrowForwardIcon />}
      sx={{
        // Styles applied here target the Button's root element by default.
        backgroundColor: "purple", // Clearly targets the button wrapper.
        marginTop: 2,

        // To style the start icon specifically, you need to know MUI's internal class names.
        "& .MuiButton-startIcon": {
          fontSize: 14, // Targets the start icon container.
          color: "yellow",
        },
        // To style the end icon differently, another specific selector is required.
        "& .MuiButton-endIcon": {
          fontSize: 13, // Targets the end icon container.
          color: "orange",
        },
      }}
    >
      Navigate
    </Button>
  );
}

The complexity deepens when we consider inheritance and cascading effects. If we apply a generic style like fontSize: 13 directly to the Button's sx prop, would it affect the button text, the icons, or both through CSS inheritance? This requires developers to have deep knowledge of MUI's internal component structure to predict styling outcomes accurately.

Variant-Specific Complexity: This problem is exacerbated when styling different variants of the same component. Each variant (contained, outlined, text) may have different internal structures and class combinations, requiring variant-specific knowledge and selectors. I find myself inspecting the component's DOM structure or MUI API Docs extensively to precisely target nested elements like .MuiButton-startIcon, .MuiButton-endIcon, or .MuiButton-loadingIndicator, which slows down the styling process.

For instance, targeting the start icon across different button variants would require selectors such as:

/* For contained variant */
& .MuiButton-contained .MuiButton-startIcon {
  /* styles */
}

/* For outlined variant */
& .MuiButton-outlined .MuiButton-startIcon {
  /* different styles */
}

This level of specificity demands intimate knowledge of MUI's internal architecture and can create brittle styling dependencies. I faced this specifically when trying to style the input fields in MUI's Autocomplete component.

MUI props are familiar to Mobile Developers

If you're coming from mobile development, MUI's props-based approach will feel immediately familiar. Consider Jetpack Compose's Modifier system:

// Jetpack Compose
Box(
    modifier = Modifier
        .padding(16.dp)
        .fillMaxWidth()
        .background(Color.Blue)
) {
    Text("Hello World")
}

// MUI (very similar mental model)
<Box
  sx={{
    p: 2,
    width: "100%",
    bgcolor: "primary.main",
  }}
>
  Hello World
</Box>

Both approaches use props / parameters to configure styling, making the transition between mobile and web development seamless. This paradigm also explains why React Native Paper pairs so naturally with MUI - they share the same mental model.

Now let's look at the alternative approach...

Class-Based Styling: Tailwind CSS and shadcn/ui

In contrast to prop-based systems, class-based styling with utility CSS frameworks like Tailwind CSS has gained immense popularity. Libraries like shadcn/ui further enhance this by providing unstyled or minimally styled components that developers can easily customise using Tailwind's utility classes.

Advantages of Class-Based Styling

Advantage	Description
Flexibility with Standard Elements	Direct styling of HTML elements without proprietary wrappers
Granular Control	Fine-tuned styling with utility classes
No Internal Structure Knowledge	Style what you see in the DOM

Flexibility with Standard Elements: Tailwind CSS eliminates the need for specialised layout components like MUI's Box. You can style standard HTML elements directly with utility classes. For example, creating a flex container with padding and a border is as simple as:

<div className="flex items-center justify-between rounded-lg border border-gray-300 p-4">
  <p className="text-lg font-semibold">Hello World</p>
  <button className="rounded bg-blue-500 px-4 py-2 text-white hover:bg-blue-700">Action</button>
</div>

This directness empowers developers to work with the grain of HTML, applying styles fluidly without needing to wrap elements in proprietary layout components.

Challenges of Class-Based Styling

Challenge	Description
Verbose Class Lists	Lengthy class strings that can exceed comfortable line limits
Repetition	Common utility combinations repeated across components
Learning Curve	Need to memorise utility class names

Verbose Class Lists: A common critique involves the potential for verbosity in class lists. Applying numerous utility classes to a single element can result in lengthy class strings that may exceed comfortable line limits, posing challenges to readability within code editors. An element with many specific styles might look like this:

<div
  className="flex items-center justify-between rounded-lg bg-gradient-to-r from-blue-500 via-indigo-500 to-purple-600 p-6 text-white shadow-lg transition-all duration-300 ease-in-out hover:scale-105 hover:shadow-2xl border border-white/20 ring-2 ring-blue-400/30"
>
  <!-- Content -->
</div>

*Note: While tools and editor extensions can help manage this, the sheer volume of classes can sometimes feel overwhelming, particularly for complex components.

Recommendations: New vs. Existing Projects

Choosing between these approaches often depends on the context of your project.

For New Projects

Consider Tailwind CSS in conjunction with a component library like shadcn/ui. The ecosystem is rapidly growing, community support is strong, and the availability of code examples and pre-built community components is constantly increasing. This modern stack is becoming a de facto standard in many parts of the React community.

The rapid adoption is evident in GitHub stars: shadcn/ui has garnered 88.5k stars, which is remarkably close to MUI's 95.9k stars, demonstrating significant community adoption and momentum behind the utility-first styling paradigm. Moreover, shadcn/ui's impressive retention rate of 92% compared to MUI's 50% suggests that developers who try shadcn/ui are much more likely to continue using it.

For Existing Projects

If your project is already established with MUI, migrating to a class-based system might not be worth the effort unless a complete ground-up rewrite is planned. Modern versions of MUI continue to evolve and work well with newer React features, including React Server Components. The stability and feature set of MUI can still provide a solid foundation for many applications.

TLDR

Project Type	Recommendation	Rationale
New Projects	Tailwind CSS + shadcn/ui	Modern stack with strong community momentum
Existing MUI Projects	Continue with MUI	Migration cost may not justify benefits

Conclusion

The choice between prop-based and class-based styling reflects different philosophies about component composition. MUI's prop-driven approach keeps styling explicit and close to component logic, while Tailwind's utility-first approach provides granular control over standard HTML elements.

Neither approach is inherently superior as each serves different needs. MUI excels at providing comprehensive, accessible components out of the box. Tailwind offers maximum flexibility for custom designs without predefined constraints.

The decision depends on your project context: starting fresh favors modern utility-first approaches, while existing codebases may benefit from staying with established systems. Both approaches will continue serving different segments of the React community as the ecosystem evolves.