I'm joined by Melissa, who's been at the heart of StyleX Meta's own approach to CSS. Melissa, welcome to Meta Tech Podcast.

Melissa: Yeah. Um, thanks so much for having me. I'm excited to talk about StyleX.

Pascal: I am really excited to talk about CSS as well. It's been a while since I've actually, touched it in depth because so much has changed, but I'm sure we will go into this. But first I want to talk for a second about you, Melissa. Can you tell us how long you've been at Meta, what your journey inside the company has been and what you did before?

Melissa: Yeah. Yeah, happy to give a quick walkthrough. So I've been working on StyleX for around one and a half years now. But I kinda started at Meta around four and I was doing quite a few things for a while. I started out on this old product called Messenger Kids, which kind of is in maintenance mode for now, for a while.

So went through a lot of reorgs there. There's a lot of chaos. And then I started out wanting to do web work, but I quickly got slotted into iOS for a while because of company priorities and everything. And then yeah, it was like on React and then React Native, and then eventually on iOS for a few years.

And then. In the past I was working on Instagram, doing Instagram growth for a little bit, so I hopped around quite a bit early on at this company. And then when I found Web Platform, which is the org that I'm in, yeah, that's where it all clicked for me. I was like, okay, I've been through all these product teams working on all these products that I love, but maybe what makes me excited is building like where the heart of all these really interesting problems are and like where I met so many people that I think have so much passion for the web, it was like I knew I always wanted to return to the web.

And when I landed out, when I kinda entered the web space, I was like, okay, I think this is where I wanna stay. I think I'm having a great time here. Joined web platform, or more specifically the components team, which is like our design systems Infra team where we create components around it.

And that's where StyleX really started. It came from this organic need from people building those like low level UI components for the company to use and being like, Hey, this styling system that we have could be better. This is, these are all the changes that we wanna make to it.

Pascal: I just wanted to ask you about this specifically because CSS exists, most websites are just perfectly fine by having a little rail style sheet annotation at the top of them. Why did we need to build our own styling system at Meta?

Melissa: Yeah. Okay. So I think that there's a lot of things that we talk at Meta, of course, that are pretty unique to such a large company, like we make facebook.com, that's one of the largest websites in the world, serving like hundreds of millions of users every day. We need to be able to handle all that traffic.

We need to be able to handle all the different routes like Facebook, like there's thousands of components that kinda make up Facebook. There's thousands of different page sub pages and sub components and everything. How do we have to make sure that we load things exactly as we need? Keep the bundle size as low as possible.

And then we also need to think about what's maintainable from a developer perspective of being able to have this large code base and make it so that hey, like if one, if someone from the ads team is building a component that they're declaring, a button class there and then oh, someone from Instagram is also creating a button class and we need a system at least to make it maintainable

Pascal: Very classic problem.

Melissa: Yeah, StyleX wasn't the first styling solution. We had a few iterations, legacy systems nowadays, but it is a solution that's been, that's, been stable for almost, for more than seven years now. It started seven years ago. And it's kind of won throughout all of these other styling solutions we created.

Pascal: Yeah, seven years is a fairly long time in technology. If you can survive for that long and people are still adopting it, probably a good sign for those people. You have never seen it in action, and obviously given that this is primarily an audio medium, we need to rely on words to get it across, but can you describe a little how StyleX works and how people use it to apply styling to their apps or components?

Melissa: Yeah. At a high level, it's very simple. StyleX is composed of two main APIs. You have your StyleX that create which use to define styles, and it just looks like a JavaScript object, like inline styles approach. It looks very similar to React Native’s style sheet for users that may be more familiar with that system.

But the gist of it is you declare like with. JSX and text your CSS across these different name spaces. Like you'll have an object with a nested key like food bar, card button, whatever it is. And then within that, you write all your styles, and then you have a StyleX props function where you actually spread what essentially just a class name of space, separated class names onto a div and then occasionally an inline style for certain properties.

But at a high level, what it's doing is it's just at compile time what it'll do is the StyleX start, create function will get transpiled into just, a keys referencing different class name strings. And then a class name stop prop will eventually spread that class names onto your diff.

And then what it StyleX behind the scenes uses atomic CSS, meaning that every single key value or CSS property style declaration gets turned into a single atomic class. So that means that if you declare a class like Margin 10 once in your code base, like someone in comment or Facebook creates that then that's the only time it'll ever be that single margin, 10 class only needs to be cleared once across the entire code base. That's just one line of CSS for us.

Pascal: Okay. That's really exciting because that then obviously translates into a lower bundle size, which you said kind of core principles behind it.

Melissa: Yes.

Pascal: So you also mentioned that this wasn't the first styling solution that we've had at Meta or at Facebook for this specific app.

So can you talk a bit about the predecessor CX and how it differs from StyleX?

Melissa: Yes, for sure. Yeah, so obviously like we, we, CX was built to solve the first thing I talked about, which is oh, how do we make sure our scales are stoked? How do we make sure that we don't run into conflicts and like the global nature that CSS is like JavaScript, of course, a lot of things are scoped to a module or a file or whatever it is, but we don't have that kind of scoping in CSS, so we had to artificially create it.

Using essentially like our own version of CSS modules. So styles are scoped to a like a file and a component and you use this like sort of syntax system, which is based on a slash forward. And what it does just scopes your styles by component by file and allows people to use them.

So you now don't run into this whole conflict thing that we have, but we still have the same issues that I mentioned about bundle size, about not having enough restrictions for people to define really complex selectors within CX. And a lot of other pain points that led us to eventually moving to StyleX.

Pascal: Yeah, I don't fully remember it anymore. But wasn't it something like you had to actually define your own namespace, or it might be something like Groups slash my component and then somebody else might have marketplace slash my component. And if you both in your previous example, have Imagine 10 in there, you would still create two entries in your CSS bundle.

Melissa: Yes. Yeah, you can still use complex selectors. You can do like parent child selectors there. You can kinda, a lot of these other patterns like of what we generally call like styling at a distance, which is when you write a style in one place that can used to style like an indiscriminate number of components or elements in the dump tree, like below or above or whatever it is. So that, that's, that was one of the problems that wanted to tackle. Bundle size was a huge issue and StyleX really came up when we were doing the whole rewrite of comet.com. And. Like earlier in the 2010s, we were doing a larger initiative to just completely rewrite comet from the ground up.

'cause of all these issues, we were, and at the time we were serving like tens of megabytes of CSS for all of comet. And then we managed to reduce it to just a few hundred kilobytes for comet using StyleX. So that's where it all arose. It started with facebook.com and it's still at the heart of facebook.com, but it's also being used pretty much everywhere else at Meta for like pretty much all web apps at this point.

Pascal: I was gonna ask like how much could it possibly be? It's still human written CSS, so to you, how much could it, and about 10 megabytes, that, that is pretty nuts. So getting that down, I can see how this became a priority.

Melissa: Yeah. I need to double check the numbers, but I think at some point it's around 30 plus megabytes or something.

Pascal: Wow. I mean there's obviously GE and this seems quite compressible, but nonetheless, there's a lot. And the browsers will also have to do just a lot of work. To even render this efficiently because somewhere there needs to be a three where we see it's looked up and then applied with all the different priority issues.

And that is actually something I wanted to talk to you about as well because as we are talking about the problems at scale size. Obviously one big problem reuse another one that you've talked about how you want to ensure that people hopefully don't reinvent button for the 300th time. But the other one is just who wins if you have multiple declarations of style sheets?

I've definitely seen like larger code bases where it basically becomes this kind of shooting match off. Who can put more. Exclamation mark importance on their potential selectors or find other funny ways of making sure they end up the highest in the priority list. So how do you solve this for StyleX?

Melissa: You won't run into any conflicts with another component style. So we're writing it because everything is scoped or being applied directly to the diviv. It's all class names. And then. From there. With, so within the component itself, all the styles you apply directly will apply to that single element.

We don't have complex selectors that could maybe override your styles. We allow, we only allow for people to basically style an element directly. So on the baseline, that's baseline guarantee that we have. But we do a lot more behind the scenes than just that. So the StyleX props function that I mentioned earlier, you can pass different style objects to it.

The style objects created with StyleX create, you can pass in the styles that are defined locally, but you can also which is one of you can also. Have parent components pass in styles as props. And it's a lot of how, I mentioned that StyleX kind of came from the design systems.

Team. It's because when we are designing a lot of these components, we are like, okay, wait, we need, if we have a high level button class and we and we want to define specific button variance, it's very useful to pass in different styles based on, different states of the parent or to pass in base styles.

So we have a pattern where people commonly passed styles in. And the promise that we have with style accept props is the last style you apply always wins. You're applying, a common separated list of styles. And the last style object you apply will all the properties within that will take precedence over anything that you have there.

And we'd do a pretty fast object merging. We merge 'em as objects and we just take the last key for every style property that appears. So if you have a margin in style A and A margin in style B, you'll, the margin in B will win. However, that, with simple properties, that, that's quite simple.

But if you think about the entire complex system of media queries as pseudo classes if you have a margin class and a margin top class and you want the margin to override every single every single site except for margin top, how do we get all that to work properly? And there's two parts to that.

One is figuring out which class names to eventually apply at the node level. So we do duplicate all class names. So there's only one property per, there's only one class name per property. But then within, in cases where we have a margin and a margin top and we want the margin top to override the margin, then we'll use CSS layers or kind of specificities to do all of that handling for you.

We end up with a pretty nice system. There's different user configurations to how you want shorthands and long heads to behave, but for a high level you have. Yeah, we define a really complicated priority system to make sure, okay, if you're defining media query, you probably want it to win over your default styles.

Similarly with pseudo classes, you probably wanna win, you probably want those to win over default or based styles. And certain pseudo classes, it makes more sense for them to win over others. For example, like if a element is being act, is it active? It's probably also being hovered. We should probably have, we give a little bit higher priority to active styles.

And yeah it's a pretty complex system. I don't really know how to talk about it in a really concise way.

Pascal: Okay, so what you said is that there is a lot of complexity, but I think the beauty is that most of it is really hidden away from the users and for 90% of users, and I consider myself firmly as part of that 90% base, they never actually use anything apart from StyleX.create and StyleX.props, and the rest is just magic and probably, I would imagine more heavily used.

By the components team that create those kind of reusable components and potential hierarchies of them and work with theming and all these other aspects.

Melissa: Yeah, I would say that the majority of people like don't really know of the internals and they honestly, it's like it works so well that I think people don't even understand all of its complexities. So they're just like, oh, yeah, I've been using StyleX this whole time. I don't really run into these complex, don't really run into these issues, and I'm like, you have no idea how good you have it.

Pascal: This is then how the questions come up about like, how is there an entire team behind this project? It seems so simple. Isn't this done? But I'm curious about it. So since the inception, because seven years is a long time, what changes have you actually brought two StyleX? What have been the biggest challenges that you've solved in that time?

Melissa: Yeah, I haven't been working on it for seven years, but I can speak to a little bit of the history as well. Yeah. It started with the comment rewrite and it started by Sebastian McKenzie, who's also the creator of Babble, creator of Yarn. He did a lot of crazy things.

And one of the creators behind Even Flipper, the project that I couldn't stop talking about when I joined this podcast. Yeah.

Yeah, I remember reading his badge post and I'm like, okay, this person has been behind pretty much every major project and he did it all. He started Babble when he was 17, and I was I was like, it makes sense that he, and since he started Babble and StyleX is at the core, a Babble compiler, it's a problem space he knew well. He was working on it for a few months and then eventually that's where the components team took over 'cause they were building a lot of these components and they were like, okay, I wanna be able to pass styles in. I wanna be able to style.

StyleX started really in the beginning as a runtime solution. We hadn't built out all the build side of things as, and and then, yeah, the features of, before it was like you had to clear your styles locally and we eventually built in, passing styles in at some point and then building in dynamic styles.

So the ability to define functions that take runtime values and then use the style, leverage style prop to, declare it as a CSS variable. So allowing people to say, you have a dynamic height that you don't know what the value's going to be at build time. You only know that when you execute at runtime, then we still allow users to do a lot of those complex patterns.

A lot of type safe improvements to make it type safe. And then a big thing in the past few years has been the theming APIs. Originally, it's like I said, we have StyleX.create and StyleX.props. Those are the main APIs, but there's been so many APIs that we've added throughout the years as well.

The main thing is theming, which is how do we allow people to define shareable values? This gets a little bit, again, into the technical details of StyleX, we have this really. We needed StyleX to work in this really complex packager system that we have. And then that means making all the CSS cacheable per file.

So whenever you declare any styles in a style XX that create call, we need all the CSS metadata from every component coming in to be a hundred percent cacheable profile. And that means that if you can't be importing. Values from other modules. You can't be doing, you can't be, we can only wanna be looking at what's statically analyzable within the file itself.

And so we were thinking like, how do we make it so people can define shareable, like theming tokens. How do we make it easy for people to share values? 'cause that's pretty a fundamental need. And our, the design of our theming APIs is quite clever because it uses hashing that only relies on information that you'll already know within the file.

So we'll look at the variable, we define. StyleX.defineVARs call. And we make it so you have to export that file, that, that variable from a file itself. We look at the exported name and the path in which you're importing that file from, or because we resolve it to, its like root path or whatever.

And then we hash everything. So at every single place where you're importing this value, it's just a variable of referencing a hash. And that hash can be generated wherever you are in the code base. The theming APIs were a big thing. There's and then also the most recent problem that we've been tackling for a while and a big major API has been a API that does something similar to define VARs, but allows you to declare constance it and allows you to declare shareable media queries, which has been a huge

Pascal: Yeah.

Melissa: And then alongside that we've been dealing with a lot just allowing users to keep up with the CSS property. Like we have to remain agile as a system to make sure we like. So a lot of the newer CSS features, like key frames we transitions position, tribe, we wanna add handling and APIs people don't have to dig into the CSS files.

Declare a lot of these pro patterns will handle those behind the scenes.

Pascal: I am actually having a question about this because I feel like you will probably always be playing catch up with the CSS spec and the browsers that are adding new features. Do you have any escape patches? If something new came along, let's just say you didn't support media queries right now, is there a way for people to still make use of these features without them being officially supported in StyleX?

Melissa: So obviously yeah, we do have some more port for pretty much all major CSS features and the core of the functionality will always be there. Some of the things that we don't have, people will functionally have to use a separate CSS sheet. And a lot of the patterns that we don't support right now that are available in CSS are pretty much opinionated patterns, like opinionated constraints we're like, okay, if you wanna create a, StyleX is a solution for styling components, it's not a solution for, all your CSS problems.

If you wanna have a declare like more CSS reset like patterns using element selectors or kind of complex selectors. Or anything along those lines. We encourage people to use a separate CSS file for those needs. Like we say, keeping up with the CSS spec, but, CSS is also like a large monolithic language.

There's a lot of changes happening around it, but we've been able to stay pretty agile and on top of things and, there are all sorts of.

There are all sorts of other patterns that you can technically do that we don't, within the syntax we allow for people to chain a bunch of pseudo classes and do these patterns that are not really like explicitly supported, but we allow people the flexibility to tackle some of these patterns as well.

Pascal: That sounds like you can still do pretty much anything. If nothing is stopping you from adding an additional style sheet to your presentation, then you can pretty much do anything you want. But for the implementation of new features, how do you actually prioritize this? So how do you define, given that you are clearly opinionated about what you want to support, which ones you add to StyleX, and where you say maybe we'll wait for a bit.

Melissa: Yeah I think a lot of it comes back to the community, so it's people are opinionated, people talk and people make their voices clear. So the for the past few years that I've been working on this, like the two biggest, some of the biggest features that we were asking for was defined cons, which is the ability to share media queries.

Across an application and declare constant values. That was hugely asked, but there's a ton of constraints to make that like the kind of around the API design. And then also around work, getting it to work with the haste package with, the packaging system that we use internally, which is this large packaging system that's been around for like many years.

And that kind of does things a little bit differently than, probably a lot how a lot of people bundle their CSS externally. And so like we look at what users are asking for, we look at these asks both in inside and outside the company. We look at obviously we have to think about company priorities as well.

If there's a big party that's coming up with certain styling asks or certain requests, then we'll obviously prioritize some of their things, but. I think it was like from talking to the community and staying within the community, it's pretty obvious what the most common asks are. But yeah, and it's also just whatever sounds fun to us, like we are honestly here to have a good time and some solving some of these problems is it.

We're like, there's, a lot of features that we we're excited to build 'cause we were like, okay, as we style these components, these are things that we want themselves. Of course. 'cause this started with. The design system team. This kind of stayed within the design system team for a long time.

And it's I think I'm best when I still use StyleX to style my own components or style, my website and all of these things. 'cause I don't use StyleX that much anymore actually as a user because I, I stopped writing as much component code when I started working on StyleX, but I think part of it was like, okay, I need to.

Like I started this ambitious project recently to migrate all of the CSS on my personal website to StyleX. And that's okay, I wanna understand the actual pain points of the system itself so I can actually better contribute to it.

Pascal: That is such a classic problem again for infrastructure developers, how at some point you have this risk of become completely divorced from the problems that your actual users face, because you always just think hey, what would be cool to build? Or how would I imagine people use it? But what you're doing is so crucially important to actually build this real empathy with your end users.

Melissa: Yeah.

Pascal: One thing that you've just said in passing but we haven't explicitly discussed as part of this discussion is that's StyleX is open source. And if you say the community, that actually includes not just people here at Meta, but pretty much everybody out there, and that's also why you can use it for your personal website.

Can you talk a bit about the community that has been built and how that is influencing the development of StyleX?

Melissa: Yeah. A hundred percent. So it's actually been hugely rewarding for me as well. Or seeing, I think it's it's so like StyleX is open source at the end of 2023 and we had an internal version of like in the incubator or to get it ready for a few years before that.

But it, yeah, it's been hugely exciting to see the open sourcing. And then more recently it's, so it started out with, just people making videos about StyleX and being like, oh, we're like in anticipation of the system and comparing it to all these styling systems and and people had mixed, like some people love StyleX, like some people like really love other solutions and it's kinda interesting to hear all the discussion 'cause it helps us polish our.

Our own app and make it better. We're like, okay, say what you want, but we'll use this feedback to make us make that, make this system even better. But more recently we've been seeing a lot of traction from a lot of different companies and it's, we have a kind of a community discord where people, who are adopting companies that are adopting the system kind of collaborate with us and tell us our pain points and we'll help them out.

So that's been a big part of us learning as well, and every time we have a company that's onboarding onto StyleX, we're like, it's nostalgic for us. We're like, okay, these are the problems that we dealt with when we were first onboarding, and oh, here are the problems that still exist within the system.

We wanna help them. And every single time that happens, we're polishing our own system. Okay. Recently there's, Figma and Snowflake and have all just been like slowly chiming into the discord and slowly bringing their problems in. And it's been exciting for us because we didn't even know these companies were using this using StyleX until they started coming in here with their questions and we were like, oh, that's fun. I, I had a friend that was at Figma and then he was just like, oh, wait, you, oh, like he was looking through the StyleX GitHub and he's oh wait, Melissa that's crazy. Like we've been using StyleX for months.

And I was like, I did not know Figma was using StyleX.

Pascal: Here's a recommendation, if you want to figure out who uses StyleX, just break it in a really bad way, and suddenly your GitHub will be spammed with interesting company emails. Not an actual company recommendation, but it is quite fun to see how widely your project has spread often without you doing anything. That's the beauty of open source. You just put it out there and you don't have any control about who gets to use it.

Melissa: Yeah. I tried after that I made like a little bookmarklet script and I was like, I need to scrape every website and see who's using it. So eventually we'll

Pascal: Oh, that's a

Melissa: initiative. Yeah.

Pascal: Sweet. So you talked about the obvious benefits. It's highly rewarding when you see other companies using it. It can actually focus your minds on certain issues that you may have neglected in the past, but not everybody's talking about. It's yeah, okay, we really need to fix this.

But can you also talk a bit about the flip side? What are the challenges that open sourcing a library like StyleX creates for you?

Melissa: Yeah, I would say it definitely adds the maintenance load of it because you want to there's some pressure where it's okay, there's a lot of issues that are unanswered in the code base. How do we people are asking for different solutions. The open source solution sometimes differs from like a lot of the internal constraints that we do have, like we are using different configuration internally with, there's still some small forked parts of the system as well. But so I think a lot of it is the taking the time to understand and maintain both sides. So like obviously for open source we have to maintain a bunch of different bundlers for people to integrate it with different apps as well.

We maintain not just the core engine or compiler of the thing, but we need to compete, create the suite of, bundling solutions, example apps, all of these things to make things smooth. So there is like a little bit of like StyleX has grown so much from just being this single solution for www or for Meta internally.

But I think there's also a lot of excitement that comes with that as well. And then, for the most part, people are really lovely in the open source committee. People are always putting up issues, putting up their own commit. Sometimes think we'll have some stuff. One time there's sometimes there's stuff that I want I'm about to take on and then I open the refund and I'm like, oh, the issue I put up, someone's already tackling it and it's really lovely to see all of that.

So yeah that's when I talk about open source being a force multiplier, it's okay, now more than ever if I, sometimes I'll just put up some issues and then try to detail the task pretty well and have it open for help. And then people will often dive in. Like people are super helpful and people who are passionate about the app have things that they want within the app.

Pascal: Yeah, that is the best, especially if you are building effectively on top of another. Space that is rapidly evolving like CSS. And the web platform Flipper, for instance, was built on top of various mobile stacks, and often we've had early adopters that used it, for instance, on a new version of Android that we hadn't actually tried out yet, and they found some issues.

And the fix was already there. So by the time that we rolled out the new version of Android Flipper was already compatible with it because of community contributions, which is super helpful. But one question I have for you is that there is a downside, or at least like a divergence in terms of the release model that you have when you involve open source releases and what we do internally, if you have.

A library inside Meta and you make some sort of breaking change. What you usually do is, because it's a mono repository, you just change all the call sites and you're basically done. That doesn't work if you now also have to code mod effectively the world because you need to tell GVAs like, Hey, this is gonna break now.

So how do you deal with this particular conundrum of breaking changes?

Melissa: Oh, it's honestly awful. And I think that's the difficulty as well with even internally like making changes to syntax or making changes to APIs. Like we've had to write so many large code mods to kind of code, code mod away a lot of like c patterns that we're moving away towards.

And honestly, to this day, we're still. Tackling with a ton of these migrations. And I think like what we've ended up saying is for companies that are adopting StyleX as a new system, it's often easier than TA than what we had like dealing with a very mature adoption set where it's so many of us is like chasing down the old patterns, writing these complex code mods with these edge cases that we all need to manually verify.

And I think that has been like a huge struggle. Or like a huge blocker where it's like, there's so many things that we wanna adopt iternally at this point, or like ways in which we're slightly behind other systems, but okay, like we still have CX that we're still migrating to StyleX, we're running a code mod two, seven years later, there's still maybe like a few thousand files of CX related like code. And we've, we, we've burned it down over the years. It's like a significant, a very small

Pascal: I think I was somebody on a code mod just a week ago. I had a diff in my inbox, so yeah I can confirm it's still going on.

Melissa: Yeah, and I've been helping kind of them out with some of the migration of details of that. And it's so we still have CX and then we have legacy StyleX patterns from maybe five years ago that we're still migrating away from. And we accepted that this will be a slow process, but I think that's where we can leverage, like AI code mods and a lot of these patterns that are not deterministically handable, but we can now tackle some of them with AI patterns and then manually with UI verification figure out if I think we'll be able to see better headway in some of those numbers soon.

Pascal: That makes sense. And talking about numbers, I'm also quite curious how you actually measure your success, because you've talked a lot about the various influences that you have on your roadmap, both internally and externally coming in. But Meta is a very data-driven company, and. I'm curious what else you have in addition to the bundle size that you described before to figure out if you are going in the right direction or you potentially regress something.

Melissa: So I think there's a few, there's like the numbers in terms of the performance side of things. And then there's also the numbers in terms of adoption. And we use both of them to inform our numbers. So obviously like bundle size contributes to things like visual completeness or largest contentful paint numbers or interaction to next paint.

Like those are all related. To the bundle size itself. So like, how much CSS are we gonna actually have to serve? Are we serving things upfront in one bundle? Are we pulling in, are we lazy, loading a bunch of bundles? All of those have their own impacts on the success from a performance perspective of this solution.

Yeah we have some of those benchmarking numbers and we also have some of those numbers internally that we look at. We have. Now for the first time, an experiment framework that's been set up on the packaging side of things to measure some of these numbers better. And then on the adoption side, we also look at, we also look at internal adoption numbers.

We have, we set it up so we tag every diff that's created with StyleX and we say, okay, are how many people are actually modifying code within StyleX? And we have 4,000 monthly developers using that are writing StyleX code today. And then from there we can get a lot of interesting methods, metrics on, okay, how long are people actually using taking to write this StyleX code?

If we're doing our job right and making these features better, time should go down overall of oh, how long, like how long is it going to, how long are people writing on average for these dips? So diff authoring time is another metric that we use. And then obviously we look at

Pascal: Yeah, we've had an entire episode about this. This is very interesting how we can now influence product decisions on frameworks and what you write based on how quickly people get stuff done using your tool. And especially once you can A/B test, which of course doesn't always work, but if you have a brand new API and you can put developers into certain cohorts gets really

Melissa: Yeah.

Pascal: you can literally see like how much time they're safe.

Melissa: Yeah I've thought about this question quite a bit because of course, like you mentioned, I'm always getting bugged and pinged by people being like, okay, what are the metrics tell, give us the metrics. But yeah, it's been interesting to find different ways to quantify all of this.

Pascal: And you briefly mentioned packaging there as one of the. Aspects where you use experimentation to now. Can you talk a bit more about the improvements in packaging that you've recently worked on?

Melissa: Yeah. Yeah. This has been a pretty big portion of the, my work over the past year, which is like a collaboration broadly with the team that kind of handles serving all the CSS and JavaScript and all of that across the company. And it's a really complex problem, especially at Meta scale.

So like I mentioned that we use this really large packaging system but like bundling system that's been around for 15 years at this point, I think. And a lot of it, yeah, it's all written in PHP. It's all, it's a lot of, it's and one of the in perks of this system is they have a really difficult job of handling, how do we serve all this CSS and JavaScript and all these things effectively to users.

In terms of the CSS they take an interesting approach which from, it's a legacy from many years ago, which is like bundling everything by directory. So all of come gets its own style sheet. All of Instagram has its style sheet. Like we look at this analyzable code within each of those points, and we serve up separate style sheets for all of those different things.

But say you're on, you're in WhatsApp and you're just importing one comment component like from that directory based model, you actually end up pulling in the entire directory code for all of facebook.com if you're using just like a button component whatever. We've had lots of discussions on how we can improve this and move towards cohort sheets where what essentially what you're doing is you're looking at all the statically analyzable code from a certain entry point and loading that there.

Which sounds like the obvious solution, right? But unfortunately there's always caveats when you're dealing with something at Meta scale, which is that, statically reachable is pretty broad. When you have people running all sorts of experiments, you might have some code that's theoretically statically reachable, but in practice never really used.

You're part of this large experiment branch that nobody cleaned up. When you try to just run cohort sheets off the bat, you're actually. In some cases you're regressing in the CSS size. So they've been doing a lot of improvements there to figure out, okay, what is, loaded 99% of the time and what is the 1% that we can defer?

And doing a lot of the trade offs there. They've been tackling, but how that affects StyleX is, what that means is, we talked about CSS we're ordering, we talked about all of those lovely ordering guarantees that we have, which is that which actually gets completely overwritten when you have multiple style sheets because with CSS, later loaded style sheets will override previous style sheets.

So there's been a lot of improvements we've been doing there to make the packaging more liable, even when we have multiple style sheets. Cohort sheets. That's one of the main experiments. Then CSS ordering, which is where we're trying to do create using CSS layers essentially, a way to have guaranteed ordering within multiple style sheets itself.

And then a lot of the other fun things related to, okay, like now that we have a ways to experiment with different ways of packaging and, bundling the CSS a lot of other fun things around. Okay. What can we do around, even the way you sort CSS will affect gzipping and kinda all these little fun little experiments too.

Pascal: Wow. Never considered that. That sounds really cool. And this is such an insightful answer because I feel like this expands what people think about when you talk about these challenges. Again, like it is such a simple API that you expose for the most part, where all the complexity is hidden away and the stuff that happens, the base of the iceberg here is so massive and all these interesting considerations like how does the order affect gzipping? My god, I've never considered anything like that.

Melissa: Yeah, that was actually something that, we, we recently migrated over a portion of that stuff in the bundling kind of side of things to open. Our open source sorting, which happened to use a different sort. And we were like, oh, why is the bundle size going down? And we were like, oh, in open source we use an alphabetical sort, which compresses a, which gzip is a little bit happier about compressing And there's so much behind the scenes around some of those things.

Yeah.

Pascal: Yeah, that's interesting. Another interesting benefit of open source where you get a natural experiment.~~ Quick cyber. Is it okay if we run five minutes~~

Melissa: ~~Oh yeah. Yeah. Definitely. Definitely. Yeah. We can run any time over. I feel bad about taking up~~

Pascal: ~~Okay I have another meeting afterwards, but I've already warned them to, I might be a little late. Okay.~~

Pascal: One thing I'm also curious about is that CX and StyleX are still not the only games in town, but there are plenty of other styling systems or. CSS and JS systems out there. So can you tell us a bit about the differences between them?

Melissa: Yeah. So I think CX and StyleX, funnily and updo encompass this branch of two different styling systems that kind of were coming up back in the day. So there's the CSS modules, which are like scoping CSS to, or solving the scoping issue. And then CSS and js, which is people who wanted to co-locate their styles with their components itself.

And then within CSS and js, they eventually branched off into two groups, or it started with a lot of systems that were more runtime injection based, which slowly, people quickly realized it was not the most performant of solutions. And then that leads us to the kind of where StyleX slots in this suite of zero runtime CSS and JS solutions or minimal runtime in the case of StyleX.

And within all of these systems as well, there's a subset of them that are atomic CSS. So based on what I mentioned of a single property value declaration and a single class. And I think all, a lot of them do different things well but there's a lot of interesting things.

StyleX tackles, namely I think the predictability guarantee. I don't think anyone, any styling solution really tackles predictability to the guarantee that we have. A lot of our theming APIs a lot of how type safe our theming APIs as well were allow people to define the exact object or key structure that they would want to be them.

Pascal: So we're running a bit low on time now, but I really want to understand the future of StyleX a little bit better.

And I feel like for this we need to understand how the roadmap kind of gets created. So how do you use feedback that you get both internally and externally from your collaborators and contributors? How do you combine this into StyleX’s roadmap?

Melissa: Yeah, a hundred percent. So like I, I guess one thing, I mentioned that Stax has been around for seven years and I've only been hopping in for the past, like one and a half years. And the previous maintainer or I still collaborate with him pretty closely. Naman and he's not at Meta anymore, but actually a lot of, we make, we brainstorm a lot of these ideas.

We are still in really close collaboration. So a lot of the feedback and a lot of the contributions still come from like a member of technically the external community, but obviously like a long term maintainer who's really still really involved. And then we also, within Meta itself we have a small team or like a small group of people, working on StyleX, so I'll source feedback from them. Run like a monthly meeting where people can pitch in ideas across www. And I hear from different members of the community there, both like teammates who are actively working on StyleX or just other people from www who have their own collaborations and everything.

But yeah, there's some really exciting things that we've been working on. We've been working on a pretty big improvement to bundling solutions and creating like a unified plugin for people to hook in with across all different integrations and setups. The, and one of the big things.

That's coming up for StyleX is the ability to define inline styles. So that's been like a big pain point for StyleX is people don't like how verbose the current API set is. So say they just want to add one style property to StyleX. Then what they'll end up doing is they'll have to create a separate namespace within a create call.

And then they have to end up writing so much code and people are like, okay, I want the ability to just write things in line. So that's a big thing we're experimenting with

Pascal: like that was a contentious issue that had a very long either GitHub issue or Discord thread.

Melissa: Yes, a hundred percent. I'm like, that's, what people love about Tailwind, for example, is just like how quick a lot of it is. And I think, you lose out on maintainability with systems like Tailwind and there's a huge trade offs that kind of come with it. But, yeah. And then, yeah, like a lot of the theming APIs, a lot of dev tools, extensions to make developers lives easier.

A way to write shareable functions. We have shareable values now, but can we extend it even further? And yeah, there's so much that I could say in this space.

Pascal: Incredible. It is too bad. We need to wrap up now. But Melissa, thank you so much for building and maintaining sStyleX here, not just for Meta, but for the entire community and allowing us to write quick, small and efficient CSS and of course for joining me here on the Meta Tech Podcast.

Melissa: Of course.

Pascal: How has open sourcing StyleX been a force multiplier for the project?

Melissa: Yeah. Yeah, a hundred percent. That's something that I've

been thinking about a lot in terms of like my own work in this system where like with, like I, I mentioned before about how the adoption from Figma and all these, people are giving us a ton of ideas, but actually it also gives us a ton of contributions as well, where a lot of times, like when we have ideas, when we have pain points that users are encountering, they're happy to delve in and do it themselves.

We talked about AI being enforceable to hire in many ways. We talk about how like AI is leveraging, people are leveraging AI systems to see exponential progress. But when you pair it with something like open source, it's like, it's that. The interplay between those two is exponential.

'cause I think now with a lot of these tooling, I'll put up an issue, maybe put up some code pointers of something I wanna get done. And then I add a help, wanted to tag on it. And then before I know it, someone has written out their own solution, put up their pr. And I think a lot of these tooling enable people to dive into a code base, which previously could be really intimidating.

And then leverage all of those, the new tooling there to drive a lot of progress. So I think. With both of those in tandem, it's been able to unlock so many wins. Like we have thousands of con, like we have thousands of people using StyleX. We have hundreds of contributors and a really happy, like really okay. I'm not sure exactly where I wanna go with this.

Pascal: You've definitely run over 30 seconds, but a nice answer. I don't wanna cut you off.