CSS in React Server Components with Josh Comeau === Paige: ~So we will get started. Uh, one, two, three. ~[00:00:00] Hi, and welcome to PodRocket, a web development podcast brought to you by LogRocket. LogRocket helps software teams to improve user experience with session replay, error tracking and product analytics. Try it for free at log rocket. com. Hey everyone. I am Paige Niedringhaus and I'm a staff software engineer at the IOT startup blues, and today we have Josh Como, an indie hacker and an educator here to talk about CSS and react server components. Welcome to the show, Josh. Josh: Thank you. It's good to be here. ~ ~ Paige: We are very glad to have you here. ~So before we start talking about React server components in particular, uh, could you tell us a little bit about your previous experience at places like DigitalOcean and Splash and how those kind of influenced your career and getting to where you are today?~ Josh: ~One thing, uh, the company is Unsplash, not Splash.~ Paige: ~Got it.~ Josh: ~So I don't know if you want to re say that and~ Paige: ~I will. Yes, I will definitely redo that. ~So Josh, before we get to react server components and CSS in particular, maybe you could tell us a little bit about your background and how time your time at organizations like digital ocean and unsplash helps influence your career and where you are today. Josh: Yeah,~ uh, ~it's interesting. I've worked at a handful of companies in my career. ~Uh, ~Unsplash was maybe one of the smallest. ~Uh, and ~it was interesting because it was, for a while, like one of the top 500 websites on the internet or something by traffic. [00:01:00] So very popular. ~Um, ~but the whole team was like six people,~ uh, ~and for a while, ~like ~the front end team was me, which was kind of fun. It was, it was interesting, right? Because it meant that ~like ~I could sit with the designer and just come up with ideas and build them in an afternoon. And then millions of people,~ uh, ~are using it. ~Uh, ~so it was really cool. ~Uh, ~DigitalOcean ~sort of ~on the other end of the spectrum, at least for the companies that I've worked at, I think it was like 700 people, ~something like that.~ ~Um, ~and ~I, ~I do think ~it's, ~it's really valuable,~ uh, ~for people to try a range of different company sizes or just work cultures,~ uh, ~cause it really is ~like, like, ~I could not have told you before starting, but I much prefer working on small teams where you can move really quickly. ~Right. ~DigitalOcean is really cool too, in the sense that it is a useful product that,~ uh, many, ~many people benefit from, ~but you know, ~it's not the same. ~Like there's so much, uh. ~There's so many processes that you have to go through in order to make the thing that you want to make. ~So, you know, it's, ~it's just worth trying different environments to see ~what, uh, ~what works best for you. And it's a good way to try lots of different technologies ~and sort of.~ grow your skills more quickly. Whereas I think not always true, but often when you spend ~many, ~many years at the [00:02:00] same employer on the same project, it's hard to avoid stagnating, right? It's hard to avoid just ~sort of ~getting into a flow with, okay, ~you've, ~you're familiar with the whole thing and you know how to tackle new problems. ~And it, it, uh, ~I find at least,~ uh, ~it's really valuable ~to, ~to try new things and jump into new frameworks and systems and all of that good stuff. Paige: So would you say ~that ~that is part of what kind of influenced you to become,~ uh, ~an indie hacker or start, ~you know, ~sharing what you knew with the community and teaching other people things that you'd picked up along the way? ~Mm-Hmm.~ Josh: It definitely was a part of that. ~Yeah. I mean, you know, ~it's,~ uh, ~Having gone, I think I've worked at ~like ~six or seven different companies now, something like that. ~Um, ~and you certainly ~like, ~you pick up a lot of different things and discover what you enjoy,~ uh, ~working on, ~you know, ~I started my career actually as a backend developer. My first job was as a Ruby developer. Paige: No kidding. Josh: ~uh, ~yeah, ~like wait, ~2014 or so,~ uh, ~we're going, and even before that. I was tinkering with PHP,~ uh, ~so lots of,~ uh, ~backend stuff way back in the day,~ uh, ~but, ~you know, ~I discovered pretty quickly that I really like focusing on interaction and user experience and building frontends,~ so, uh, yeah, ~the decision ~to, ~to ~sort of ~jump ship and do my own thing and [00:03:00] focus on courses,~ so, Uh, ~it was a lot of different things, partly it was,~ uh, ~I got ~like ~a nerve injury that made it hard to type for a few months. And it was a good sort of wake up call that ~like, ~Hey, there's,~ uh, you know, ~your ability to type is not infinite. Like you have a certain number,~ uh, ~of years where you can do that comfortably. So it might do that. I think that's not necessarily true, but, uh, it was just a good wake up call that if there's this thing I want to do, I should probably do it sooner rather than later. And I did, I spent a few years teaching at a coding boot camp here in Montreal. We have a university, Concordia University. They partnered with this company, Journey Education. And so we did both ~like ~full time 12 week programs and part time 8 month programs. And for a few years I was helping out at the part time program, both as a teaching assistant and also as the lead instructor for one cohort. ~Um, ~but yeah, ~it was a good, uh, ~it ~sort of ~made me realize that, oh, this is really satisfying. ~Like, ~it's really nice sitting with somebody and helping and, ~you know, ~like trying to guide them to have that light bulb moment. And so what I'm doing now is really ~sort of ~the same thing, but,~ uh, ~at scale, like to many thousands of developers. Paige: ~well, ~I have to say as a boot camp graduate [00:04:00] myself of a 16 week coding boot camp here in Atlanta. ~Uh. ~Thank you for doing that because it gave me a career that I never could have imagined would be as fulfilling and satisfying as the one that I have now. So to all the people who are out there teaching and instructing, keep doing it because ~you're, ~you're changing lives for sure. Josh: ~I'm glad to hear that. ~I'm glad to hear that you had such a good experience with it. ~Uh, ~I do think for people who want to get into creating online courses or starting a YouTube channel or whatever it is, right. Teaching developers online. ~Um, ~doing it either in person or remote, but in real time in a sort of coding bootcamp setting is ~really, ~really valuable. ~Um, ~cause you know, it's a good way to sit with somebody and you can tell right away if your explanations make sense or they don't. ~Uh, ~whereas like when you're writing a blog post, you don't know that until after you publish and after you've spent ~many, ~many hours working on it. So it's a really good way to ~sort of ~build the teaching muscle is to teach in person or in real time. So definitely,~ uh, ~people do ask me a lot like, Hey, I want to start creating my own chorus or. ~Uh, ~[00:05:00] starting a YouTube channel or a TikTok channel or whatever it is. ~Uh, ~and I think that's a great way to build sort of the prerequisite skills for that sort of thing. Paige: ~Well, ~I think ~that ~that actually is a great segue into your topic today, which was teaching people about how to handle CSS with react server components, which really have thrown the entire react community for a loop for the past year or so that they've been out. So maybe you can start by explaining the significance of next JS 13. 4 when RSC is really started to come into. Being used in production as well as the app router and just that whole new world that opened up for us. Josh: ~Yeah.~ For most of React's life, we've had the ability to render on the server, right? Server side rendering has been around. It's nothing new. But it's typically been very limited in that the code runs on the server, but the only thing the code is doing is generating the initial HTML and the exact same code is then going to run again on the client. So you can't [00:06:00] really do things like database queries because if you write your code, to connect to your local Postgres database or whatever it is. Well, that same code is going to ship to the client. And then of course the client won't be able to connect to the database and you shouldn't try anyway. ~Um, ~so we've had this big limitation that server side rendering was really only meant to be used for optimization, right? To create the HTML more quickly but not to serve as like a full stack framework or to do the typical things you would do in a Rails app or in PHP. Paige: Right. Mm Josh: ago was add these functions, like getServerSideProps. And this was kind of clever. ~Uh, ~what they did was build this thing outside of React that would ~sort of ~sit in front of React. So ~when you would go, ~when a request would hit the server, the Next code would run first, and then it would take the data, ~you know, ~you would connect to your database, you'd do your query, and then it would grab that data and feed that into the React server side rendering. And ~so, ~It was outside of React, but it accomplished the same sort of goal that you would have with a full stack framework. ~Um, ~[00:07:00] but it was always sort of, uh, I mean, a hack is too strong of a word. But it was, ~you know, it was, uh, ~wiring this thing up to do what you wanted in a way that didn't really feel natural, right? React didn't have a way to do this. The big innovation with react server components is now we have the ability, we have a new type of component. So now ~every react application, well, actually, that's not true. ~Every next 13. 4 plus application and other, ~you know, ~remixes in the process of adopting server components. So there may be lots of ways to access react server components. But in this new paradigm, we have two types of components. We have client components, which,~ uh, this is, uh, a little bit of a gripe I have with this whole thing. Client component ~is a very misleading name, because it implies that the code only runs on the client. But really, the term client component is a new name for an old thing. Every React component you've ever written is a client component. It just means,~ uh, ~that it does run on the client. ~Uh, ~and in this new paradigm, we also have server components. And these are sort of the new thing, right? This is the new innovation. Which is now we have certain components that can only run on the server. And what this allows us to do, if we know that the code is never going to make it to the client, it's not [00:08:00] going to be included in our JavaScript bundles, it means that we can do database queries and do any sort of other,~ uh, ~private work that is used to generate the markup for that component. ~Very, ~very similar to how backend frameworks like PHP work. And I know that like for, for non-reactive developers, they hear this and they think like, goodness, you know, the React people have reinvented PHP and they've over-engineered this thing that we've had for 20 years or longer. But, uh, the thing that makes this really interesting is that those server components live alongside the client components in the same application, right? When you work with PHP or Rails. Once the HTML is generated on the server, the framework is done. ~Like ~there's no way to also handle interactivity. ~Um, ~and so it's really cool that now in the same react code base, you can have some components that only render on the server while other components will still render on the server as part of server side rendering, but still have the ability to hydrate and to handle interactivity on the client. ~Uh, ~so that's a lot of words, but hopefully that,~ uh, ~[00:09:00] does a decent job kind of summarizing. ~Uh, ~this new paradigm that we find ourselves in. Paige: Yeah, I think that it does. And one of the questions that I have been wondering, and that I think the React community in general has been wondering, is how is this going to impact the React ecosystem long term? ~I mean, ~we're seeing, ~like you said, ~Remix and other frameworks are starting to pick up React server components. But to be honest, I don't feel like I'm seeing as many people actually talking about how they're shipping react server components to production as they're in their own applications. As I thought I might, after a year plus of it being out and available for people to use. Josh: Yeah, it's a great question, and I think this is ~sort of ~an open question. But,~ uh, ~with most React features, like with hooks, right? Hooks were a big deal when they came out. ~Um, ~but any React developer could bump the, I forget what version, 18 maybe is where they were introduced. ~Um, ~they could bump their react version and use them in whatever application they already have. ~Uh, ~server components are different because server components need to be tied into the bundler. ~Um, ~[00:10:00] they're not the sort of thing you can drop into a Vite app or a create react ~app ~app or any sort of existing,~ uh, ~system. And so it is going to be interesting to see like how widely do these things get adopted. I do think it's still very early,~ uh, ~even like next 14, which is the major version that came out recently. ~Um, ~it still doesn't feel entirely ready for primetime in my opinion, like it's certainly production ready. ~It's not, um, you know, ~it's not ~so, uh, ~far from being ready that you can't use it, but I've been trying to use it and there's just like a lot of little things that you stumble into, right? ~There's still, ~there's still sort of sanding down the edges. So I think it is still early. It is this massive project that ~was sort of, it ~was being worked on behind the scenes for a few years. ~Um, ~and I think it'll be a few years more before we really see ~like ~the full potential of this system. But it's a good question that like, you know, in five years, I don't know what percentage of React applications will use server components. ~I don't think it's ever going to be, uh, like, ~I think maybe there's ~like ~a hard cap at ~like ~70 percent maybe. Like we're never going to see 100 percent because there's just so many React applications that are not built,~ uh, ~with [00:11:00] Next or with whatever future frameworks come along that support server components. Paige: Yeah. Josh: So it is going to be, it's not going to be like hooks where it just becomes the de facto way that everybody, pretty much everybody uses. ~Um, ~but I think for those who are starting new projects or those who will be starting new projects in the years ahead,~ um, ~there are some really compelling things with this, right? There is a real reason that they're doing this and it is pretty frigging cool to be able ~to, ~to mix and match these server components and to have things, ~you know, ~like ~I ~I'm building a blog and,~ uh, ~my blog has lots of interactive elements. And what I've had to do in old react, because in old react,~ uh, ~every component runs on the client and if you have 50 blog posts that each have their own interactive components,~ well,~ you don't really ~have a way to say, well, I mean, you do, uh, you ~have a way to load specific components in specific blog posts, but you have to rely really heavily on lazy loading,~ uh, ~which means that ~like ~things may not be fully interactive at the same time as the rest of your react application. ~Um, ~With server components, you have a little bit less of that concern because anything that ~you know, ~if the code is needed on the client, it'll be included in the [00:12:00] client bundle. ~Um, ~but you can expect to see your bundles get a little bit smaller because you might have a bunch of components that are only necessary on the server that never get included. Paige: Yeah. That's a great,~ uh, ~way to approach it, I think. And that actually is a very good segue into one of the things that you mentioned specifically about CSS and React server components, which was your preference for using styled components, which actually became a little bit of a sticking point with RSCs. So maybe you could talk about how that, ~you know, ~what are the challenges that you started to realize you were facing when trying to use ~CSS? Server compo or~ styled components with,~ uh, ~server components. Josh: Yeah, I suppose I should quickly introduce,~ uh, ~so style components is a CSS in JS library. I've been using it as my preferred way of writing CSS for many years now. ~Um, ~The thing that I really like about it is that ~it gives us sort of, uh, it, ~it takes the idea of react a little bit further where, ~you know, ~before reactor in like a typical ~vanilla frame or not vanilla, but like ~plain JavaScript environment,~ um, ~your concerns are separated by technology. So you have CSS [00:13:00] for styling JavaScript for behavior, HTML for content and structure. With react, we have this new unit, right? We have the component, which is like bundling up all of those things in one. So instead of having a button style sheet and a button JavaScript module and a button HTML template, you have a bucket component that bundles up all those things. ~Um, ~style components ~give~ allows us to essentially create our own mini abstractions that bundle the HTML and CSS for a component together. ~Um, and it just, it feels really nice when you lean into this, uh, you know, like. It does take some getting used to. Um, but I think when you, when you actually sort of buy into the premise and when you use it the way it's sort of, uh, nudging you, when you use it in the way that it's nudging you, hold on, I want to say this again. ~ ~Let me, let me figure out where to pick up from. ~ ~Yeah, so, uh, ~when you use style components in the way that,~ like, ~the documentation tries to encourage you to use it,~ Uh, ~it's really quite a lovely experience that it feels ~really, ~really nice. ~Um, ~the trouble in this new world is that every styled component Is expected to run on the client, right? When style components was introduced,~ Uh, ~server components weren't in anybody's,~ uh, Sort of, uh, ~future plans. ~So,~ Paige: Yeah. Josh: it makes heavy use of context. So that if, for example, you have a theme That has a bunch of theme [00:14:00] variables Like colors and breakpoints,~ Uh, ~you can pass those variables Through the react tree, through context ~Uh, ~which works ~really, ~really well. The problem is that context isn't available in server components. And this is another reason that I say ~like, you know, ~maybe ~things, ~we're still sanding down the edges with both ~Next, uh, ~Next app router, which is the router that they built using React server components, and React server components themselves. ~Um, ~it was sort of planned to have some server alternative version of context. But it shipped without one. And so, there isn't really a clear way to understand or to see how it could work as is, right? ~Uh, ~the way style components works, you're expected to have all this code run on the client. And this is kind of a bummer, because, ~you know, like, ~you can still have it work. ~It's, uh, ~I think a lot of people think that it's incompatible. ~Uh, ~with react entirely or with next entirely. And that's not quite true. You can still use styled components with next 14. The problem is that any component that renders even a single style [00:15:00] component will have to become a client component, which means that you lose a lot of those benefits, right? Most of my react components have at least one style. ~Um, ~and so any component that needs any little bit of CSS is now going to be included in your bundle,~ uh, ~and downloaded on the client.~ Uh, ~which is ~kind of ~a bummer because you want to take advantage,~ uh, ~of this new, this fancy new world. Paige: ~Right. ~And ~you've just, like you said, ~you've just completely lost the ability to take advantage of RSCs because you have components. Even if you're not using hooks, even if you don't have useStates or useEffects or whatever, the fact that you were styling your components in a particular way has just eliminated your ability to try RSCs really at all. Josh: Yeah, and ~you know, like, ~it's interesting because it really feels like a bummer,~ like, ~as developers, we want to take advantage of the latest and greatest thing, and there are real potential performance benefits. Paige: Mhm. Josh: But at the same time,~ like,~ we haven't lost anything, right? And this is something,~ uh, like, ~if you currently have an application that uses styled [00:16:00] components or Emotion, right? There's a bunch of tools that are sort of, uh, we're talking about styled components because it was ~sort of ~the original,~ uh, ~library that ~took this, ~took this approach. But there's Emotion, there's a few other smaller ones. ~Um, ~if you have an application that uses one of these libraries, You're not actually gonna experience any degradation if you bump to next 14, even if it means that every Component has to be a client component because that's the current reality, right? That's the reality beforehand that every component was a client component. So you haven't lost anything and it is the sort of thing that It may actually not be a bad idea to ~like ~wait a year or two and ~sort of ~let some of those edges get Sanded down. Maybe we'll see new libraries come around ~Uh, ~that make it really easy to switch over. ~Um, so it's certainly, uh,~ I think that there has been a little bit of catastrophizing about this. ~Like,~ it, it is legitimately,~ uh, ~too bad that you lose some of these benefits, but at the same time, you're no worse off than you were yesterday, right? Like, it's not actually a step backwards, you're just not able to take as big a step forwards as we would like to. Paige: Yeah, ~and like you say, ~the React team is [00:17:00] still working on new features and additions. So maybe we will get that new, ~you know, ~context,~ uh, ~that we need that is server side so that it can start to work again as it was previously. Josh: Yeah, that's, I'm keeping my fingers crossed. And honestly, even if we don't, There are alternative ways to solve this problem. Like I think there's been no shortage of CSS libraries that have been released,~ uh, ~in the past little while. And while you can't build something that works exactly as styled components works, because we're missing this sort of fundamental piece inside react, you can still do a lot of really cool things. ~Um, ~there's actually a library called linearia or linearia. I'm not sure how you're supposed to pronounce it. Um, It's not new. It's been around since ~like ~2016 or something like that. ~Maybe not, ~maybe 2017,~ uh, ~but many years. ~Uh, ~so they were early to this and their whole idea was giving you an API that looks and feels almost exactly like style components, but instead of [00:18:00] having that code run in real time in the browser, it compiles that code to CSS modules. ~And so. ~You can still ~sort of ~use it as you would a style component. But when you go to build your application, it takes all those styles. It dumps them into a CSS module. It adds the little import statement so you can pull them in and any style component gets replaced with the HTML tag with the class name that was generated. ~Um, ~so this library sort of years ago, years before server components. Solved the hardest problem, which is how do we have this nice API that we like using,~ um, ~while still getting all the benefits? Because when you do this, when you compile to CSS modules, none of that code needs to run on the client. There's no context being used. There's no state, there's no effects. ~Um, ~so Linaria is this sort of already ready to go solution. Now, the drawback with this is that you lose the ability to pass values through context. So Themes, for example,~ uh, ~with style components, anywhere in your CSS chunk in your template string or your object, if you use object styles,~ uh, ~you can ~sort of ~pluck the theme from context. [00:19:00] You can't do that in Linearia. Instead, you're going to have to import,~ uh, you know, ~like in my case, I have a breakpoints object, a colors object. ~Uh, ~actually for colors, I use CSS variables, which is another really cool,~ uh, ~workaround for this. But for breakpoints, I have ~like ~a JavaScript object that I have to import into any file. So there's like a little bit more friction there. It's not quite as nice as it was with style components, but you're getting 95 percent of the developer experience and it's ~like ~this huge potential benefit to user experience. So I think it's a pretty good trade. Paige: And does it feel pretty similar in terms of writing CSS to how you would write styled components? Or is it ~like a, a ~quite different syntax? Josh: It's the same general syntax. Now I should say I've been leaning on CSS variables for quite a few years. So for example. Say I have a component that,~ uh, ~has a color prop,~ uh, ~the styled components way to then apply that color to the styled component is to use interpolations. So you would pass to the styled component like color equals color, and then [00:20:00] inside your styled declaration, you would say ~like, ~Color, colon, and then you would pass ~like ~a little interpolated function that grabs the props object and grabs the color from that props object. It's hard to describe this, right? If I could show you all, it would be more illustrative. ~Um, ~but that's like the style components way to do that. I don't think you can do that in Linaria. But what you can do and what I've actually been doing even before any of this was an issue is instead of setting it as a ~dollar color, ~dollar sign color prop, I would set an inline style that sets dash dash color equal to color, right? Declaring a new CSS variable on the style component element. And then inside your style definition, setting color equal to var dash dash color, right? Plucking the value from CSS variables. So this is how I've been doing it for quite a long time. And I really like this approach because it does feel like we're relying more on a plain CSS rather than a JavaScript abstraction, which is good. ~I think in cases like this. ~And it means that I haven't really had to change anything about how I create styles, right? I'm still using Linearia almost [00:21:00] exactly the same way. ~Like, ~in fact, I'm currently working on a new version of my blog that uses Linearia. And most projects, or most files, I can copy paste them, change the import from style components to Linearia, and it pretty much works. The one exception is breakpoints, which I ~sort of ~mentioned before I was plucking it out of a theme. Now I have to import it in my module and then interpolate it in. ~Um, ~so there's ~like ~a little bit of friction there, but,~ uh, ~it's pretty much the same. ~Uh, ~the one drawback I would say is that linaria itself,~ uh, ~is pretty well maintained, but the next JS linaria bindings are not. Um, so there is somebody that sort of created, and I realized this is like, we're really down the rabbit hole here. ~Um,~ somebody created,~ uh, ~next with linaria rather than next linaria. So a new package. And this new package works great, but it's ~like ~one person working on it. And for a while they had this big warning about not using it in production because it was still in beta. That warning has since gone away, but it still feels a little bit ~like, uh, ~like that XKCD comic where you have [00:22:00] the boxes and boxes that are stacked on this one little rectangle at the bottom. ~Uh, ~it does feel ~like, you know, ~I don't know that this is something I would encourage everybody to jump on because if this person stops maintaining it, then you have this pretty critical dependency. A project that I'm really excited about is called ~pigment, ~pigment CSS. And this is a tool built by the material UI team. So material UI,~ uh, ~was the Google design system,~ uh, ~or I guess material design was the Google design system. Material UI is a react component library that uses that design system. It's the most popular react component library. It's downloaded. I think ~like ~a quarter of every react download also includes material UI. So it's massively popular. That component, yeah, which is surprising to me because I don't feel like I encounter it that much, but yeah, no, it's apparently super common. ~Uh,~ that component library is built using Emotion. ~So, ~they're running into all the same problems we've been talking about, and their solution is to create their own CSS library. Now, it uses the same general idea as Linaria. In fact, it uses the same sub dependency that manages all that compiling to [00:23:00] CSS modules business. ~Uh, ~but now you have this team. ~Uh, ~that is, ~you know, like they, they're ~putting real resources behind it. There are full time people working on it. ~Um, and ~I don't know where they are exactly in the process. ~You know, ~we're recording this in late June. ~Uh, ~I suspect in the next few months, maybe we're going to see material UI, their popular component library offer the option to switch from emotion to pigment. And if that goes smoothly, then maybe in the next major version, it'll only be pigment. ~Um, ~but what this means is that,~ like,~ pretty quickly, it's going to go from a library that is still in,~ like, sort of ~early beta to,~ like, ~one of the most battle tested CSS libraries out there, because when people start switching over, and especially when it's the only option,~ uh, ~there's gonna be millions of projects that all of a sudden use this thing. Which is what you want, right? You want to be building your application using tools that are really battle tested that have teams behind them. So it does feel like we're in a little bit of an awkward limbo now where if you use style components or emotion or even material UI or other component libraries that use these tools,~ um, ~you're sort of stuck, ~sort of ~wondering, like, should I move to [00:24:00] tailwind? Uh, you know, there's sort of this weird situation that you're in. ~Um, ~I think the weird situation is temporary. And I think that things will improve as these tools continue to evolve. Of course, you can also migrate to a different CSS tool. Uh, but I know for myself, I like the way that I write CSS. And I, even if I wanted to. It would be too big of a project,~ right, ~to change,~ uh, ~hundreds, I think I have ~like ~130, 000 lines of code between my blog and my course platform. I don't have the time to migrate that to a new CSS tool, one that isn't at least similar in its API. Paige: ~Well, ~I'd love to, to dive in a little bit more when you say that you have, you really like the way that you write components. Because one of the things that you mentioned either in your talk or in your blog about this was your registry approach. So I was hoping maybe you could talk a little bit more about that for listeners and explain to them, ~you know, ~what your approach is for that sort of CSS. Josh: ~Right. ~So I should clarify.~ Um, ~the registry approach is something that ideally the tools will do for you. So as it stands, [00:25:00] essentially the registry is the way that it's like the implementation of how do we get the styles to work with server side rendering. Um, and it's interesting, uh, when we think about it, right. Even in ~like ~an older next application. ~So ~without react server components, the code is first rendered on the server. We generate the HTML. We send that HTML to the client. It hydrates on the client. How do we make sure that that very first HTML, like the first thing the user sees is fully styled, right? Because if we only render the HTML,~ uh, ~you're going to have a flash of unstyled content where you get just the raw HTML. And then on the client, React would kick in and generate all the styles, right? If you use style components in, uh, like a spa type framework and a client side routing context,~ uh, well, ~then everything happens on the client, ~right?~ You generate the HTML and the CSS. But with server side rendering, that HTML comes first, and so you have to make sure to also generate the CSS. And so the idea with the registry is that as you're server side rendering all of your components, you're ~sort of ~plucking out every style that you see, and then you're [00:26:00] injecting them into the head of the HTML document right before that file is released to the client. And this also is something that would be impossible without context on the server. There are some, like, potential workarounds, but they're a little bit funky. React has this new API called react. cache that can ~sort of ~be used for this. Paige: huh. Josh: but yeah, no, in terms of ~like, uh, ~actionable takeaways for the user, you shouldn't really have to worry about any of this. ~Like, uh, ~even as it stands, ~like ~with older versions of next, you still do have to set it up yourself because there isn't ~like ~an official style components next binding. But at least to me, it seems like this is all just implementation details. ~And ~ideally,~ uh, you know, the, ~the packages of the future will not have you worry about any of this. Paige: Alright, so we're not going to worry about that then, but I would love for you to talk a little bit about how you. ~Right. ~CSS and think about CSS for anybody who maybe they're less familiar with it. They're a JavaScript developer first, and it's not something that they feel super comfortable with. What kind of advice or tips would you [00:27:00] offer to help make it a little bit less confusing? Josh: Yeah, I mean, it's tricky, right? And I really empathize with people that are in this situation. I was in this situation for a long time myself, where for ~many, ~many years, my attitude with CSS was that,~ like, ~I was just hoping that the CSS gods were in a good mood that day and they weren't gonna,~ like, ~throw me any curveballs. I think we've all had that experience where,~ like, ~you're chugging along, you're implementing the future, everything is sunny, And then all of a sudden,~ like, ~you use a CSS snippet that you've used a hundred times before. It's always done the same thing. And now today, it's just, ~you know, ~the box is in the wrong place. The box is invisible. The box is scrolling when it shouldn't be scrolling. ~Um, ~we've all had these experiences that are super frustrating. And I think they're frustrating because CSS doesn't give you the same kinds of debugging tools that JavaScript does. ~Like, ~there's no console log. with CSS, right? ~Like ~either the element is doing what you expect, or it's not. And it's pretty hard to like, unpack that and figure out what's going on. The only real solution [00:28:00] I've found for this is to build a deeper understanding of CSS. And so much of CSS is under the surface. ~Like, ~there's all of these mechanisms that are described in depth in the CSS specification, But that you will never encounter in your day to day life as a developer just through experimentation. Things like stacking contexts or containing blocks. ~Um, ~really important concepts because if you don't understand them, this is what sort of causes those surprises, right? CSS is a super,~ um, ~declarative, I guess is the word, language, where like you write a little bit of code that tells the CSS engine what you want to do. And all of these like implementation details and all of these like little mechanisms kick in behind the scenes, ~and ~And everything in CSS is relational, like if one property on one element,~ uh, ~will do very different things depending on the context that it's used in, right? Like the width property, if you set width 100 pixels, you'd be forgiven for assuming that means you will always get a box that is 100 pixels wide, but that's not actually [00:29:00] true, because it depends on what else is going on ~in the, ~in the application. If that element with the 100 pixel width is dropped into a flex container, and if that flex container is only 80 pixels wide,~ well,~ Flexbox,~ right,~ the Flexbox layout algorithm, it's all about flexibility, and so it's going to try to squeeze that element to fit in the available space. But that's not a behavior that you'll see if you're not in Flexbox, if you're just in the standard flow layout. So there's a bunch of things in CSS that really, really helps if you understand ~sort of ~the underlying mechanisms. You have a mental model for how it works, That's not like the easiest thing in the world to build. And I think that people really get ~kind of ~fooled by CSS because when you're starting, it's all so straightforward, right? Color red, like the early steps of CSS make it seem way more simple than it actually is. It's a little bit similar to TypeScript. Like with TypeScript, you start, you're like, okay, this is a number, this is a string. ~Uh, ~and then before you know it, there's error messages that require tooltip. Paige: Right. Josh: Like just those paragraphs and paragraphs of [00:30:00] meaningless nonsense. Um, I feel like CSS has a similar like hockey stick style difficulty curve, where it's all fun and games at first, but once you actually try to build like a real world application,~ uh, ~all sorts of things get thrown in your way. ~Uh, and ~the way that I solved that in my own case was, I actually made ~like ~a conscious decision because I spent, ~like I said, many, ~many years struggling with CSS and just ~sort of ~crossing my fingers. ~Um, ~I made the decision that from now on, whenever one of these situations happens to me where I use the snippet I've used a hundred times before, and it doesn't do what I would expect, I would actually ~like, ~settle into the problem and try to figure it out, so I would ~Um, you know, ~experiment ~sort of ~poke and prod and see if I could understand like, okay, what if I remove this property? What if I add this property? ~Um, ~you can go read the MDN documentation. You can read the CSS specification, which is surprisingly accessible. ~Um, ~you can really ~like ~dig into these problems. And when you do that, you'll discover,~ uh, ~slowly at first, but more quickly and more quickly that like things that seemed totally arbitrary to you actually make a lot of sense. And that the way the language is designed,~ Uh, ~isn't actually as chaotic [00:31:00] as it seems. Um, I should also in the, you know, apologies for the self promotion, but I do have a course on this subject called CSS for JavaScript Developers. So I've sort of taken all of the stuff that I've learned about this and compiled it into a course. So that is an option as well. But certainly,~ uh, ~you could do what I did and just ~sort of, uh, ~take the approach of problem solving and,~ uh, ~digging into things when you encounter them, because I promise you, ~you know, ~computers aren't illogical. They're not arbitrary. ~Like ~it's not actually random whether something happens or doesn't happen. There's a reason. It's doing what it's doing. ~Um, ~and you can understand that reason and work that into your mental model so that it will stop surprising you. Paige: Yeah, and as a person who has bought that course and is ~only a, and it's ~only still partially through it, I can say that I enjoyed CSS before I knew what I have learned from your course, but things like understanding collapsing margins, which I think was a blog post that you even pulled out and just put on your website as a separate piece of content. ~Yeah. ~Has made debugging my own CSS woes so much easier. So [00:32:00] I would highly encourage anybody who even ~like,~ just like CSS to check it out because there's a lot of stuff in there that I didn't know that has helped and made ~my my develop ~my own development a lot better because of it. Josh: ~Well, ~I appreciate that, Paige. Thank you. ~Um, yeah. ~And I should also mention, I have a bunch of stuff, like I have, as Paige mentioned, plucked out a handful of lessons from the course and published them on my blog, so you can get it like a little, ~you know, And ~I really, I've actually tried to pluck out some of the more,~ uh, ~valuable things. So my blog has a bunch of CSS content that should prove helpful. Paige: That's great. And I was absolutely going to ask you, but Josh, if people don't want to read the specifications themselves or go into the MDN docs, is there a more streamlined approach to getting to CSS? But you did it very well yourself. Josh: I'll be into it. I appreciate that. Paige: You did. All right. So let's go back a little bit to the server components and styled components and CSS and things like that. You've talked about how Linaria is using CSS modules [00:33:00] to. ~kind of ~take away that issue. ~Um, ~there is another one that you mentioned in your post Panda CSS. Is that a good one to consider as well? Josh: Yeah. So pandas CSS is interesting. It didn't really work for me, but it may work for you. ~Um, ~pandas CSS takes a different, but similar approach where instead of compiling to CSS modules, it compiles to utility classes. So essentially it becomes tailwind under the hood instead of CSS modules. And so you get all the same benefits, right? It becomes totally static. There is no need for a runtime, so it doesn't have to run on the browser. All the same performance benefits. The problem with Panda CSS for me is that utility classes can't express relationships. So for example, say I have an aside component. And I have a TextLink component. And I have some styles that, like, when the TextLink is within an aside, I want to change the styles that are applied, right? I want the same component to change the styles contextually based on where that component is rendered. With style components, [00:34:00] you can express this by saying you can literally interpolate in a component and it'll transform that into the generated class name.~ So you can say like dollar sign squiggly bracket aside space dollar sign.~ ~Actually, you can say, I'll say, I'll say that again. ~So you can say dollar sign squiggly bracket aside and then the ampersand, which is the character for the current thing. ~Um, ~and then any CSS you put in that block will only apply to the text link component when it's within an aside. And so this is like a really powerful tool that I use all the time because it allows me to set up all of the styles for a single component in one place, right? ~I don't have to remember to like, ~I think how a lot of people solve this is they create a different component. So you have a side link instead of text link. ~Um, ~but the problem with this is ~now you have to remember or ~whoever's creating the content has to remember to use this. Every single time you put a link in the aside and I don't have the discipline for that. So what's going to happen and what I've seen happen in that approach is like just randomly 20 percent of the links in your asides are different styles because they're using a different component. I don't want to have to worry about that. I want to make it so that like just automatically without any sort of developer intent, the styles for an element will change depending on [00:35:00] their context. And I want all of those styles to be written in one place. So I don't want to go to the aside component and say, okay, when text link is rendered in this component, apply these styles. Because when you have five or six different places that do that, all of a sudden to understand what the text link is going to look like, you have to check five or six different files. It's hard to know if you found them all, especially like a lot of developers solve this by not selecting for text link, but selecting for the anchor tag. Paige: Mm hmm. Okay. Josh: classes, doesn't really give you the ability to do this. Now,~ uh, ~Tailwind actually does have some sort of ability to do this. And I'm not a Tailwind developer. I forget what exactly the [00:36:00] API is called, but ~I, ~I have posted about this and people have said, no, actually Tailwind does let you do this. But as far as I can tell Panda CSS doesn't, it may be something that they add. ~Um, but, uh, ~for that reason and that reason alone, I ~kind of ~ruled Panda CSS out. I had like minor gripes with it too,~ like,~ it generates a bunch of stuff that then lives in your project. And,~ uh, ~I just found it like a little overwhelming that there were all these files all of a sudden. ~Um,~ That's not the biggest problem in the world. ~I could, ~I could get used to that. That's fine. ~Um,~ but you know, it just ~the, ~the feel of the library. ~Uh, ~I wasn't like immediately,~ uh, ~satisfied with it. And so because there are all these other libraries, I've chosen to ~sort of ~lean into other. ~Uh, ~other tools, but I do think like I say,~ right,~ it solves the most important problems if this isn't,~ if,~ if you don't typically use these sort of contextual style patterns, you may find pandas. CSS works just fine for you. Paige: ~Yeah. ~Are there any other trends or technologies, either with CSS and JS or, ~you know, ~other stuff that's coming in the React ecosystem that you're particularly excited about or that you think has a lot of promise and [00:37:00] potential? ~Yeah.~ Josh: Yeah, it's a good question. ~Um, ~I think ~it's, ~we're sort of in a time now where I'm just waiting for things to stabilize. ~Like I'm, ~I'm eagerly awaiting the world where I can use all these new tools without having to ~like ~diagnose and debug weird issues or open new issues on various repositories. Paige: Yeah. ~Um,~ Josh: I'm so satisfied with all the tools that I'm currently using. ~Like ~Framer Motion is an animation library that I lean on quite a bit. It's absolutely incredible. ~I use, ~I use MDX for my blog post, which allows me to take like arbitrary react components and drop them into the middle of a markdown file, which is ~really, ~really cool. ~Like, ~I think we're ~sort of ~spoiled in our ecosystem with how many great tools we have. Now the problem is just waiting for everything to. Adopt React 19,~ uh, ~and become ~sort of ~fully stable and ready to use. Paige: Fair enough. So what kind of advice would you give for developers who are trying to navigate this transition of using react server components, but still potentially using a CSS and JS framework for their styling? ~Are there, are there any,~ [00:38:00] is there any advice that you would give in particular or things that they should look at or try out first? Josh: Yeah. ~I mean, ~and I sort of alluded to this earlier. ~Uh, ~I think my advice for somebody in that situation is to not worry too much about it. Like you can keep using style components. You don't have to upgrade, you don't have to migrate. ~Um, ~as we've been saying, like in a couple of years, I think things will be a lot more,~ uh, ~the path will be a lot less daunting. ~Um, ~so ~like today, ~this week, I don't think you have to do anything. ~Like ~keep doing what you're doing. You're doing great. ~Uh, ~don't worry too much about all this stuff. But yeah, like if you wanted to start exploring the new world, I do think ~that it's ~the best way is to try it. ~So ~I would start ~like ~a new project, ~you know, it's like a weekend, maybe not a weekend, but like a, you know, ~a small, a few day project where you can ~sort of, uh, ~install the new, ~you know, ~maybe try linearia, try pigment CSS, try pandas CSS. ~Uh, ~that's ~sort of ~what I did when I was,~ uh, ~trying to make sense of this is just spend a few hours building ~sort of like, you know, ~to do list applications using these different tools and getting a sense of how they work. ~Um, ~and you may discover that actually some of these tools work even better than the tools that you're already using. ~Uh, ~that would be lovely. ~Uh, ~but you can also sort of, ~if you, ~if you have ~the, uh, maybe ~a similar experience to what I had, which is,~ uh, ~realizing that some of [00:39:00] these things aren't quite ready for primetime yet, that we're still in the process. ~Uh, ~then you can keep chugging along with emotion style components, whatever you're using,~ uh, there's no need to, uh, ~and like we said, right at the top, it's not clear whether this actually will be the predominant way of building react applications in the future. It may be that because so many established companies like have their back end and go right, they can't adopt some of this new stuff. I don't think client side react is going anywhere. ~Um, ~and depending on the application that you have,~ like, uh, ~and this is a wild tangent that I'll try not to take us too far down. We focus so much on performance in the context of how quickly does the page load? How quickly does that first paint happen? How quickly is it interactive? And this is extremely important for some businesses. ~Uh, ~if you have an e commerce platform, if you're competing with Amazon,~ uh, ~or really anything where visitors,~ uh, ~are searching, ~you know, ~if your traffic comes from a search engine and you are one of many products or applications, like if the person knows they, if the site is slow, they can hit their back button and try the next search result. Yeah. Yeah. Yeah. ~Uh, ~[00:40:00] that's the sort of situation where this sort of performance is really important because~ every hundred, ~like, you know, the statistics say every hundred milliseconds cost Amazon, however many millions of dollars. ~Uh, but you know, ~if you're building an internal dashboard,~ uh, ~it's not like the person's going to say, well, it took 1. 7 seconds to load instead of 1. 2 seconds, so I'm going to quit my job and go work for, you know, you don't have options in many of these cases. ~Uh, ~that's not to say that performance doesn't matter. It still is really important. But the first couple of seconds is only the first couple of seconds of the journey, right? There are other parts of performance that matter so much more and Client side react handles most of those situations just fine In fact it happened it like client side react handles them much better than many other options Like if you have a PHP application It's those subsequent navigations that are going to be a lot slower than they are with client side react All of that to say that,~ uh, ~I don't think any of us have to feel like,~ uh, ~we're at risk of our current tooling becoming obsolete. ~Uh, ~if you use [00:41:00] something like Vite,~ uh, ~or maybe Parcel or Create React App, ~I mean, ~Create React App is ~sort of, ~you probably do want to migrate away from that because it's unmaintained. ~Um, but ~any sort of client side React tooling. I don't think you have to feel any urgency around migrating to something full stack or ~super, ~super bleeding edge modern. Paige: ~I mean, ~I can speak from experience because I work on a next JS app at my company and we haven't even ended up migrating from the pages router to the app router yet because a lot of our Actual website content is MDX documents. So ended up that we would have to ~kind of ~reconstruct our entire file system to move to ~the page router file based routing, or sorry, ~the app router file based routing, and it just. Didn't make sense. ~It, it, ~what we have right now with page router works very well, and it would be probably a lot more pain to get to the app router than to continue the way we are. So yeah, for the time being, we're just not going to migrate. Josh: Yeah, I'm actually in the exact same boat with my course platform. So I have two major [00:42:00] projects that I maintain right now, my blog and my course platform. The blog I am essentially starting fresh and rebuilding, redesigning. ~Um, ~and for that, I'm using the app router and all the shiny new things. ~Uh, ~honestly, even that,~ like,~ I'm doing it because it's my job to teach this stuff and I feel like I should have a real project that uses it. But my course platform is still using Pages Router. It's probably not going to change for at least a few years. I'm happy with it. It works great. I'm not really too worried about it becoming obsolete. I think that's going to be the same calculation that a lot of people make. So ~it's, ~it's validating page that,~ uh, your, ~you've come to the same conclusion at your organization. Paige: Well, Josh, it has been an absolute pleasure talking to you today. Is there anything that we haven't covered about CSS and React server components that you'd like to talk about? Josh: Hmm. I don't think so. I think we covered all ~the, ~the major beats of it being a really exciting tool that is still really early and that,~ uh, ~it certainly will solve some interesting problems. But if you don't have those problems today, then you don't really have to stress about them. Paige: ~Well, ~if people want to either get in touch with you, learn more about [00:43:00] your courses or find out more about some of the great content that you've shared online, what are the best ways to reach you and find you? Josh: Yeah. ~I mean, ~my blog is ~sort of ~my home base. It's joshwcomo. com. My last name is C O M E A U. That's really where you'll find all of my stuff. You can also join my newsletter there, which I try to make actually valuable and I include some stuff that I don't put anywhere else every now and then. ~Um, ~I am regretfully still on Twitter,~ uh, ~under Josh W Como. I'm also on LinkedIn. ~Um, ~and I'm starting to become more active on Mastodon. So you can find me in most of the typical online hangouts. Paige: Very nice. Boy, I haven't heard anybody talk about Mastodon in a while, so it's good to know that it's still out Josh: ~it's, ~it's interesting. Front end social is the Mastodon server and it's, there are so many like absolutely lovely people that have stopped using Twitter and it's ~like, ~Oh, ~right. ~All of you, wonderful people. I get, it's kind of nice. It feels a little bit like Twitter used to feel.~ So I'd highly, you know, ~it's certainly a lot quieter. ~Um, ~and it's still,~ uh, ~I'd say in its early phases, but if you want to ~sort of ~hang out with people that you haven't seen in a few years and.~ You know, ~see a little bit of a different sort of vibe. I think [00:44:00] it's pretty cool. Paige: Yeah. We need more peaceful social places on the internet to talk and hang out with people. Josh: totally. Paige: Well, Josh, thanks again for joining us today. It's been great having you on the podcast, and we look forward to your next blog or talk or, ~you know, whatever you, ~whatever you do next. Josh: I appreciate that. Thanks. Thanks so much for having me. This has been a lot of fun. Paige: All right. We will see you on the next episode of PodRocket.