Is Tailwind Losing Ground to StyleX in the Agentic Coding Era?

For years, styled-components worked well for Linear, the product development and issue tracking platform. 

Its flexible API let developers colocate styles with components while keeping a regular CSS escape hatch. 

As Linear’s codebase grew, however, that flexibility became harder to manage.

In a blog post, Linear said the “endless configurability” of styled-components had become a liability. CSS could be modified from outside the component it belonged to, making patterns such as styled(Button) common. 

After a redesign, Linear found a long tail of UI regressions caused by styling changes from a distance.

Runtime CSS generation also added render-time work, and styled-components had entered maintenance mode.

The problem became harder to manage as AI coding agents began contributing more code. 

Linear found styled-components difficult to automate because it is effectively an open-ended language with the full flexibility of CSS. 

Many ways could express the same styling intent, and agents could produce code that looked correct while violating the application’s intended structure.

That is where StyleX came in.

Linear wanted styles to be generated at build time, styling at a distance to be difficult, component styling contracts to be explicit, and style merging to be predictable. 

It evaluated several React styling systems, including vanilla-extract, but chose StyleX because its styles could remain colocated with components while providing deterministic resolution and type-safe styling contracts.

The migration took more than 1,000 pull requests. Linear built a deterministic codemod and used agents for repetitive work, while migrating the application incrementally and keeping the old and new systems running together.

The team started with leaf components and kept scopes narrow because visual validation remained difficult for agents.

Linear says the resulting system reduced main-thread CPU work by roughly 20–35% on view-heavy pages after removing runtime style injection. 

Its tests were around 30% faster on a mid-tier machine, and the client went from injecting hundreds of CSS rules during navigation to injecting none.

Jared Palmer, VP of Engineering at Cognition, has made a similar argument after years of working with atomic CSS frameworks including Tailwind.

“After about a ~decade with atomic CSS frameworks (BuzzFeed Solid, Basscss, and then finally Tailwind), I think I’m convinced now that StyleX is superior for agents,” Palmer wrote on X. 

He said StyleX’s constraints produce “greater consistency and correctness as your codebase grows”.

Palmer still considers Tailwind the better choice when developers are writing the styling code themselves. But with agents handling more of the implementation, he argues that “the tradeoffs have changed”.

The argument for StyleX with coding agents is less about syntax and more about constraints. Tailwind gives developers broad freedom in how they combine utility classes. 

StyleX narrows those choices with typed styles, design tokens, and deterministic composition, giving agents fewer ways to express the same intent while catching invalid values and styling violations earlier.

Tailwind’s concise syntax benefits humans writing styles by hand, but when an agent is doing the typing, stricter rules can matter more than brevity. Linear cited clearer styling boundaries and agent ergonomics when it chose StyleX, after finding its previous system too open-ended to automate reliably. 

Meta developed StyleX as a styling system for large-scale applications and open-sourced it at the end of 2023. 

It combines CSS-in-JS ergonomics with static CSS by compiling styles at build time and generating a static stylesheet. 

Meta uses it across Facebook, Instagram, WhatsApp, Messenger and Threads, while companies including Figma and Snowflake have also adopted it.

The system uses atomic CSS, type-safe authoring and predictable style merging. Meta has said atomic classes reduced its CSS size by 80%. Runtime work remains for cases such as cross-module style merging and genuinely dynamic styles, while stylex.create itself is compiled away.

StyleX has also built a sizeable open-source community since Meta released it publicly. The official repository now has nearly 10,000 GitHub stars, and more than 450 forks. StyleX’s adoption is also showing up in package usage. 

The core @stylexjs/stylex package now records more than 1.4 million weekly npm downloads, while its Babel plugin records more than one million and its ESLint plugin nearly 688,000.

Naman Goel, a core contributor to the StyleX open-source project, has highlighted several other differences from Tailwind. 

StyleX uses strongly typed style objects, standard CSS property and value names, colocated CSS keyframes and view transitions, named styles and a first-class API for dynamic styles.

Goel also points to debugging. Tailwind makes the styles applied to an element visible through its utility classes, while StyleX can show where a style originated in the source code. Its DevTools can use source maps to display the style objects and the order in which they are applied.

The distinction also matters for how agents interpret code. A named StyleX style can encode semantic information about why a style exists, not just which CSS properties it contains. 

Standard CSS property names also remove the need for an agent to translate between CSS terminology and framework-specific utility names.

StyleX is finding a new path to wider adoption as coding agents take on more software development.

“Hard to predict how much adoption a discussion on X will lead to, but even before now StyleX has been used at many major companies like Meta, Figma, Canva, Snowflake,” said Goel to AIM. 

“StyleX has slowly been gaining adoption since it was open-sourced, and I think it’s normal for it to take a couple of years for the rate of adoption to increase.”

Canva is also investigating a much larger migration. In a November 2025 GitHub discussion, a Canva engineer said the company had more than 10,000 CSS Modules files containing over 46,000 rule selectors and was investigating a move to StyleX. A StyleX maintainer responded that Meta’s own migration from a similar system had been automated for roughly 80% of cases.

A July experiment by LogRocket migrated StyleX directly from Tailwind across 20 production-style components. 

The migration doubled the styling code, from 1,568 lines to 3,143, while the resulting CSS bundles were nearly identical: 20,379 bytes for Tailwind and 20,561 bytes for StyleX.

Cold build times were also similar, at eight seconds for Tailwind and 7.4 seconds for StyleX.

The main difference, however, was type safety. The experiment found that StyleX caught styling mistakes involving tokens, variants and composition earlier, while Tailwind retained a clear advantage in ecosystem size and rapid prototyping.

The Misconception about StyleX’s Performance

One criticism of StyleX is that its styling model could carry the runtime performance costs associated with CSS-in-JS libraries that generate and inject styles while an application runs.

Goel says that is a misconception. 

“The common misconception about StyleX is that people don’t realise that it is compiled and doesn’t do any runtime style generation/injection,” he tells.

“StyleX compiles to something that is at least as efficient as Tailwind, if not more,” Goel says.

He cites recent migration figures showing up to 20% better FCP, up to 60% less CSS and 5% less JavaScript.

There are genuine tradeoffs, though. 

StyleX makes some CSS patterns harder to express, including certain parent-dependent selectors, global selectors and wrapper-based restyling. 

Linear describes those restrictions as deliberate constraints, and they remove patterns that made its previous styling system hard to reason about at scale.

StyleX can also require more ceremony for some simple use cases. Its compiler depends on styles being statically analyzable, which limits highly dynamic patterns. Cross-file composition can require runtime style merging, although the StyleX team describes that runtime cost as small.

StyleX is Not Always the Right Migration

However, replacing Tailwind with StyleX does not automatically make a website faster.

Recently, Franklin Javier, a software developer, published the results of his attempt to replace Tailwind with StyleX on his personal website. The site already scored 100 on PageSpeed, shipped no JavaScript in its Astro bundle, and had an FCP of 0.8 seconds. 

After rebuilding it with StyleX and matching the existing design pixel for pixel, FCP remained at 0.8 seconds, and LCP showed no consistent improvement. Javier reverted the migration.

StyleX reduced the site’s raw CSS from 40,325 bytes to 36,972 bytes. Gzipped CSS fell from roughly 6.9 KB to roughly 6.5 KB. The smaller stylesheet did not produce a measurable loading improvement.

Javier also found that Tailwind carried unnecessary CSS. The typography plugin was sent to pages that did not use it. After removing that waste and making other changes, he achieved substantial CSS reductions without migrating away from Tailwind.

The comparison also showed that raw file size doesn’t tell the whole story. StyleX produced less raw HTML, but the compressed HTML was slightly larger because Tailwind’s repeated utility classes compress efficiently. StyleX’s more unique class names reduced that compression advantage.

Javier’s results do not show that StyleX is slower than Tailwind. They show that the benefit depends on where the bottleneck is. On a small site that already loads quickly and ships almost no JavaScript, a styling migration can reduce CSS without producing a visible performance gain.

Tailwind therefore remains a strong option for developers who prefer its utility-based syntax and flexibility. StyleX makes a different trade-off. It gives up some flexibility in exchange for stronger constraints, predictable composition, type safety and compile-time extraction.