No Arbitrary Selectors#

StyleX explicitly forbids styling child elements. You cannot write:

1
// THIS IS NOT ALLOWED IN STYLEX
2
const styles = stylex.create({
3
  container: {
4
    '> p': {
5
      color: 'blue', // ❌ Forbidden
6
    },
7
  },
8
});

This is a philosophical decision: styling “at a distance” is considered problematic. But in practice, it’s crippling.

Real-world example: A form where the last row has no margin-bottom.

In normal CSS:

1
form > div:last-child {
2
  margin-bottom: 0;
3
}

In StyleX, you must create a wrapper component or pass a prop to each element. This adds boilerplate and breaks component abstraction.

StyleX doesn’t support:

• :first-child, :last-child, :nth-child()
• Sibling combinators (+, ~)
• Attribute selectors ([data-*])
• Many pseudo-elements

These are fundamental CSS features, removed in the name of “static resolvability.”

Parent-Child Hover Is a Nightmare#

Something as simple as “when the parent is hovered, style the child” becomes a multi-file ordeal:

In CSS:

1
.parent:hover .child {
2
  opacity: 1;
3
  transform: translateY(0);
4
}

In StyleX, you need to:

1. Track hover state in React
2. Pass it as a prop to child components
3. Apply conditional styles based on that prop

What was one line of CSS becomes 20+ lines of JavaScript boilerplate.

Debugging Hell#

StyleX creates atomic classes for every declaration. A simple button generates:

1
<button class="x1abc x2def x3ghi x4jkl x5mno x6pqr x7stu ...">

In DevTools, finding which class does what is detective work. But it gets worse.

StyleX sometimes generates :not(#\#) selectors as a polyfill for CSS cascade layers. While these gzip well, they make debugging in browser DevTools nearly impossible.

Static-Only Limitations#

stylex.create() cannot be used at runtime. All styles must be statically analyzable and compiled away. This means:

• No truly dynamic styles based on runtime props
• CSS variables are the only escape hatch
• You’re constantly working around the system

Ecosystem Immaturity#

StyleX was open-sourced in December 2023. Compared to mature tools:

• Smaller community
• Less documentation for edge cases
• Fewer IDE plugins and tooling
• Limited third-party examples

1. Doesn’t Limit Native CSS Features#

A good tool should enhance CSS, not restrict it. I want access to:

• Container queries
• @scope
• Native nesting
• @property
• All selectors (:has(), :nth-child(), sibling combinators)

Any tool that says “you can’t use fundamental CSS features” is a red flag.

2. Allows Component Organization#

I want to colocate styles with components. Whether that’s:

• CSS Modules
• CSS-in-JS that compiles to static CSS
• Scoped CSS files

The key is organization, not runtime overhead.

3. Static CSS at Build Time#

Runtime CSS generation (like older styled-components) adds JavaScript overhead. I prefer tools that compile to static CSS:

• Zero runtime performance impact
• Better caching
• Smaller JavaScript bundles

4. Smart Optimization#

A great tool should:

• Remove unused CSS (tree-shaking)
• Deduplicate styles (atomic CSS is fine for this)
• Integrate with IDE (autocomplete, type checking)
• Generate source maps for debugging

5. Doesn’t Require Learning a New Language#

This is lower priority, but matters. Features like Sass variables ($color) or loops (@for) were useful when CSS lacked them. Now CSS has:

• Native variables (var(--color))
• Native nesting
• calc() for math

Preprocessor-specific syntax adds cognitive overhead without proportional benefit.

Linaria: The Better StyleX#

If you want the benefits of StyleX (zero-runtime, type-safe, component colocation) without its crippling limitations, Linaria is the answer.

1
import { css } from '@linaria/core';
2
import { styled } from '@linaria/react';
3

4
// CSS tag for class names
5
const button = css`
6
  padding: 0.5rem 1rem;
7
  background: #0066cc;
8

9
  &:hover {
10
    background: #0044aa;
11
  }
12

13
  /* Child selectors work! */
14
  & > .icon {
15
    margin-right: 0.5rem;
16
  }
17

18
  /* :last-child works! */
19
  &:last-child {
20
    margin-bottom: 0;
21
  }
22
`;
23

24
// Styled components syntax
25
const Container = styled.div`
26
  display: flex;
27

28
  /* Parent-child hover - ONE LINE, not 20 */
29
  &:hover .child {
30
    opacity: 1;
31
    transform: translateY(0);
32
  }
33
`;

What Linaria gets right:

Linaria compiles to regular CSS files. No atomic class explosion. No :not(#\#) nightmare. Just… CSS.

The trade-off? Linaria doesn’t have StyleX’s strict architectural constraints. But for 99% of projects, those constraints are the problem, not the solution.

PostCSS#

The plugin-based approach. You add only what you need:

• Autoprefixer for vendor prefixes
• cssnano for minification
• postcss-preset-env for future CSS features

PostCSS doesn’t limit what CSS you can write—it enhances it.

Lightning CSS#

Written in Rust, 100x faster than JavaScript alternatives. It handles:

• Vendor prefixing
• CSS minification
• Modern CSS transpilation
• CSS Modules

Built by the Parcel team, it integrates seamlessly with Vite, webpack, and other bundlers. I haven’t used it extensively yet, but the performance benchmarks are impressive and it’s worth exploring for build-time optimization.

The Classics: Sass, Less, Stylus#

I’ve used all three professionally:

• Sass: The most powerful. Excellent for large design systems with complex mixins and functions. The ecosystem is massive.
• Less: Bootstrap’s choice. Gentler learning curve, closer to vanilla CSS syntax.
• Stylus: Most flexible syntax. Great for Node.js projects.

These days, I find myself reaching for them less often because native CSS has caught up. But they’re still solid choices if your team is already invested.