Moving on From Runtime Css-In-Js at Scale

I have a lot of slides, so I'm going to be very quick about this. Earlier this year, I found myself thinking about components, thinking about styles, but also thinking a lot about the amount of JavaScript we needed to render our styles. I was going on this spectrum of JavaScript on, we should have very little JavaScript to do our styles, do we actually need a lot more JavaScript to do it? I just spent a lot of time just tilting in this one line.

How I got there was, I was basically assigned this task. Which is, figure out the styling architecture for Primer React. What is Primer React? Primer React is the design system that powers GitHub. I'm Siddharth. I work on the design engineering team at GitHub. This was one big, it's funny that we call them epic, because it was kind of an epic task. And before GitHub, I used to work at all of these companies and for the last six years I've been basically working on design systems and component libraries. Fun fact, just like React, I also started my career exactly 10 years ago today, so thank you for that. I appreciate the balloon. Thank you.

All right, so, back to the moving slide. And why this was such a confusing task? Because when I was trying to figure out the styling architecture for Primer, it ended up being the styling architecture for a lot of React at GitHub. Any tiny change that I make would have cascading effects, get it? Cascading? Effects on all of GitHub. And that's a scary thing to do. So let me first talk about how did we land up in the space that we are.

This is not just GitHub. This is mostly the entire styling infrastructure. Think about it. It's 2015, and this meme just came out. This is that old. The best movie of all time, Mad Max, was also released in 2015, and Drake gave us this extremely cool song. Internet Explorer 11 was still around. Edge wouldn't be released until later that year. Which also means things like CSS variables that we take for granted now weren't actually supported in much except maybe like Chrome or new Firefox. I think Firefox is the first that implemented it all the way in 2014. Different times. You require very little JavaScript to get your styles done.

You write your style like this. This is a button component. You put your colors, put your padding. You see a lot of hex codes, pixel values hard coded over here. This isn't as nice as you'd like it to be, but there was some tooling that existed.

I put it on like slightly more JavaScript because you have to use Node.js and the compiler for JavaScript is written in JavaScript. With a little amount of JavaScript these are the kinds of things you could do. You could nest your styles and have slightly better DX and then you could compile it out back to CSS.

The other thing that you got was variables. You could define these variables in a single place, which is huge for our design systems. And then in our components you could just use those variables. So when React came around in 2013, and then when we started using React, you would use it something like this. You have a button component and it uses the class name. And then you could use this button component in another type of page.

The nice thing that we just did, by defining a component in a different file, and then using it in a new file, is that we've created this relation. We've created a dependency tree between components. And that helps us create smarter bundles, eliminate dead code. You get a lot of tooling from that. But the same kind of tooling doesn't really exist for... Or didn't really exist for CSS.

This class that is coming from button, there wasn't really a good way of knowing which file does it come from. You would just have to guess and bundle a lot more CSS. That of course changed very quickly with just a little more JavaScript with CSS modules. So you could configure CSS modules, you could basically fake an import, is what I'd call it. Because there is no actual CSS import that's happening this way. But we are creating a dependency tree. So now that your CSS dependency tree matches your JavaScript dependency tree, you get this really nice one-to-one between component JavaScript and CSS. And then you can bundle them together. You can tree shake them, you can eliminate dead code very quickly.

The next interesting thing that gets to is even though you have variables in Sass, wow, I see your eyes, I'm sorry about that.

So when you have to do multiple theming, and theming is not just about light or dark mode, theming is there's light mode, dark mode, there's different types of color blindness, same goes for dark mode, there's dark dimmed, so you have a lot more themes. And with something like Sass, because these variables are compiled out at build time, not on runtime, you basically have to generate a lot of theme files for each one of them. So you would have your component library in light, you would have component library in dark, you'd have component library in Teletopia, so you end up creating all of these combinations. But with a little more JavaScript, we could actually do this on runtime with something like style components. Because JavaScript already had variables at that point, CSS didn't. So you end up in something like this. Where instead of writing class name, you define your entire classes with style components, and it kind of looks like CSS, but it's not CSS, and you get JavaScript variables in the middle of CSS. So you get a lot of nice things. You can refer to your theme and this theme can change on runtime and propagate all across.

Some of you might already be using this style. And you can wrap this with a theme provider that takes care of the rest. So something that's interesting is if I add this additional color, I kind of don't really have a way of knowing is this first, is this the right color, is this color defined? Second, is this color going to be applied? I kind of have to write this, render into the browser, see if it works. It probably is just black, so I right click inspect element, and that's when I get to know if it's the right color.

So we add a little more JavaScript and we type script. And with type script now what you get is you can type your theme and then you start getting the red squiggly line, which tells you that this property, FGHover, is actually not even defined on theme, so that's not the right thing to use. And then you can fix it. The other thing, if you haven't noticed, is I kind of messed up somewhere in the slides where background color is just, on hover, it's just pointing to the button background and not the hover background, and with theme, because now you control your theme, you control your styles, you can actually type them smarter, and it can give you smarter errors. For example, border color, I'm using button.bg, which is not actually a valid style, which is not actually a valid color variable in our component system, so we can give you these errors, like, this is not the right one, maybe you meant button.borderColor. Same goes for hover style, it says, HellasPentaCast, a type, themeColorBackground is not assignable. You have to use hover background. And because you have TypeScript, you have a compiler behind this, you also get features like autocomplete, which help you pick the right hover backgrounds.

So customizations are still interesting. This is the default, or the recommended way of customizing components with style components, where you wrap the button component in a style and then you can add your additional styles there. So something like this is nice, but it's also kind of a lot of boilerplate, it's a lot more work. I'm not a big fan of this style because it kind of diverges from the button. You'd have page button and then other thing would use the page button and you kind of get further and further from the original source. So, with just a little more JavaScript, this is team UI's logo, but team UI, system UI, this class of libraries made this syntax popular which is the SX prop or the CSS prop. And with this prop what you do is instead of defining a new component you define your overrides at this component usage level. So it's kind of like an inline tag but it's not, it compiles it down. So what you end up getting is something like this where your button styles are the default styles and then you merge them with the SX overrides styles that are provided. And of course you type the SX so you get the same type completion even in the application with the overrides. So pretty, pretty nice API, pretty cool. So we've gone from less, like very little JavaScript to a lot of JavaScript. But we've kind of got a lot of features along the way, so there's things like nesting, variable steaming, but there's also linting, import dependencies. We have a very opinionated autocomplete that we can configure which would be harder to do without JavaScript. So is that the success? Like is that what we wanted? I guess so. But of course things come with tradeoffs. So it's been such a big success that there are about 4,000 presentational components on GitHub which have the SX prop just for style overrides. And which has caused success problems, like shampoo problems.

Big style updates are slow. So when you have a lot of styles that need to update on user behavior, the updates take a while. Collecting styles for SSR also takes a significant time. And by significant, it's like 10 to 15 percent of the server render time. And then streaming and suspense make it more interesting, because now you have to time your style updates very, very smartly. So looking at all of these updates, I started thinking about, OK, a lot of these problems are about, when are the styles injected? And maybe I don't need to do it on runtime. Maybe we can compile these styles out. So I added another feature right at the end, and I wanted to solve it with just a bit more JavaScript. So it could be a Babel plugin that reads the AST, looks at the styles, and then compiles them out into CSS files.

So I looked at other solutions first. So vanilla extract is a good example of this, where they ask you to write your styles in a CSS.TS extension. So you're writing the same object styles, but these can be compiled out, and you get the type safety, all of the nice things. I'm slightly short on time, so I'm going to skip the boring parts. This is boring.

Another nice solution is Atlassian compile, which matches the style components API more and compiles your styles out into .CSS files, so that the users just get CSS files. So a good example of this would be take all of this code, put it in a CSS file, and then put the class name back. That's kind of what the users get, that's what developers author, this is what the users see. Kind of nice. Of course it's not perfect, there are some nuances that come with compiling styles out. One, your authoring experience is slightly worse because JavaScript is very composable, you can do a lot of things, but if you want them to be compiled out, your JavaScript set is restricted to things that can be compiled out. And that can cause confusion, that can cause weird APIs to make that happen. I have a very tiny proof of concept of this, it's called CSS-out.js, it's a Babel plugin, if you want to see the, it's like 50 lines of code just to see how it works. It's on Github, this could be a good introduction to it.

So, success, right? Now this should definitely work. We have our styles, we can compile them out, and the tiny thing that we ran into is that GitHub.com, the one most of you use, actually doesn't use Babel, it uses SWC. And that's when I discovered that if you go far enough on the JavaScript spectrum, you actually end up in Rust, where a bunch of bundlers like SWC, Parcel, they're all written in Rust, and then there are things like efbuild which are actually written in Go. So I found myself, if I have to write a plugin, maybe I should learn some Rust and write a Rust plugin so that we can use with SWC. And that really scared me. So there are 4000 presentational components, but they're across 20 subpackages, and 20 subpackages in a lot of teams, and all of this complexity that we're asking people to overtake, 20 different subpackages in multiple teams, they have very different level of familiarity with this entire JavaScript, TypeScript, Rust tooling. So we often talk about the right tool for the right job, but I think there's an asterisk there. It has to be the right tool for the right job, for the people who need to do that job. So my perfectly compiled stack might be a really good stack, but if it doesn't work for the people that need to use it, is it really a good stack? And I also realize it's not 2015 anymore. And a lot of these things that we got from moving on the spectrum, a lot of these are already getting there. So for example, CSS variables are already part of the CSS spec and widely supported. Theming is already there. There's a proposal for nesting that's supported and some browsers were coming to more. There's container queries that are becoming a very wide spec. Similarly, there are solutions for linting and imports that are more native to the CSS world. So for example, there's Tileint for linting, and PostCSS can give you CSS-module-like features very easily.

So it looked like we could probably use a lot less JavaScript now that CSS has become more JavaScripty, more variability. The only thing that we don't have here is an opinionated autocomplete and there are some good examples of this.

Oh shit, I missed something. Okay. So there is an increased diversity in JavaScript bundlers. There's parser, ESBit, SWC, etc. But the diversity in code editors is actually going the other way around where VS code seems like the default option. Even online browsers like Code Sandbox or StackBlitz also use VS code under the hood to make it possible. If you can support VS code, you can make a big part of the developer population happy. So that's the direction I started looking in.

Tailwind does a really good job at it. Use the extension, they use a language server to understand what you're trying to do, look at your theme, and then suggest classes that actually match your own theme. That's very smart. Similarly, this is from Shopify's Polaris. So Polaris is Shopify's design system, and they have an extension which uses something similar to suggest CSS variables in CSS that are actually part of their system. So again, you can have very opinionated, you can see it's not just suggesting everything, it's suggesting shadow because it understands that you're trying to use it in box shadow. Which I think is very cool. So I tried to play around with this as well. It was surprisingly hard in the wrong ways and easy in the things that I thought were hard. And you can actually get very opinionated things, you can also get lint errors, where it can stop you from not using the variables that the design system team doesn't want, but actually use the ones that we do want you to use, even if the values are the same. So there's a lot of intelligence that you can bake into your developer tool. There is no good open source API, open source library to do this yet. So if any of you want to be popular, have that GitHub Star fame, this is a free idea for you. Finally, right, that should be it. Now we're using CSS, we have the tooling for it, this should definitely be enough. Almost. Remember I said we have 4,000 presentational components that use SX? So we kind of have to move all of them to CSS so that we can use this new tooling. And one way to do it would be, let's just do it one at a time, refactor it, let's ask teams to do it, deprioritize users, deprioritize bugs, and prioritize migration to CSS. Or we could use some tools. So remember this magic thing I showed earlier which you can do with a baby plugin and decided it would be hard to do it for so many different bundlers at the same time.

We could do it one at the developer step instead of the build step. So there's a very good library called TS Morph. It basically looks at the typescript AST and lets you write transformers that can change your code. So it's pretty smart in the types it gives you. So depending on the type of the variable, it could be a JSX opening element or a self-closing element, it can differentiate the two, you can look at the JSX attributes, and then you can get very smart with it.

So for example, the first one is pretty easy. If it's margin 10, then I know that I have to pick this up, put it in a CSS file, and put a class name here. But then because we're using an entire typescript compiler, we also have the option of following variables around. So for example, if in SX, you're passing base styles, you can actually trace these variables across multiple files and compile the value from there. Similarly, if you're calling a function, you can find the function definition and from the function definition, return a class instead of an object style. So you can get really clever, really wild with something like this. And that's how I'm hoping that we would migrate those 4,000.

Now, the one thing that computers are not so good at is naming things. Even though we have a lot of context in the file, you can use the file name, you can use a component name. A lot of the class names actually ended up looking like this, where there's a wrapper container stack and then a hash at the end of it. And that's the thing that computers are not good at. I guess they are, but I don't know enough AI to be good at it. So it's very, the code that is generated is not very maintainable in the long run. So the way I'm looking at it is, it's not an automated migration. It's an automation-assisted migration. And that's the way to do it. You run your command, it gives you some code, you review it like a developer would, and then if you like it, you might suggest some class name changes, and then you ship it. I will be raising a seed round because it says automation-assisted, and that qualifies as AI. You can meet me in the Q&A after with your goods.

So the final thought, should you drop CSS in JS as well? It depends. So if you find yourself somewhere on this spectrum, and you're thinking, we've got way too much... Wait, this is not the slide. If you're on this spectrum, and you think, we're happy where we are, we don't have the performance problems that this guy talked about, all our developers are very good at JavaScript, we don't really need to bother, then stay where you are. It's a happy place to be. I spent a lot of years here, I was pretty happy.

If you have a team that is very good at JavaScript, very good at the tooling, and you would like to invest more time in improving your developer experience by actually improving the editor, improving your plugin system, then definitely go more JavaScript, that's where most of the fun is. If you're like me, and you find yourself in a place where your team is very mixed, a lot of designers, developers, different skill sets contribute to the same codebase, then I'd recommend go all the way to the left and use CSS tooling, CSS native tooling, it's kind of really good now. You'll be surprised at how far you can get with very little JavaScript.

That's kind of it. I'm going to do that again because I spent way too much time on this slide. And that's all. That's my talk.

All right. So we have a few questions coming in on the slide. People see you as an expert opinion on CSS and the different CSS tools and libraries. So I've got a bunch of different ones. So we're just going to go and you're going to give me some of your thoughts on them.

The first one was what are your thoughts on panda CSS? Never heard of it. No opinion. Sorry.

So maybe later on in the speaker Q&A they can come and show you and we can find out. Yeah, I'd love to. And then we've got another one. What do you think of tailwind CSS? This one you expected. Yeah. Yeah. Definitely. So we explored as part of all of like the exploration for this project, I explored tailwind as well. And less tailwind specifically, but more the idea of a utility style CSS which also has very good tooling. And it's a very promising idea for us. There are certain aspects in component land where if you have a component library and you want to add overrides, it's very hard to do it with just class names. Because the order in which you give class names to an HTML element doesn't really matter. What matters is the order that they show up in the CSS. And if you distribute it all across a big application, you can't really control the order. So you need some runtime CSS to make sure you're deduplicating these class names to make that happen. And that's where we started shying away from it. Because we were really on the path of we don't want to runtime solution.

Because we were really on the path of we don't want to runtime solution. The other thing was I showed it to multiple developers. And some developers said I love it, and some developers said I hate it. This is not a tech conversation anymore. So we did not go that way.

Awesome. I think the cameramen are having a little CSS problem. They're like, put the spot there. It's like a grid. Center and a div. But we get there in the end.

Another question that has come up is what are your thoughts about CSS in JS major libraries like MUI, struggling within service side rendering? Should we come back to CSS modules? Or will libraries evolve? That's a very good question. There is a path for libraries to evolve and play really well with service side rendering, suspense. There is a direction there. I do feel like there is a murmuring that is happening of like maybe we don't go that way. And maybe we rewind a little and go to CSS. So for libraries like MUI, I'm really curious of what they're thinking of in terms of I'm sure they find themselves on the same spectrum where they could go a little more JavaScript and actually start building bundler plugins for all of these different bundlers, or go the other way around and drop or compile out runtime CSS altogether.

Now that makes sense, that makes sense. Now this next question, hindsight, is 2020 and if you could rewrite prime from scratch, which stack would you use? If I was starting today, with the team I have today, I would probably go CSS first because we have a lot of really, really good CSS developers that are really smart designers as well. So I would go there, and I feel like we're at a point where it wouldn't be so much of a tech decision, like because I compared all of these, made all the pros and cons chart and it kind of just came down to, this one looks prettier, so I would say skillset is how I decided today.

I love that as well, picking a stack based on the team members and their strengths as well. Good readership, good readership. We've got another one, what are your thoughts about critical CSS as it's quite a solved problem with CSS in JS? Yeah, yeah, it is. I think one thing that we would definitely stick, like the only thing that we're taking from CSS in JS world is something like CSS modules, and even though we might do it with CSS, but the idea of each component file has a CSS file tied to it. And then as you compile your JavaScript tree, you can also attach your CSS tree on top of it. I think that's an idea that's invaluable and would stick around for a very long time. And that also helps you solve for things like critical CSS, tree shaking, knowing when to delete code. I think the dependency tree is something that that's going to stay for a while.

Nice. One thing I also love about watching developers give presentations is I often get exposed to new developer tools that I really really get jealous of and really want.

And someone's asked, what's the TypeScript extension that you're using? The TypeScript extension for? I think it was in your slides, but your slides in the code editor in your slides were using the TypeScript. Oh, nothing. That's just Keynote. Good design. Good design. That's just like, I typed and I drew the rectangle to get the TypeScript thing. Yeah. Styled it so well. All right, we'll do this one as the last one.

What about namespacing CSS, something that styled components are delivering already? Yeah, I think it's interesting because it kind of depends. If it's a... We're kind of partitioning this half an hour implementation where the library components, we're not namespacing them. So you might get something like a Primer button. And that stays the same across the stack. But something like an application component where things like wrapper, stack, container are actual legit names, those were namespacing because we don't want any conflicts. So the same dependency tree that we get, we also get the ability to hash these and have them conflict-free with that. So something like CSS modules. Thank you, Sid. Everyone give him a round of applause.