Tailwind CSS vs. StyleX: A real migration with 20 components

I wanted a practical answer to a question that usually gets handled as a vibes-based framework debate: What actually changes when you migrate a real Tailwind component library to StyleX?

So I built 20 production-style components in Tailwind CSS, rewrote all 20 in StyleX using the newer sx={} prop syntax, and tracked the parts that matter in a real migration: lines of code, CSS output, build time, configuration work, and the issues that slowed me down.

The short version: StyleX doubled my styling code, produced almost the same CSS bundle size, built slightly faster in this test, and caught styling mistakes that Tailwind would have let through silently. Whether that trade-off is worth it depends on what you are building.

If you maintain a design-system-backed component library, StyleX is worth a serious look. If you are building quickly with copy-paste components, Tailwind is still hard to beat.

Tailwind vs. StyleX: The migration results

Before getting into the setup, here are the results from the migration:

Metric	Tailwind	StyleX	What changed
Component LOC	1,568	3,143	StyleX added 100.5 percent more code
CSS output	20,379 bytes	20,561 bytes	Nearly identical
Median cold build	8.0s	7.4s	No meaningful difference in this test
Type safety	Mostly string-based classes	Typed style objects and tokens	StyleX caught several migration mistakes earlier
Ecosystem	Large public ecosystem	Smaller public ecosystem	Tailwind has the clear ecosystem advantage

These numbers changed how I thought about the migration. StyleX did not win because it made the code smaller. It won in the places where static analysis matters: typed tokens, invalid variants, dead style elimination, and predictable composition.

That is the real decision point. StyleX costs more code and more setup. In exchange, it gives you a stricter styling system for large, reusable component libraries.

Why the sx={} prop changes the StyleX comparison

StyleX has been Meta’s internal styling system for years and now powers large-scale products across Meta. It was open sourced at the end of 2023 and is designed around static CSS extraction, atomic CSS output, type-safe style authoring, and predictable style composition.

For a long time, the biggest objection was developer experience. The old StyleX syntax looked like this:

return (
  <button
    {...stylex.props(styles.base, styles[variant], styles[size])}
  >
    {children}
  </button>
);

That works, but it is not especially inviting. The spread syntax hides the styling mechanism, and compared with Tailwind’s className="flex items-center", it feels heavier than it should.

With the newer sx={} prop syntax, the same component reads like this:

return (
  <button sx={[styles.base, styles[variant], styles[size]]}>
    {children}
  </button>
);

The Babel plugin transforms sx={} into the same kind of output as stylex.props() at build time. The main difference is what you read and write every day. Instead of spreading a helper into every element, you pass styles through a prop that behaves like the rest of your React API.

That change does not make StyleX as terse as Tailwind. But it closes enough of the syntax gap that the comparison becomes more interesting. Now the question is less “Which syntax is less annoying?” and more “Do I want string-based speed or compile-time styling guarantees?”

My migration setup

I built the original component library in Tailwind CSS inside a Next.js app with TypeScript, then migrated each component to StyleX. The components included buttons, badges, cards, modals, tabs, navbars, data tables, form inputs, toggles, alerts, skeletons, toasts, breadcrumbs, and layout primitives.

The stack:

Tool	Version used
Next.js	16.2.9 with webpack
StyleX	0.19.0
Tailwind CSS	4.3.2
TypeScript	5.9.3

Each component had at least two visual variants, responsive behavior, and interactive states. I tracked four things:

• Lines of code
• CSS output size
• Cold build time
• Migration issues by component

This was not a synthetic benchmark of one button. It was also not a massive enterprise design system. It sat in the middle: enough components to expose real migration friction, but small enough to inspect every difference by hand.

Four setup decisions before writing StyleX styles

Getting Tailwind and StyleX to coexist took a few decisions before the component work started. These are worth calling out because they affect the migration experience as much as the component syntax does.

1. Webpack and Babel instead of Turbopack

This setup used webpack with the StyleX Babel plugin. In my project, adding a custom babel.config.js meant opting into Babel for the relevant transforms. That also meant accepting the trade-offs of that setup, including losing access to some Next.js compiler-specific features I would normally reach for.

For this migration, I used system font stacks instead of next/font.

2. The PostCSS plugin instead of the deprecated Next.js plugin

I used @stylexjs/postcss-plugin with @stylexjs/babel-plugin rather than @stylexjs/nextjs-plugin. The Next.js-specific StyleX plugin is deprecated, so the PostCSS/Babel setup is the safer path for a new migration.

3. The sx={} prop everywhere

I used sx={} throughout the migration rather than the older {...stylex.props()} syntax. To make TypeScript recognize the prop, I added a src/types/stylex.d.ts file that patches HTMLAttributes.

That gave me a consistent authoring style without needing a JSX pragma, jsxImportSource, or a React 19-specific setup.

4. CSS layers for Tailwind and StyleX coexistence

Both Tailwind and StyleX emit CSS, so I used CSS layers to make the ordering explicit. Setting useCSSLayers: true in the StyleX PostCSS config wraps StyleX output in named @layer blocks.

That let both systems live in globals.css without accidental specificity conflicts.

Here is the Babel config:

const path = require('path');
const dev = process.env.NODE_ENV !== 'production';

module.exports = {
  presets: ['next/babel'],
  plugins: [
    [
      '@stylexjs/babel-plugin',
      {
        dev,
        runtimeInjection: false,
        treeshakeCompensation: true,
        aliases: { '@/*': [path.join(__dirname, 'src/*')] },
        unstable_moduleResolution: { type: 'commonJS', rootDir: __dirname },
      },
    ],
  ],
};

And the PostCSS config:

const babelConfig = require('./babel.config');

module.exports = {
  plugins: {
    '@stylexjs/postcss-plugin': {
      include: ['src/**/*.{js,jsx,ts,tsx}'],
      babelConfig: {
        babelrc: false,
        configFile: false,
        parserOpts: { plugins: ['typescript', 'jsx'] },
        plugins: babelConfig.plugins,
      },
      useCSSLayers: true,
    },
    autoprefixer: {},
  },
};

Once these decisions were locked, the rest of the work became a component-by-component conversion.

Where StyleX won

StyleX did not win on terseness. It won where the styling layer needed to behave more like typed application code.

Type-safe design tokens

stylex.defineVars() gives you typed design tokens with IDE autocomplete. If you misspell a token, TypeScript catches it before the component renders.

In my migration, I created a src/tokens/ directory with separate token files:

// colors.stylex.ts
import * as stylex from '@stylexjs/stylex';

export const colors = stylex.defineVars({
  primary: '#2563eb',
  primaryHover: '#1d4ed8',
  textDefault: '#111827',
  textMuted: '#6b7280',
  borderDefault: '#e5e7eb',
  // 40+ more tokens
});

The payoff shows up immediately in components. If I write backgroundColor: colors.primaryy, TypeScript rejects it. In Tailwind, a class like bg-blue-60 can compile and fail silently in the UI.

Self-referencing variables also reduce token duplication. For example, you can derive a muted text color from a base text color with color-mix(), so one token update can cascade through related values.

Dead CSS elimination

StyleX strips unused styles at compile time. There is no PurgeCSS config, no safelist, and no wondering why an unused class is still in the output.

I tested this directly. Every StyleX component in the migration included a _deadStyles object that was never referenced:

const _deadStyles = stylex.create({
  neverUsed: {
    backgroundColor: 'hotpink',
    padding: '999px',
  },
});

After building, those dead styles did not appear in the CSS output. With treeshakeCompensation: true, unreferenced stylex.create() calls were stripped entirely.

Tailwind gets to a similar result from the opposite direction: it scans your source for utility classes and generates only what it finds. Both systems can eliminate unused CSS. The difference is the model. Tailwind scans markup; StyleX analyzes style objects at compile time.

Compile-time constants with stylex.env

StyleX also supports compile-time constants through stylex.env, which is useful for feature flags, platform checks, and debug-only styles.

Here is the pattern:

// stylex.env.ts
export const DEBUG_MODE = process.env.DEBUG_STYLEX === 'true';
export const PLATFORM = process.env.PLATFORM || 'web';

Then in a component:

import { DEBUG_MODE } from '@/stylex.env';

if (DEBUG_MODE) {
  var debugStyles = stylex.create({
    outline: { outline: '2px solid red' },
  });
}

return (
  <div sx={[styles.base, ...(DEBUG_MODE ? [debugStyles.outline] : [])]}>
    {children}
  </div>
);

When DEBUG_STYLEX=true, the debug styles are included. In production, the branch can be eliminated. Tailwind can conditionally apply classes at runtime, but if those classes appear in source, they are still candidates for generation.

More explicit variant styling

The biggest difference showed up in variant-heavy components. Here is a simplified button example in Tailwind:

const variantStyles = {
  primary: 'bg-blue-600 text-white hover:bg-blue-700 focus:ring-blue-500',
  secondary: 'bg-gray-200 text-gray-900 hover:bg-gray-300 focus:ring-gray-500',
};

const sizeStyles = {
  sm: 'px-3 py-1.5 text-sm',
  md: 'px-4 py-2 text-base',
  lg: 'px-6 py-3 text-lg',
};

const combinedClassName =
  `${baseStyles} ${variantStyles[variant]} ${sizeStyles[size]}`.trim();

return <button className={combinedClassName}>{children}</button>;

It is compact, but the styling contract is mostly string-based. If a variant key is wrong, the bug may not show up until runtime.

Here is the same pattern with the newer StyleX syntax:

const styles = stylex.create({
  base: {
    display: 'inline-flex',
    alignItems: 'center',
    borderRadius: spacing[2],
  },
  primary: {
    backgroundColor: colors.primary,
    color: colors.white,
  },
  secondary: {
    backgroundColor: colors.gray200,
    color: colors.gray900,
  },
  sm: {
    paddingInline: spacing[3],
    paddingBlock: spacing[1.5],
    fontSize: typography.sm,
  },
});

return (
  <button sx={[styles.base, styles[variant], styles[size]]}>
    {children}
  </button>
);

It is longer, but invalid tokens and style keys are easier to catch. That is the repeated trade-off across the migration: Tailwind is shorter; StyleX is stricter.

Where Tailwind still wins

The migration also made Tailwind’s strengths clearer. StyleX won on correctness, but Tailwind still wins in several areas that matter in day-to-day product work.

Prototyping speed

Tailwind is still faster for throwaway UI and fast iteration. You stay in JSX, add utility classes inline, and see changes quickly.

StyleX requires defining styles in a stylex.create() call before referencing them, even with sx={}. That extra step is reasonable in a component library, but it slows down one-off UI work.

Ecosystem

Tailwind has a massive public ecosystem: shadcn/ui, Headless UI, Radix-based examples, Tailwind component libraries, templates, snippets, tutorials, and thousands of copy-paste components.

StyleX has strong internal adoption at Meta and growing public adoption, but the public ecosystem is much smaller. If you adopt StyleX today, you should expect to build more of your component system yourself.

Learning curve

Tailwind’s mental model is easy to pick up: utilities map directly to CSS properties.

StyleX requires developers to understand a few more constraints:

• Style objects must be statically analyzable
• Token imports need to follow the compiler’s expectations
• Dynamic keys often need explicit maps
• Conditional styles need to produce valid StyleX style objects
• CSS layer ordering matters when StyleX coexists with another CSS system

None of that is impossible, but it is a real onboarding cost.

Community content

When you hit a Tailwind issue, there is usually a GitHub discussion, Stack Overflow answer, Discord thread, or tutorial somewhere. This is similar to the kind of robust community support you get with well-established React chart libraries versus newer alternatives.

With StyleX, you are more likely to read official docs, source code, or examples from early adopters. That is improving, but it is not the same support surface.

Migration issues I hit

These are the issues that cost me time during the migration. They are the kind of details that rarely show up in a quick hello-world example.

Barrel exports broke token resolution

This was the most painful discovery. I started with a clean token architecture: four .stylex.ts files re-exported through a barrel index.ts. Every import looked like this:

import { colors, spacing } from '@/tokens';

The build failed. The StyleX Babel plugin performs static analysis on token resolution, and in this setup it needed to see the actual stylex.defineVars() call at the import path.

The fix was direct imports:

// This broke the build
import { colors, spacing } from '@/tokens';

// This worked
import { colors } from '@/tokens/colors.stylex';
import { spacing } from '@/tokens/spacing.stylex';

Seven components needed this fix. If you are migrating, skip the token barrel export and import from .stylex.ts files directly from the start. Tools like Knip can help identify unused and ghost dependencies in your project before you begin a migration like this.

Raw inline @keyframes did not belong in stylex.create()

Skeleton and Toast components failed when I tried to define raw @keyframes blocks inside stylex.create(). That pattern works in some CSS-in-JS libraries, but it was the wrong StyleX API.

The right fix is to use stylex.keyframes() when the animation can be expressed through StyleX, or keep complex/global animation definitions in a regular CSS file. The important lesson is not “StyleX cannot do keyframes,” because it can. The lesson is that keyframes have a specific API and cannot be dropped into a style object as raw CSS.

Dynamic style keys needed explicit maps

TypeScript cannot infer that a computed string like this will match a literal key on the style object:

styles[`modal${size}`]

Eight components hit this issue.

The fix is a type-safe map:

// This fails TypeScript
return <div sx={[styles.modal, styles[`modal${size}`]]} />;

// This passes
const sizeStyleMap = {
  sm: styles.modalSm,
  md: styles.modalMd,
  lg: styles.modalLg,
};

return <div sx={[styles.modal, sizeStyleMap[size]]} />;

It is more verbose, but it catches invalid size values before they become broken styles. If you find yourself reaching for advanced TypeScript patterns here, the TypeScript utility types you may be underusing are worth reviewing before you start your migration.

Falsy values did not work in sx arrays

Tailwind developers often use && shorthand for conditional classes:

`${isActive && 'bg-blue-500'}`

In this StyleX setup, passing false into an sx array caused a TypeScript error because the prop expected style objects, not booleans.

I had to build arrays conditionally:

// This fails
<tr sx={[styles.tr, isStriped && styles.trStriped]} />;

// This works
const trStyles = [styles.tr];

if (isStriped) {
  trStyles.push(styles.trStriped);
}

<tr sx={trStyles} />;

This is small in isolation, but it affects almost every component with conditional styling.

CSS layer ordering was strict

My first build failed because globals.css had @layer declarations before the @import "tailwindcss" statement.

Webpack enforced the CSS spec strictly: @import rules must come before all other rules except @charset and @layer. Moving the Tailwind import to the top fixed the build, but the error message was not especially clear.

The real numbers

Here is where the migration became less subjective.

Lines of code

The following table shows the lines of code per component:

Component	Tailwind LOC	StyleX LOC	Growth
Container	31	118	+280%
Grid	43	121	+181%
Navbar	129	291	+126%
Modal	104	226	+117%
Stack	57	123	+116%
TextInput	76	167	+120%
Select	153	293	+92%
DataTable	128	245	+91%
Card	91	141	+55%
Skeleton	61	95	+56%
Total, 20 components	1,568	3,143	+100.5%

StyleX doubled the codebase. Most of the growth came from explicit style maps and responsive styles written as full objects instead of Tailwind’s compact responsive prefixes.

The important nuance is that component logic did not double. Event handlers, state, and conditional rendering stayed mostly the same. The extra lines were styling definitions. The growth was predictable and mechanical, but it was still real.

CSS bundle size

The following table shows the CSS output comparison:

Scenario	CSS output
Tailwind only	20,379 bytes
StyleX only	20,561 bytes

The CSS output was almost identical. Tailwind generated utility classes; StyleX generated atomic CSS rules. For this 20-component library, neither produced a meaningful bundle-size advantage.

Build time

The following table shows the build time comparison:

Framework	Median cold build, 3 runs
Tailwind only	8.0s
StyleX only	7.4s

There was no meaningful build-time difference. StyleX’s Babel setup adds compilation work, but in this project the final build time still landed in the same range.

I would not use this result to claim StyleX is faster than Tailwind. I would use it to say that, for this component set, StyleX did not add a build-time penalty large enough to affect the decision.

Where each tool fits

StyleX is not a faster, smaller, simpler Tailwind. It solves a different problem.

Need	Tailwind	StyleX
Fast prototyping	Excellent	More boilerplate
Type-safe styling at scale	Requires extra tooling and discipline	Built in
Unused CSS elimination	Strong with content scanning	Strong with compile-time extraction
Design token safety	Mostly string/config-driven	Typed variables and constants
Runtime style merging	Manual className composition	Compiled/merged through StyleX
Public ecosystem	Very strong	Still smaller
Reusable component libraries	Good, but string-heavy	Strong fit when consumers also use StyleX

Use StyleX for design-system-backed production apps where type safety, token consistency, and predictable style composition matter more than raw speed. If your team maintains a shared component library and has been burned by silent styling bugs, the extra LOC may be a reasonable price.

Use Tailwind for prototypes, content sites, marketing pages, and teams that benefit from the Tailwind ecosystem. If you are shipping quickly with shadcn/ui, Headless UI, and existing Tailwind patterns, StyleX’s safety may not justify the migration cost.

They are not really competing for the same job. Tailwind wins on speed and ecosystem. StyleX wins on correctness and safety. The sx={} prop makes StyleX comfortable enough that the decision can finally be about project needs instead of syntax alone.

What I would change in the migration plan next time

If I were doing this migration again, I would make a few changes up front:

• Start with the most variant-heavy components, not the simplest ones
• Add token files early and import them directly, not through barrels
• Decide the CSS layer order before migrating components
• Write a small conditional-style helper for repeated sx array patterns
• Use stylex.keyframes() for animations instead of trying to copy CSS-in-JS patterns directly
• Keep Tailwind available during migration so each component can be compared before the old version is removed
• Track mistakes caught by TypeScript, not just bundle size and build time

That last point matters most. If you only track bundle size, this migration looks like a wash. If you track how many styling mistakes are caught before runtime, StyleX starts to look more valuable. This same principle applies broadly: when React Compiler handles memoization, you also need to look beyond surface metrics to understand what actually changed.

Conclusion

I expected StyleX to win on bundle size and lose on everything else. That is not what happened.

Bundle size was a wash. Build time was a wash. The metric that actually separated the two was type safety. During the migration, TypeScript caught misspelled token names, invalid variant keys, and broken conditional style arrays before anything rendered in the browser. In the Tailwind versions, those mistakes would have been easier to ship silently.

So the decision point is straightforward: Is that safety worth doubling your styling LOC, making several setup decisions before writing a single component, and building more of your component ecosystem yourself?

For a production component library, especially one with shared tokens and lots of variants, I think StyleX has a real argument. For a small team moving quickly with existing Tailwind patterns and public component libraries, Tailwind is still the better tool.

The sx={} prop is what makes this a real choice. Before it, the developer experience gap made the comparison easier to dismiss. Now the trade-off is clearer: Tailwind gives you speed and ecosystem. StyleX gives you stricter guarantees. Pick the one that matches the cost you are actually trying to reduce. If you are evaluating other modern CSS approaches as well, it is worth exploring how CSS contrast-color() handles auto-contrast and how CSS staggered animations work as part of a broader styling strategy.