Why everyone is moving to Stylex?

Stylex. Everybody's talking about Stylex. We're gonna do an episode on it. If you ever open up a meta property, Facebook, whatever, you'll see that their classes just have all these random classes on it, and everybody assumes that that's Facebook's own internal version of Tailwind. And that's not the case at all. It's their own way of writing CSS, and it's actually pretty smart. We did an episode three years ago on it. Now everybody is onto it. It's great for agents. There's some pros, the cons. We're gonna go into all of it, what people are saying about it, as well as some of the alternative. Let's get on into it. You ready, Scott?

Oh, I'm I'm I'm as ready as I can be, Wes, because, honestly, there's a lot there's a lot about, Stylex I find to be fairly grotesque, but I'm I'm keeping an open mind.

This is me keeping an open mind. Folks, you can change, and you can keep an open mind too because there's nothing that makes me feel more icky than writing CSS inside of a JavaScript object. And today, we're gonna be talking about that. We're gonna talk about how great it is. Yes. Yes. Yeah. But before we get into that, we are going to be doing a meetup in San Francisco, Tuesday, October 27.

It might be a spooky meetup, but I don't think it's gonna be that spooky. So come on down. We're gonna be at the Bear Bottle Beer Garden. If you've come to a Syntax meetup in October, it's at the same place we had it last Yarn. And let me tell you, we had a great time. There was a huge turnout. You can come around, have some beers, have some just,

sodas or waters or whatever you like to drink. We got we're gonna have swag there. It's gonna be sick. We're gonna have swag.

The whole Syntax the entire Syntax team. Have you have you been dying to meet producer Sanity? He's gonna be there. You can say hi. It's gonna be sick.

So, again, Salesforce Park, at the beer Bottle Beer Garden. We will have all of the information in the show notes as well as a link you can head to syntax.fm/meetup

if you wanna get more information. It's gonna be a ton of fun, and I can't wait. We should also say, even though we're in town for GitHub Universe, this is not part of GitHub Universe. So you don't need a GitHub Universe ticket or anything like this. You just come as you are. Come as you are. Just come and hang out, and it's always a good time.

Alright. Let's talk about stylex. So stylex is the way that all meta properties write their CSS. And the way that it works is that you author your styles in kind of similar to how you would write like a CSS selector, and the syntax is significantly different. We'll get into why that is in just a second. But put aside the the syntax for a second because we wanna talk about, like, the pros and cons and and all of that type of stuff.

So the way that it works is that you write these StyleX selectors, and you you give it your font size, your line height, your color.

They're fully typed. You can share them. You can import and export them. It's all done inside of inside of JavaScript.

And then there is a compilation step, which will essentially turn all of that CSS into these crazy class names. So if you look at any meta property, right, you see, like, x one I one zero h f l, and, like, that will correspond to, like, padding top zero. So Mhmm. The benefit of this is that it will go through all of your styles. You can author them like like you're used to with regular CSS styles. And then anytime you use padding top zero or margin bottom zero anywhere in your your application, you might use it like, Meta probably uses it 300,000 times across all their properties, they can get rid of all of those and simply distill it down into a simple one class that they can apply to that element, which is some generated x random token that puts in there. So if you're looking at, like, the we did a show called why is Facebook's HTML and CSS such a mess? Because if you if you inspect element on it, it's, like, impossible to read. But that's that's obviously not how it's authored or maybe Scott, obviously. I think a lot of people think that they they write it like that.

Yeah. Yeah. You know what? I mean and this is the exact same way that, like, something like how Svelte does their scoped CSS. It generates these kind of wild class names as well. So not exclusive to Stylex, that strategy of generating these types of class names. I believe, the Babel plug in for,

styled components did the same. So yes. So the difference between the way that Svelte does it and the way that Stylex does it is Stylex gives you a class for every single unique property value pnpm. Whereas the Svelte and, like like, CSS modules and a lot of the, like, the I think it's panda. We'll talk about panda in just a second.

Those will create a single unique class for that item. So you might have, like, podcast card where it has, like, a border. It has, a background, a radius, a Bos shadow. All of those things will be like, okay.

We'll put that into a single class called, like, show card or, like, X4935, some random ID.

Whereas this, it will literally break apart every single property value Mhmm. And then assign it. That's why, like, every single element here has sometimes twenty, thirty different classes. Wes. Only one per. It's a wild strategy. And I I think that it's,

one, I I think that it's there to save a bunch of code. I mean, it's there to save you a bunch of shit, like, shipping a bunch of extra stuff, which, you know, in this world where we're just shoving as much stuff into the browser as we can these days, obviously, having a strategy to deal with that, I am pro for.

So that that, I think, is interesting.

You'll you'll notice some, like, hesitation when I talk about this in general because I'm so repulsed by the syntax. I I have such a hard time. And it it's it's these are all the things. Away. I'm try I can't. It's so hard. But I I'm keeping an open mind, and I understand why this is cool. So people have started talking about this recently, and Jared Palmer had a tweet.

Dude, it feels like a week ago, but it was yesterday.

He says after about a decade of atomic CSS frameworks, base CSS, and then finally, Tailwind. I'm finally convinced that Stylex is superior for agents. Stylex constraints lead to greater consistency and correctness as your code Bos grows. I do think Tailwind is the idea, human DSL for styling. But in a world where I'm barely touching CSS class names by hand, the trade off has changed. Again, if I were writing code, Tailwind still wins, but we're not doing it anymore. I would disagree that Tailwind is the best to write by hand. I like writing to just a single class name, but, I I totally get where he's coming from in this. And this tweet in particular made me stop and go, kinda feel like he's probably right about this. Yeah.

Yeah. Yeah. Like, again, putting aside what it looks like because I also don't like, like, what it looks like, and I hate authoring it that way. But if you're if you're looking at it, like, for initially, Tailwind was the winner for agents because it was so good at writing, spitting out Tailwind. Right? And Yes. What is so good about Tailwind is that it it can look at the markup, and it's collocated with how it looks. And if you're writing typical CSS, you would often have your CSS in, like, a separate file, and then linking those two things together was was kind of tricky for an agent. Right? And Mhmm. And this is not the first thing to solve that. Right? Svelte solves this by simply just, like, you have your your markup and your CSS in the same file. Right? That's that's beautiful. I absolutely it's probably my favorite

way to write CSS JS the way that it's called. I'd need to separate my favorite way from a favorite

system that can work well Yes. With agents. Exactly. Because I I think at the end of the day, a a system that is rigid and works well as you scale from a website with 20 pages on it to a property like Facebook that has hundreds of thousands of components that that need to be that write CSS for. Like, I remember hearing, like, LinkedIn writes something like 30,000 lines of CSS every single day. I forget what the actual stat was, but it was mind blowing how much CSS they were just adding to the platform every single day. And when you get into that type of scale, it gets away. So, yeah, it doesn't surprise you.

Yeah.

It's a rough style site. Sorry, LinkedIn folks. Another another one right here is, Adam Hutchinson from Linear. Right? Linear, long, held as one of the, like, best web properties out there. They care a lot about the engineering. We've moved more than 50% of linear to StyleX so far. Wow. It's given us more control over over how components compose, what can be overwritten, and improved render performance as well. So that's a really interesting one because the browser doesn't necessarily have to, figure out what overrides are there right? Like, with with typical CSS, if you have, like, margin zero, margin bottom four, right, it applies a margin zero, and then it and it has to figure out, okay. No. But then I do want to add margin bottom four.

Right? If it's simply just straight up, every class is not overriding each other. It's not cascading down. It's none of that. That can improve render performance, which Aidan Bive had him on the podcast. He's, really smart guy. He's Node, like, React Doctor and several other of the React plugins that will help you figure out perf. Million dot dot like, really cracked, like, performance dev here. He says, I just migrated my personal site from Tailwind to Stylex. So, First Contentful Paint, 20% faster. Largest Contentful Paint, 7% faster. CSS, 50% smaller because, again, literally, every time you use margin bottom one p x margin bottom color red, like, that's you're literally only shipping that once even though you might use it millions of time. And you might say, yeah, Wes, but gzip.

Because, like, with gzip, if you were to send the same string 10,000 times, doesn't matter because the browser just gets it once. Right? But the actual parsing of that CSS can slow it down. I don't know. Most people are having, like, CSS performance issues on their website, but, like, these are obviously I he doesn't say, like, what the thing is. It's probably milliseconds,

but it is something. Right? And if it's trivial to implement, then. Yep. Or if it's, you know, hey, AI agent, make this style x, then it's like, why wouldn't you just accept I obviously, rewriting your platform is different than, like, greenfield or something like that. But still, like, if you're making that choice, especially if you're in a React world where CSS is such a pain, like, I I I kinda kinda am feeling like man, Wes, you can feel it in my voice here. I'm kinda feeling like I need to try this. It.

I'm understanding it, but I'm also trying to resist my urge of picking up all the new stuff all the time, even though this isn't new. I'm trying to resist my urge of being like, oh, people say that's good. I gotta have it. Yeah.

So, yeah, I I okay. Well, so Let's talk about the the pros of it and see if we can get you all the way there. Right? Because the first pro we have here is that it's type safe.

With Tailwind or with regular CSS, you are simply just writing strings. Right? And if you have something like a design system where you want to constrain what CSS can be written, If your entire CSS thing is is type safe, meaning, like, just like TypeScript Wes you can allow and disallow certain things and infer the types from it, then you can have a little bit more control over what is and isn't allowed. Not to say that you couldn't do this before. Scott's talked about many times on this podcast about different CSS linters. He's wrote his own CSS ESLint.

Right? Like, you can enforce that. But when you have a rigid way where an agent or yourself can know, is this allowed or not, then it is it's much easier to stay within the lines and stop you from gaining that CSS drift.

Yeah. The linting, any deterministic systems, those types of things Yarn endlessly important, especially in CSS, because, AI world, man, AI just loves to do whatever the heck it wants to do with CSS.

So, yes, there is no runtime dependency.

So this is something that, like you say here, that most CSS methodologies no longer have this. Like, they're done at build time. For a long time, you need to have Babel plug ins for various ones, but it feels like we've kind of moved out of that world a little bit. Yeah.

So

most people have been doing the same way. Big one Wes every time your React component rendered, it would then compute what the CSS would be. Mhmm. And we did that mostly because we needed it to yeah. We Node to be dynamic. Right? Yeah. But now with CSS variables and whatever, we realize, oh, it's much better to compute all of that at build time, figure out what all the possible CSS is, and then ship that. And then if you are doing things like like you're conditionally setting some CSS based on if something is focused or something is in a certain state, your your JavaScript will simply just add and remove those classes rather than adding and removing

figuring out what styles need to be added at runtime. Yes. And if you want to see all of the errors in your application, you'll want to check out Sentry at century.io/syntax.

You don't want a production application out there that, well, you have no visibility into in case something is blowing up, and you might not even know it. So head on to century.io/syntax.

Again, we've been using this tool for a long time, and it totally rules. Alright.

Yeah. Another one is that it's reusable, super easy to reuse. I mean, that's the one thing about CSS modules that I have a hard time with is needing to import and export everything. But at the end of the day, you know, having that there does make it easier to, have.

It's safer. Yeah. You're not there's no chance of you using something that doesn't exist. Like, even if you I mean, you can have linting set up, right, to prevent you from using classes that don't exist. But a lot of times, you know, I've had AI write, like, dot whatever class that it thinks exists in my code base because it Scott it in its training data. And it's like, without having a linting step in there, there's nothing to be like, oh, by the way, this CSS class does not exist. You know?

I did my whole site in CSS modules after I wrote it in Panda, and I moved it to a couple different ones. And I finally landed on CSS modules, and I did that because when I'm viewing a component or in this age, when an agent is viewing a component, it should be you should be able to click on the styles and and go to where those styles are are defined.

With with regular CSS Wes you have a class, you're you're ending up, like, searching for for where that is. So, like like, okay. This is a class here, but, like, where is that defined? Oh, it's in several different files.

When it is all typed all the way down, then you can just kinda click through and see exactly where those styles are. So in that case, I do not mind importing it even because, like, the auto import. I set up auto import with it. And if I just write a class of, like, big card or highlighted card or danger, then it would just auto import for me. I didn't have to really worry about that, and I absolutely love that. And I that's one thing I don't like about Tailwind is that, like, if you wanna reuse styles in Tailwind, you you kinda have a couple options. Right? You can you can create a string, and you can just export that string from a file and import it every everywhere that you need it. Yeah.

Or you could what a lot of people do is they'll they'll create a secondary, like, component. Right? So instead of, like, having a div with the class of, like, special on it, they would make a special, like, div component, and they would then import that. And then and then I don't like that either because now now you have to make a whole like, I just wanna add a couple styles to this thing, and now I'm having to, like, make a whole another component. That's a big pain, especially in, like, Svelte land Wes you can't define multiple components in a single You can you can. That's all. Information. You can do that. Now we can do that. Right? Yeah. But you know what? It's,

this this type of thing I this is crazy. Like, my brain is is, like, struggling with this. But this type of thing, I think, is dope. I I I like this, in regards to being able to get that control. Mhmm. Being because I I I did love that about styled components where you had the wrappers, and it just, like, worked like that. But I haven't found any other style wrapper style of things that work well post style components.

So I guess I can get into importing CSS. It just has to be the right API or the right surface. And and maybe, again, like, this surface isn't for me. I have in all capital letters. It is not for me, but it is seem like it is for agents.

Yes.

Yes. You know, you are I mean, it's JavaScript too. And a lot of the stuff like overriding or anything like that, they're done inside of function. So you have, you know, overrides. You have conditional styling. You have, composability.

And and I love that about styled components Wes you could just ESLint out and go into JavaScript and do some JavaScript inside your CSS. I like that. The composability is is a huge one because, like, with Tailwind, you gotta, like, use some,

like, class x or Tailwind merge or something like that Wes you're like, okay. Well, I have, like, these base styles, and now I want to extend them and overwrite some you know what's really good at merging and overriding properties? JavaScript objects.

Yeah. Very, very good.

Vercel strings, fantastic for that type of thing.

Totally. So that's the pros.

The cons, we obviously sucks to write by hand.

It's, like, right especially when you get into, like, writing nested media queries or, like, pseudo classes or a lot of the new, like like, sibling index, a lot of the new CSS, awful to write by hand. And it's Awful to write by hand. Just can't Yeah. Do it. Like, the the the

I have the syntax here for, like, defining or to, like, modifying an existing variable. I it's just the amount of code used compared to, like, oh, you need a function that then has a string interpolation.

You got, you know, an object inside of there, and you're having to pull out a property. It's like, you know, in in normal CSS, you're just like Yarn hyphen hyphen text. You know? The the the amount of change the amount of code you're having to write there is more, and that like, it's ugly for me to look at. It's hard it's hard it's hard for me to look at, folks. I'm having a hard time looking at it. I wanted to know about modern CSS properties in this thing. One thing I have with Tailwind is that you kinda have to wait for them to implement, you know, modern cutting edge stuff all the time. Right? They it's a DSL or it's a subsystem of CSS, so you gotta wait like, you can't just go ahead and, you know, load the newest stuff. I I would assume that's the same with this because everything's in the JavaScript object, and it's fully typed. So, you know, you're gonna be waiting for the

less of an issue here because, like, new stuff that comes in CSS is simply just going to be, like, a property or a value.

I think in some cases Wes you do have some weird syntax, you probably are better off just bowing out to, like, a CSS sheet. That that's what I do in Tailwind as well, where I'm like, I could write Tailwind plug in for this and make some, like, weird abstraction or whatever. But you know what's easier JS just just write some CSS for that. It that's Yeah. And that's fine. That's not, like, losing at Tailwind. They might come out with, like, an abstraction on top of it that makes it a little bit easier to author, but there's nothing wrong with just throwing a little bit of CSS in there. I guess it could be wrong if if everybody starts doing it, and then you Now you got two systems.

Yeah. For me, that's a tough one.

But, again, it's probably for most like, 99% of projects, not a big deal because, sometimes I'm getting into to some wacky stuff, and most people aren't. You do do do stuff. Honestly. Yes.

Nested CSS. This is one thing that kills me with most stuff JS you write, like, a selector, like a podcast heading, and then inside of that, maybe you have, like like, a span around, like, the the podcast number. Right? And in almost all of these implementations, what they want you to do is the podcast heading is one style, and then the podcast number would be a secondary style that even though it's just a span inside there. In so many cases, I just wanna nest a span selector inside of that because I know that's literally the only thing that will be applied to it. And I love to write not too nested, but nested selectors inside of it. And and with this type of stuff, you're every single element, you're writing a brand new, selector. You're writing it or a brand new object for it. I'm sure there are ways to do it, but then, like, even with with CSS modules, if you want, like, the nesting to apply, it can get really, really tricky. And also with, like, Svelte as Wes. You have to use the stupid, like, global selector on top of it. And I get why, but sometimes I just wanna nest things inside.

So it's not that great in this case.

Yes. Yeah. I yeah. Those are the things I have the hardest time with, I think. But then, again again, to I'm gonna keep going back to, it's not for me to author. If I'm using Stylex, if I'm going to use this thing, I'm not going to be writing it by hand. I'll say that. Yes. I agree.

Let's talk about some alternatives here. Panda CSS, we've done a whole show on it. We'll link it up. You can go back and and listen to that one.

Panda CSS follows the same sort of ideas. However, they allow you to author it either in, like, a like a like a tagged template syntax, which I absolutely love because it's as as similar to writing CSS as possible.

Or you can write it in the object syntax, which, is very similar to to using something like Stylex. So that's great. Like, they have figured out you still get all the benefits of Stylex, but you still you you can use, like, the tagged templates, which is is kinda best of both worlds. The nesting, still a problem here, but that's I think that's inevitably why I moved off of it because I wanted the nesting of CSS modules. But I think that, like, if you're going from absolute scratch, Panda is is a highly you should definitely check it out if you're if you're considering Stylex.

And they got cooler branding. So you know? Panda. Yeah. They got yellow and black. It's, like, very up our alley here. Yes.

Love that. Love that. Yes. And the the panda guy's kinda cool too. So, you know, pros and cons here. One's got a panda guy. One's got a kind of, like, corporal logo.

But

yeah. That's cool.

Yeah. This is cool. Another thing is that I don't love this like, the spreading syntax either.

Oh, it's ugly. You don't have to spread, but Yeah. You can.

You don't have to spread, but you can. Yeah. I just have to touch your hour time. You know, the one thing I could get behind is if it's a greenfield vibe coated project, it's something that I'm just straight up looking for, what's going to give me the least amount of issue with AI agents writing CSS. Because let's face it.

They suck at CSS. Everything is just kind of done in the moment when it thinks about it, adds it, and then emits unmaintainable systems.

And if this could fix that, then, you know, I'm I'm would be reasonable to to try it. What's going on there? Oh, you're typing. I was, like, seeing a bunch of arrows flashing. Yeah. Well, let let me show you. This is like a like a visual

representation of how good Stylex is. And please describe to their folks on audio. In their playground, I'm typing styles.

I can't spell styles. Styles Scott, and, like, it automatically completes styles dot button, button row, button secondary, card, content block. Like, you're not saying, what was the class that I was using for button links? It's it's just auto completed for you. Right? So, like, dot button Mhmm. Scott.

And then here's all of the let me scroll. I can't scroll over, but now it's it's proposing all of the CSS properties. Right? Align item, background, border radius, color. It's like every single property value is typed all the way down, which is absolutely beautiful when you're trying to apply these styles. And now I know most people are just gonna slop code their CSS anyways, but if you're writing something that if if you wanna author what it looks like to make it look good and then give that to your agent to to reuse, that's a fantastic way to write your CSS.

Yeah. You Node, it Wes. The the the thoughts that are going through my brain, I don't like them. That JS, like, what if I had, I took my Graffiti CSS, which is already a great system, and I told an agent to make it into a nice little component library using Stylex.

I feel like that would fit really well considering it's CSS based components.

Oh, I don't like this. Yeah. If if your whole hang up to this is just like, I like writing the CSS syntax. It is. It is. And I'm Get over yourself. I yeah. I know. That's listen. I'm telling you folks, I'm acknowledging that. I'm working on myself here. I'm entertaining this. Yes.

Alright. Stay tuned for the next episode where Scott is fully Stylex pilled, and, he's gonna not stop talking about it.

If you've listened to the show at any amount of time, you know that's that's coming. So, yes.

Peace.