Sam Magura is a Software developer at Spot. He joins the show alongside, Jack and TJ to talk about his article, "Why We're Breaking Up with CSS-in-JS".  He was the second most active maintainer of Emotion, a widely-popular CSS-in-JS library for React. But realized it came with a big performance cost and added unnecessary complexity. He describes the specific inefficiencies that he has encountered while using it and how he came to realize them. Moreover,  he talks about his solution to these performance problems. 

Welcome to React Roundup. I am your host, Jack Harrington, and with me today is my esteemed colleague, TJ Vantoll,

 

Hey everybody.

 

as well as Sam Magura. Hi, Sam. Yeah.

 

Great

 

So,

 

to be on.

 

Sam, you did a blog post recently around CSS in JS. So, yeah, you want to talk a little bit about that and then we can kind of see how that segues into other things?

 

Yeah, sure. So I wrote this post in October. It was titled, Why We're Breaking Up with CSS and JS. And it's kind of a combination of my personal journey with the technology and then also at my company's spot, like how I saw them using the technology and how I eventually realized that it was really harming us in terms of runtime performance of our React app. But yeah, so the post, I basically... Um, just went through like, you know, what's attractive about this technology, uh, which is like, you get the locally scope styles. You can use JavaScript variables in your styles. You can put the styles right in the same TSX file as your component. Like there's a lot of convenience that comes with it. Uh, but there's also a lot of nasty things that come with it. Like, uh, so I was actually a contributor to the emotion project, which is the second

 

Oh wow,

 

most popular.

 

like so you were bought in.

 

Oh yeah, I was way in. Yeah, I was like the, pretty much the number two contributor to that project for about a year, which isn't saying a ton because the project is not, it receives like critical maintenance only basically. It's very hard to contribute to. Like it's still written in flow and

 

Oh

 

just

 

no way, really?

 

it is, yeah.

 

Oh my

 

I was

 

God.

 

actually working on converting it to TypeScript, but it was a huge task.

 

I'm guessing a lot

 

Yeah.

 

of people don't even know what flow is, but okay.

 

Yeah,

 

It's an alternative to TypeScript, real fast.

 

the Facebook

 

Well.

 

version of TypeScript. Yeah.

 

Yeah.

 

To take even a bigger step back, I wanna start by just saying we should define CSS in JavaScript.

 

Yes, please.

 

Sure.

 

Just

 

Yeah.

 

for our very basics, let's say maybe you can get us started with what is the tech, I guess we can focus on the positive too early. What sort of things drew you in? Maybe give some real world examples of how you've used it successfully.

 

Yeah, I mean, so just at a super basic level, I mean, back in the old days, you had your HTML file, you had your CSS file, they were separate things. You wrote classes in the CSS that applied to the HTML, but I'm not really sure what caused people to think we should start writing those CSS classes inside of our JavaScript, but that's

 

I think I know

 

really

 

what it

 

what

 

was.

 

it is.

 

I mean, I think they just

 

Okay.

 

wanted, I just wanted a single file.

 

Yeah,

 

It's probably

 

it

 

that

 

is

 

easy.

 

pretty nice.

 

Yeah. Like you had to have this external CSS file and it was either in the same directory and I got like a directory per component. It was a huge pain in the butt,

 

Yeah.

 

but you

 

And

 

can have

 

I mean,

 

it all in one file. It's

 

CSS

 

easy.

 

organization is like a historic pain point for

 

Oh yeah.

 

any,

 

definitely.

 

any large company, any large app. So you have like different CSS structures and, but like those, those can get hard, especially

 

Yeah.

 

like

 

They're

 

on

 

fine.

 

large teams, right? And then you end up with this situation where it's like, oh crap, what is, what styles are you even controlling this random header or button I'm in? Like it might be in three different files in three different places. And it's,

 

Yeah.

 

it's a challenge that we've had for a long time.

 

Definitely. Yeah. And I think the core challenge there is that CSS is global by default.

 

Mm-hmm.

 

So you style your class dot my button, anything in your entire huge enterprise app that has that class is getting those styles. And so CSS and JS kind of fixes that by making styles locally scope by default. And it does that by generating like a artificial class name. for each piece of CSS that you write. And so that's one of the big appeals to it, in addition to being in the same file as your React or other JavaScript code.

 

It amazes me how much we've done to get around cascading in cascading

 

Hmm.

 

style sheets.

 

That is

 

You

 

really

 

know,

 

true. Yeah.

 

right? That was supposed to be the benefit. You're supposed to be able

 

Hahaha.

 

to create like a body tag that has the other right font and then everything cascades from that.

 

Mm-hmm.

 

we want to get around it. So yeah, we did the CSS and JS. So why is it inefficient? Did you drill down into the actual implementation and find out like

 

Um,

 

why

 

so

 

it's taking so long?

 

I profiled some of our components that we're using it heavily. I didn't like thoroughly profile emotion itself, but I do have some pretty good guesses for why it's not performant. Um, so one of them is you write like a CSS string or an object style in your JavaScript code, and then emotion has to convert that to a serialized style is what it's called in the code base.

 

Okay.

 

Um, which is like a piece of CSS text that can be directly inserted into the document. And the way it's shown in the emotion documentation and how I think a lot of people do it is that that style serialization happens on every render of your React component. So if your component's rendering, you know, 15 times per second, it's doing all this work to serialize those styles for every tag that you use CSS and JS on.

 

Oh wow.

 

on every render. And so I think that's a big performance cost. And then another one, which is much harder to observe is that, uh, like the way almost every CSS and JS library works, even compile time ones is when a component mounts, it inserts its style into the DOM. Um, and browsers like to cache like all of the style rules for a page. And so whenever you have a new component mount, It inserts new style rules and that invalidates this kind of internal browser caching mechanism, which causes the browser to have to redo a lot of work. So that's, it's hard to see that really in practice, but that is another performance impact from it.

 

Yeah, I think it's funny because at its core, the CSS in JavaScript is somewhat replacing some of the browsers built in ways of handling these processes because

 

Mm-hmm.

 

the browser, by default, the browser is going to handle the CSS sort of parsing and applying it to things. And essentially you're somewhat replicating that in JavaScript. And the difference

 

Yeah.

 

there is if the browser is doing it, it's like optimized

 

Yeah,

 

C code.

 

that's C++. Ha ha ha.

 

It's

 

Yeah.

 

yeah, that's running that's running in the background that's doing this on your behalf. And if JavaScript is doing it, it's first of all, more code for the user to download, um, just the, the downtime. But I think the bigger cost is the, like, like you said, the runtime nature of this, cause JavaScript's just got to do more work that otherwise it would just defer to the browser to take care

 

Yep.

 

of.

 

And also the stuff the browser is doing is totally separated from the React render loop. But if you're serializing those styles and render, it's happening every render, which you want to limit what happens every render as much as possible.

 

Yeah, the browser can multi-thread

 

That's

 

the

 

true

 

handling

 

too,

 

of

 

yeah.

 

some of this stuff, whereas your JavaScript code is not. It's

 

Yeah.

 

that stuff's just got to happen. And I think too that it's another one of those situations where it really depends on the scale you're operating with, I feel like, because just to take the simplest example, if you're building Hello World with CSS and JS and you're adding one or two components, there's like a 0% chance you're going to notice any performance issues.

 

Oh

 

Definitely.

 

yeah.

 

Because... It's going to parse a small group of styles. It's going to paint them. It's going to do them in like two milliseconds.

 

Mm-hmm.

 

It's not going to be human perceivable. No one's going to care. And that's probably true even up to, I mean, my guess would be even to like small websites that it's almost going to be somewhat negligible. But I'm curious, what was your flag, what sort of cued you into this? Because there's might be a problem that this might be something that... you needed to investigate. Were you getting like user reports of problems? Was it starting to get to the point

 

Yeah.

 

where you could like visually see differences or?

 

That is a really good question. And I'm going to have to think very hard back in my memory to remember why.

 

Hehehehe

 

So yeah, we have a pretty big app at Spot. And I was tasked with just improving the performance of the app overall. And

 

Mmm.

 

so

 

Okay.

 

I was both looking at things like using a service worker for caching and also like once the app is loaded, how do we optimize the rendering of these React components? And so I think I started where everyone should start, which is using the react dev tools profiler and in that profiler, I saw that. So, uh, at spot, we weren't just using emotion, like directly on Dom elements. We had all of these kind of style primitive components like box and flex and typography and heading one heading two, which are actually react components. that we're using emotion to apply styles. And I just saw that these little components were actually a kind of non-trivial amount of our render times in the profiler. And so that's what caused me to be like, all right, I'm gonna take this page, I'm gonna rewrite it with plain CSS, and I'm gonna compare the performance. And that was really like the kind of aha moment where I was like, that cut the render time in half. So.

 

Oh wow.

 

Half of our time rendering this component was just attaching CSS to these box components and these flex components and these typography components. And it's like, we were really deriving very little value from those components over like using something like CSS modules or utility classes, which would have been much more performant. And so,

 

So

 

you

 

it

 

know,

 

wasn't the

 

big

 

existence.

 

costs, little value, yeah.

 

Yeah. It wasn't the existence of box that like, cause I think folks. Like we want to, I think there's a sentiment out there where we want to reduce the number of components overall. Like

 

Yeah.

 

there's some overhead, neat, natural overhead to, to components. What you're saying is the fact that there was a box that's fine. It was the fact that we had, that we're laying out box with this particular method of CSS. That was the problem.

 

I think that's kind of a complex issue. So yes, the, the fact that we were using CSS and JS inside of that box component was the main problem. I think the total number of components is really maybe focused on too much. Like, uh, just in my experimentation, like React is very efficient with dealing with large number of components.

 

Yeah!

 

Um, and then the third thing I would say though, is like, if you have a component called box, you're going to want to style it with props. which means you're either using CSS and JS or you're using inline styles, neither of which are ideal for performance. But at least inline styles don't really hurt your render times. It's only more of a browser performance thing.

 

It's funny. The other thing you have listed in your article

 

Mm-hmm.

 

is that is how CSS and JavaScript clutters the react dev tools. And that's

 

Oh

 

something

 

yeah.

 

I've ran into before as well. And it seems like such a small thing, but like those sort of developer conveniences can really just make your life more difficult. And

 

Definitely.

 

those, those little things like that do do legitimately translate into lost time, lost productivity, lost money. all those sorts of things, because you don't want to be sifting through all of these from your image, like insertion, emotion,

 

Mm-hmm.

 

CSS, because then you're looking at this and your brain loses any construct of what this component tree actually is, because

 

Yeah.

 

it just looks like a hot mess.

 

The signal to noise ratio is just really low there. Yeah.

 

Yeah.

 

Um, yeah, I mean, it's like, if we're using this technology because we feel like it has a better developer experience, then it really is fair to criticize it and that while the developer experience is not better when you're using the dev tools.

 

So then I'm curious then you've you identify these problems, you decide that there is some definite performance gains to be made. I do wanna get in a chat of like what sort of things you do recommend now or what other things you investigated, but

 

Mm-hmm.

 

I'm curious your process of if to choose to migrate away from that, like what is that process like? Did you end up converting the app or is that something that's in progress?

 

Yeah.

 

How much of a pain did that end up being?

 

Um, so I guess I'll start with like, what do I recommend now? Which

 

Yes,

 

is,

 

please.

 

yeah.

 

What is

 

Um,

 

the magic answer? Well,

 

Yes.

 

yeah,

 

I guess I'll

 

basically

 

go convert all of my

 

CSS

 

apps.

 

modules are the magic answer for me. I mean, they provide the locally scoped styles. Uh, they, I mean, you don't have to do it this way, but a lot of people will write a CSS module right next to the, uh, component. So like you have my button dot TSS, my button dot module dot CSS. It's not in the same file, but it still keeps things closely tied to each other so that it's not confusing. And I like the extra power that SAS gives you. So I actually do CSS modules with SAS. But I mean, if you don't like SAS, you don't have to use it. That's just kind of like extra syntactic sugar on top. And then I do kind of like utility classes for really simple things like. You want to make this div have display flex. Like, it's annoying to have to define a CSS class for that. So I do think utility classes have their place. We are using kind of a forked version of the Bootstrap utility classes, which was mainly because that's what I was familiar with, having used Bootstrap for many years. Of course, Tailwind is the most popular utility class

 

new hotness.

 

framework. Yeah, which. I have some opinions on Tailwind.

 

Oh yeah?

 

I haven't used it that, that much, but yeah. I mean, they even say this in their docs, like it's effectively like writing inline styles, so you end up with a lot of duplication and, uh, I'm sure someone who loves Tailwind would tell me why my opinion is wrong, that that's a bad thing. But yeah, I just feel like, uh, huge benefit of CSS is that you can define a class once and then use it in a hundred places.

 

Yeah.

 

And I just don't really see how you're supposed to do that with tailwind. Um,

 

Well, Jack likes Tailwind, so

 

Well,

 

okay.

 

I'm waiting

 

Go

 

to hear

 

for

 

the

 

it.

 

defense here.

 

do I like it? I'm conflicted about it because on the one hand, I love like MX dash two, right?

 

Mm-hmm.

 

That is so nice. Like I,

 

Definitely.

 

you know, just throw that into a class and you're good. Right. But then when I look at like a button and the buttons got like 40 classes on it and

 

Hehehehe

 

it's just like, what is going on? You know, and so it's very, it's like cognitive dissonance when it comes to this. I just, I, you know, it's hard for me to justify it really. So yes, I like it, but I also don't like it.

 

Yeah, yeah, so I guess we're using a more of a pared down utility class approach where we do have the MX-2, but we're not trying to apply all of the button styles just with the utility classes. We

 

Yeah.

 

just use CSS modules for more complex things

 

Right.

 

like that.

 

I think actually if I, if there was, you know, I'm, I'm sure you can do this, but you can just basically take tailwind and take all of the, like, cause there's, there's definitely there's there's CSS that's like layout and there's, there's CSS that's styling. And I'd like to have the CSS that's styling kind of, you know, be one thing. And that layout thing, the MX two or whatever. I think that that's really handy. Just being able to say like flex, flex, blah, blah, blah, blah, blah. And you're good. Like that. That would be right. Is that sounds like it's something like what you've got. You've got basically CSS modules plus

 

Yeah,

 

that or.

 

so kind of the way I do it is like, if I can write all of the styles for this element just with a few utility classes, I'll do it that way. But if I get to the point where I need to apply a style that can't be done with our utility classes, then I'll just write all the styles for that element in plain CSS or CSS modules really. So yeah. I don't really divide it like you do between these are styling attributes and these are layout attributes, but that is a good way to think about it.

 

I'm curious, have you experimented with Svelte at all and the way it approaches CSS? Cause...

 

I have not, so I don't know anything about that.

 

It's fun because it, I'm also a fan of your approach. When I, for the big React app I work on, we use the exact same approach. We have

 

nice.

 

CSS modules that are with SAS. We like SAS too, is it just some of the niceties,

 

Mm-hmm.

 

syntax niceties and like variables and stuff like that tend to be really nice. But I've got a small little utility app that I worked on last year in Svelte and they do styles that are scope styles, but you can write them in the same file. And then it comes though, as I understand it, and this, I'm also not the world's biggest spelt expert, but it's, it's sort of like bakes, bakes them into the components. So I don't think, and this is the part where we need our listeners to like fact check us

 

Hahaha

 

on it, but I, I don't think it comes with some of the baggage of like the CSS in, in JavaScript approach. Cause I, as I understand it, it kind of almost generates a module for you that scoped. But, uh, and it also works a lot like view, cause view lets you do something. similar as well, where you just write a style in their file. I think now as I'm talking, now I'm like starting to doubt myself.

 

Well, I mean,

 

Yeah.

 

this is React Roundup. We don't have to know about other

 

Yeah.

 

frameworks.

 

about

 

Ha

 

film.

 

ha ha.

 

Oh, yeah. Yeah. Yeah. Although we end up talking about it so

 

Hehehehe

 

often. Don't

 

Yeah,

 

know what

 

no,

 

that's

 

I think it's, I mean, I don't think there's a single React developer. I think it's important to know a bit about the broader ecosystem, right?

 

Oh,

 

Cause

 

definitely.

 

React's

 

Yeah, no,

 

not always

 

I'm

 

the

 

just

 

right

 

joking.

 

tool for it, but it does show when I try to speak from a position of authority on things that I've only toyed with

 

Hehehehe,

 

here or there.

 

yeah. Um, but I think the other thing you asked TJ was how are we migrating our app from this like heavily

 

Yeah.

 

CSS and JS approach to more of the CSS modules and utility classes. And it hasn't been a like, all right, drop everything. We're going to rewrite the whole app using CSS modules right now. It's like, um, we were already using CSS modules for some things. So it's more like if we add a new component or heavily rework a component, we're convert it to the new styling system. But we're not aggressively trying to remove every instance of that box component, which I think there's still probably like a thousand times that we use that box in the code base.

 

Yeah, it's.

 

I'm kind of surprised though. So I mean, wouldn't you just change box once and get the fix everywhere?

 

Um, that's the problem though, uh, that I spoke about earlier, which is like, so box takes in all sorts of prompts, like, uh,

 

Oh, okay.

 

flex and padding and margin. And so if you want to rewrite that component without using CSS and JS, you would basically have to use inline styles, which honestly would probably be more performant, but inline styles are still not ideal when you have those same inline styles applied to many elements. So. That's why we didn't go with that approach. That would have been a quicker way to extract the CSS and JS from the code base.

 

That makes sense.

 

It's interesting too, because this actually strikes me. We talked to a lot of people, a lot of people end up on this show because they've migrated from some technology to

 

Hahaha

 

another technology. It's like a common pattern, I guess, of, of guests or just reasons people reach

 

Mm-hmm.

 

out. And this actually strikes me as one of the somewhat simpler migrations because like you're these two technologies can easily coexist.

 

Exactly.

 

Oh yeah.

 

Um, whereas like in some other cases, like we've had some people migrate JavaScript to TypeScript or. Angular to react or those

 

Mmm,

 

sorts of things.

 

yikes.

 

And those are things where they're solvable problems, but you have to get kind of creative in how you approach this. Whereas this, it's just like, I could totally see it being like a backlog item. If you're

 

Mm-hmm.

 

there, touch it. Probably at some point, once you get to a reasonable number, there probably will be some, put some intern on the last one, the

 

Hahaha,

 

last pass

 

yeah.

 

of getting rid of all of them.

 

Yeah, it's a very easy migration. Yeah, I think JavaScript to TypeScript is hard, but it's not undoable because you can't have a mix. But when you said Angular to React, that sounds horrifying.

 

Yeah.

 

Yeah, I'm trying to remember what episode it was, but we had somebody that they were using both for rendering on the same time on the same

 

Wow.

 

page and they had it working. So

 

That

 

you

 

is

 

can get...

 

wild.

 

yeah.

 

So I don't know if you guys have played around with Next.js or Keen at all in the new app directory. Yeah.

 

I have,

 

I have not

 

yeah.

 

yet.

 

Yeah. Yeah. So their default thing is, uh, module based CSS, right? That that's out of the box. And I think it was out of the box too, for the pages directory. I think that's always just been there. They're shtick, but emotion and CSS and JS just clearly don't work. And anything built on top of it. Don't work either. Um,

 

Hmm.

 

In as you got to go, you got to switch it into the client mode, which is terrible. Even the, the, the, the CSS and JS extracted stuff, which I think is supposed to take away some of the performance issues that we're talking about, like. Vanilla extract. Um,

 

Yeah,

 

that doesn't work either.

 

even

 

So

 

that doesn't work, wow.

 

yeah. I mean, I, I really tried, honestly, there's like a, some, some sort of it. When you get to vanilla extract, that's actually when you start getting into like the whole world of the. the SWC issues with the compiler.

 

Mm-hmm. Oh, yeah.

 

Oh, it's a mess.

 

Yeah, I really want to use SWC for everything, but then like you run into any library that needs some kind of compiler transform and it's

 

Oh

 

back to Babel.

 

yeah. Yeah, exactly.

 

Hehehehe

 

All right, what is SWC? What am I missing here?

 

It's an alternative compiler. I mean, I think it's written in Rust. I

 

Yeah,

 

want to

 

it's

 

say

 

rest.

 

that one. It's tough to know Rust or go nowadays,

 

Hahaha

 

or, you know, which one's trying to eat the JavaScript ecosystem as a new whatever, but yeah, it basically it's a transpiler. I don't think it has type check. I don't think it does type checking, but it does type script, um,

 

Correct.

 

you know, language removal and transpiling. Um, Yeah. And then there's also, yes, build is another one. I don't, I think

 

Mm-hmm.

 

that's kind of falling to the wayside, but next, next picked that's a SWC and that's kind of given it a lot of impetus because

 

Okay.

 

it's

 

Yeah.

 

next. And anything next does ran.

 

Well,

 

Hehehe

 

and then the, so then the server rendering part is that's because in, because it's server rendering the page, it can't like bake in the JavaScript handling of the styles more or less would be the reason why the CSS and JS

 

Hmm.

 

stuff doesn't work, or is it just that the next team has like chosen not to build in the integrations necessary to make it happen?

 

They actually have a documentation page specifically around this. I'm sorry to dominate the podcast. They have a documentation page around this for CSS and JS. And apparently the issue is that it is incompatible with React 18's concurrency mode.

 

mmm

 

I mean, there's a whole thing around concurrency and it's no

 

Yeah.

 

longer a mode and it's kind of weird, but whatever. It's incompatible with that and therefore it's incompatible with React Server Components and And there you go. And so CSS modules for everybody.

 

I'm a bit surprised about the comment that it's not compatible with a React concurrent mode because Emotion should be compatible with that using use insertion effect, which is like a hook that they added specifically to make CSS and JS work in concurrent mode. But there's just a huge amount of complexity around server-side rendering with CSS and JS. So it's really not surprising to me that it doesn't work. I mean... Like back when I was trying to fix issues in the emotion project, we would just get issue after issue about SSR not working with different frameworks. So yeah, I have a feeling it would be a lot of work for the next JS team to get that working with the new app directory. And so probably just not worth the cost.

 

Yeah.

 

So then the other thing you brought up is some of these, the compile time CSS and JavaScript

 

Yeah.

 

frameworks. So maybe Sam, you could explain like what those are, like what the difference in approach is and

 

Yeah.

 

maybe how they work.

 

So, caveat or disclaimer, I haven't directly used any of these libraries, but compile time CSS and JS is like, basically you wanna write the same code that you were doing with emotion or style components, but instead of that being converted to plain CSS at runtime, we wanna do it at build time instead, so that the end user doesn't pay the performance cost. And so it sounds like a really good idea, better idea, but there's still some downsides to it, like going back to the box component where it takes in a prop called background color. If you're providing a different background color every time you use the box, there's no way to statically extract that style. Like it's just not known at compile time what the background color is. And so these compile time libraries, they're able to statically extract a lot of styles, In the case of like a style that is from a prop, they just have to, they basically would set background color equals variable background color in the CSS and then they would use an inline style to define a CSS variable that sets the background color. So they basically fall back to inline styles when they have to. So that's one of the problems. And then another one is you still have that issue of your inside. inserting new styles when a new component mounts, which invalidates that browser caching thing I talked about. So I think it's an improvement, but it still has some of the downsides of traditional runtime CSS and JS.

 

Yeah, I feel like it's closer because that to me, this approach feels like it should be the holy grail because

 

Yeah, right?

 

I kind of, I almost wonder if somebody will eventually nail this approach and that

 

Mm-hmm.

 

can get it to take off. Cause it seems me, me very naively looking at this problem. I feel like there should be some way where I can define my styles in my component and some magical tool will extract them,

 

Hehehe

 

place them into like some. global style sheet, but maintain this, like generate a dynamic name. So it's say it's like pseudo scoped and that those styles will be available for that component. And I don't, I don't know if you can solve the dynamic styling. That part

 

Yeah.

 

might be tricky, but it feels like even if you could just get static styles in a way where you could define them in the components, they get registered globally and I don't pay any of the runtime performance penalties that would be my sort of ideal. workflow

 

Yeah.

 

for working with this. And I don't know if we're quite there yet.

 

I think some of those libraries are close to that. I don't know if I'll ever be able to reach exactly that ideal that you're speaking of.

 

Yeah, because it has to almost like, you almost need like a next JS level tool that controls everything for you to

 

Mm-hmm.

 

kind of pull that off. Like sort of an isolated tool doesn't control enough, I feel like, to almost

 

Yeah.

 

be able to pull that off. It's tough.

 

And there's, I think there's a lot of self-discipline required to stick to static styles that can be extracted

 

Hehehe

 

and not just use dynamic styles all over the place.

 

Yeah.

 

Yeah, that's problematic. Because it's so

 

Mm-hmm.

 

easy. You know, if

 

Yeah.

 

you have those properties on it, it's just... You know. When it's this, make it roundy. When it's that,

 

Yeah.

 

make it not roundy. It's just nice, you know.

 

I don't know, like I feel like a tool could maybe enforce that. And I mean, inline styles exist for a reason. They're

 

Yeah,

 

not

 

they

 

like,

 

do.

 

they're not evil. I mean,

 

Hahaha

 

there, if there's legitimate use cases of them where you might want to, to switch display on and off or

 

Mm hmm.

 

like things like that. So I,

 

Yeah,

 

I don't know.

 

they're totally

 

I still maintain

 

valid.

 

it's possible.

 

They're use cases where, I mean, you definitely should be using inline styles. It's just like you never want inline styles to be the foundation of all of your styling for your whole app.

 

Yeah, I do agree with that. Sam, another question for you. I'm curious, what made you want to write this up? Because I'll be honest, I thought this was a really excellent article. You've got like,

 

Thank you.

 

I don't know if you ever desire this, but you've got a future in like marketing or dev role because you got like a nice click baby title, nicely

 

Ha

 

organized.

 

Oh,

 

ha ha ha!

 

nice. That's an art.

 

It's like marketing, I know is an evil word, but you've got a talent for it. So I guess what made you want to sort of share and talk about this?

 

Yeah, so, um... Really two main factors. I guess the smaller one is that, uh, My boss, Gordon at spot was like, Hey, this would be a good blog post. You should write this up and we'll post it on our blog. And, uh, we did actually get like a customer lead through someone who had

 

nice.

 

read the blog posts. So, but the bigger thing was like, I kind of felt like this was a big problem that no one was talking about. And. As someone who had like advocated a lot for CSS and JS in the past, I felt like someone needed to like, just not try to tear down this technology, but just inform people that if you use it this way, there is a significant runtime cost. And so I felt like I needed to tell people about that.

 

It's, I'm sort of fascinated that no one had sort of wrote this story earlier. Cause I feel like, and even just take 30 seconds in the comments and you see people that are, um, chiming in with their own stories of this sort of thing.

 

Mm-hmm.

 

So it's, it's kind of interesting to me that, um, this hasn't come up before. Uh, and that

 

Yeah,

 

more people aren't,

 

it was surprising.

 

cause I mean, cause I mean, CSS and JavaScript has a huge number of users, right? It's a, it's. This is a general technology. It's fairly widespread and I'm positive. There are tons of big organizations that are relying on this now. So I'm just surprised that it has not come up.

 

Yeah. And the thing is, even if you're not using it directly, you still might be using it because they're big component libraries like MUI is the

 

Yeah.

 

one that comes to mind that

 

Yeah.

 

it's all powered

 

How?

 

by style components or emotion. And I know there's other ones that are the same way.

 

Yeah, chakra, all of it.

 

Yeah.

 

I mean, that was one of the reasons why I figured out that CSS and JS and emotion were the problem. You know, you try to bring up next JS 13 and you're like, great, this is awesome. React server components are great. Now I want to just use my material UI just because I'm,

 

Hehehe

 

you know, it looks decent, whatever, and you bring that in and kaboom right away, and you just want to add

 

Yep.

 

a button to a page. And it was a little scary too, because it's complaining about create context. I'm like, oh my God, does context not at all work? And that turned out to be kind of lark because it's actually just around this concurrency mode, blah, blah, blah. But it was scary.

 

Yeah, that's definitely not a good like a first time using next 13 experience. I'm

 

Right?

 

sure they would like to avoid that.

 

I'm curious what you learned from the feedback you've gotten from this article because there are a whole lot of comments here and I know you've probably heard on social media and stuff about this. Like what's been

 

Oh,

 

the reception?

 

yeah.

 

I'm

 

Hehe.

 

So

 

sure there's been some. Yeah.

 

I felt like the reception to this article is very positive. I've done articles in the past and kind of learned, don't say anything controversial unless you really can back it up because people will roast you on that thing that you said. And so I managed to stay fairly non-controversial on this post, except for one thing, which is I quoted, I'm going to mispronounce his name, Sebastian Mark badge, one of the like React team guys about the problems of CSS and JS in concurrent mode. And I unintentionally took that quote out of context and kind of

 

Uh

 

misrepresented

 

oh.

 

it. But it was such a subtle and like such a advanced thing that the only person who called me out on it was Dan Abramov. So

 

Oh shoot!

 

Hehehehe

 

Yeah, he tweeted about my article and I felt so nervous after that. I was like, oh my God, I got to race home and fix the thing in the article that's wrong. And he had just pointed out that I had described the problem without mentioning the solution that the React team had implemented for that problem. And yeah, so it's a bit nerve wracking, but also cool to have been noticed by the React guy.

 

That is very fun. I think Dan is addicted to, it's amazing how many times I've seen him just nitpicking random React articles and it

 

Haha

 

just boggles my mind. He must have Google alerts for these things and sits

 

Yeah.

 

around and watches them like hawks. It's kind of fascinating.

 

I kind of get

 

Mm-hmm.

 

where he's going though. I mean, in a way you kind of got to defend react and, and these things, sort of things can spin out of control. You know, like

 

Yeah.

 

there's definitely a culture of, uh, you know, old wives tales when it comes to software engineering and web engineering in particular, like the whole, you know, you have to do SEO SSR to be good for SEO kind of old wives tale. And it's like,

 

That's

 

that

 

an

 

thing

 

old

 

will

 

wives

 

just.

 

tale.

 

Yeah. Yeah.

 

I always, I could never get a solid answer to that question,

 

No,

 

whether.

 

no, Google for like a whole, like almost a decade now has been parsing client side, it's, it's fine. Um, but you know, I think, you know, there's an SEO community out there. That's not technical. It's more about like tagging and stuff. And they, they're basically thing is they just tell the engineers, Hey, we just need SSR. That's because that's what you've been told. Whatever.

 

Hehehe

 

And the engineers like, I don't want to fight it. You know, SSR, um, you know, but yeah, so there's, there's, if you've let these things kind of get out. then people will start quoting it and quoting it and quoting it and quoting it and it just explodes. And so I can imagine why. I don't know what this particular thing was, but again, I can certainly see the end. I guess this is his job in a way.

 

Well, I think that's kind of like the quirk about him that's made him who he is, is just his superhuman dedication and effort he puts into it.

 

You have to. I haven't, I was thinking about react. Isn't it like basically, I mean, it's the number one web platform outside of like jQuery, like

 

Hehehe

 

in existence, like it's just, I mean, it's, it's a huge platform just like there's, there's millions and millions and millions of downloads.

 

Yeah,

 

Yeah.

 

yeah, way ahead of Angular review.

 

Oh yeah, yeah, it's crazy.

 

Yeah, it's

 

Well.

 

pretty remarkable that we, you know, programming languages like on the back end, we have so many competing technologies. It's like every company kind of uses a different language, but React is like kind of a unifying factor in that not everyone uses it. There are other popular frameworks, but it's really like dominating that market, so to speak.

 

Yeah, you don't see like Go and run, you know, like I, you know, this definitely like a whole culture out there of using Go as the new kind of Java to do like microservices and that stuff.

 

Mm-hmm.

 

And a lot of examples you see, it's like React on top of Go. It's not like they've decided that, oh, we're going to create our new, you know, Go based web framework. No, no, no. We're not even going to try to compete with React on the front end. We're just going to grant them. you know, the web and we'll just be the beat, the folks in the back.

 

Yeah, well, it's pretty challenging to compete with JavaScript in the browser. I mean, Microsoft is trying to do it with a C sharp and Blazor, which compiles your C sharp code to WebAssembly, but I

 

Yeah.

 

think there are some pretty big downsides to that approach.

 

WebAssembly is certainly something to keep an eye on going forward.

 

Yeah, definitely. It's exciting. I just haven't like yet seen like, oh, this is like the killer

 

But,

 

app for web assembly.

 

killer app, yeah.

 

Yeah.

 

Big time. Well, Sam, this has been awesome. Have we neglected to ask you any questions that you think we should have asked you during this?

 

No, A plus for asking good questions. I

 

Hahaha!

 

feel like you brought out my interesting opinions.

 

Thanks for watching.

 

All right. Well, we try, we try. And now we get into a section that we like to call picks and we get to talk about ideas, topic or, sorry, let me, let

 

Yeah.

 

me do a different second.

 

Okay.

 

I kind of got off on it. And now we get into a segment called picks where we get to talk about kitchen utensils or shows are watching or.

 

Woo!

 

Whatever. So TJ, when you start us off.

 

Yeah, I'm going to pick the movie Megan, which is

 

Oh yeah!

 

the like thriller horror movie about an AI doll that sort of goes on a rampage, more or less. It was pretty good. It wasn't amazing. I think what made the movie good was that it felt way too plausible, like the plot did.

 

Wow.

 

Especially with how much we talk AI on the show a lot or AI playing a bigger part of our lives that like movie, this movie hits a little closer to home than it would have even like two or three years ago. And I think that's the chilling part about it. But overall, it was pretty good. It's like an hour, hour and a half. It's very entertaining. So

 

much horror is in it? You know, my daughter is that's her name. And so we were like, Oh, we got to go see that, you know, and you know, she's older. So it's not a big deal. But my wife hates horror. Like, so is it horror horror? Like what, how, what's, what's

 

So

 

the level?

 

it's PG-13, so it's

 

Okay.

 

pretty light. There's jump scares, but to keep a PG-13, they kind of have to cut away

 

Ha ha.

 

at certain scenes. It's definitely not gory because they can't show much and keep the rating. So, I mean, I took one of my sons who's 12 to see it, and he did mostly okay. He had to cover his eyes a few times, but it's a pretty good intro to horror

 

There you go.

 

if you have a kid that's around the teenager age.

 

I saw the preview for that and so I'll say I'm quite surprised but pleasantly so that it turned out to be good. It looked kind of cheesy but I guess it didn't end up being that way.

 

It's a little cheesy, but it's still, it's just enjoyable. It's fun to see.

 

And it's got that whole, the TikTok dance that everybody kinda,

 

Yeah.

 

Hahaha

 

you know, kinda

 

Yeah.

 

do, you know, kinda thing. Cool, well, Sam, so you have a pick for us?

 

Yeah. Um, so I'm actually from North Carolina, but I'm not in North Carolina right now. I am in winter park, Colorado. Uh,

 

Ooh!

 

so I'm out here skiing for an entire month. And so my pick is definitely like skiing in Colorado.

 

You ain't gonna

 

I,

 

die, man. Ha ha ha.

 

yeah,

 

Nice.

 

for an entire month, I would, I would say people should not come to winter park, it's absolutely the worst resort. It's super crowded. It's just. everything about this place is bad. So you should go somewhere else where I'm not so that I can continue getting the short lift lines.

 

Thanks.

 

Are you being

 

I'm

 

like one

 

totally

 

of those folks

 

kidding.

 

who are being fictitious,

 

It's,

 

like this is a

 

yeah,

 

great place, you just

 

it's

 

don't want

 

a

 

to

 

great

 

tell them.

 

place. You know, there's just kind of a, I feel like it's a great place, but if too many people come to a great place, it becomes a little bit less great because it's just crowded and you're waiting in line for a long time. And so that's all I was getting at.

 

Let's say hypothetically you're somebody who's very bad at skiing but still

 

Hmm.

 

enjoy doing it. Would I still be okay? Am I going to be intimidated off the lifts because I'm going to die going down

 

Oh,

 

these

 

no,

 

hills?

 

no, no, no, it's, it's not that kind of place. I mean, they have some pretty gentle beginner terrain here, but they also have some terrifying expert terrain

 

Cool,

 

that

 

what

 

I watch my

 

is

 

friend

 

Sam

 

do.

 

Ski? Double black diamond?

 

No, no, no, no. That's what I watched my friend do from the bottom yesterday.

 

This is...

 

So they actually have a blue-black rating here, which is pretty nice, like

 

Nice.

 

an advanced intermediate slope. So I do those, and I do the single black diamonds. I don't know if I will attempt a double black. I like having my legs and knees intact.

 

Yeah,

 

Right?

 

So

 

that's where I'm at.

 

yeah.

 

This is what keeps me from skiing is, and at every age, I'm just

 

Hehehe

 

like, this is cool, but I don't wanna die over this. Like,

 

Yeah, I know.

 

you know.

 

Like, I don't think I ever want to ski something where it's like, you might die if you fall. Like, that's just not worth it.

 

It's one thing I learned with my kids that I feel like it helps a lot if you can learn it at a young age because

 

Mm-hmm.

 

Yes.

 

if you watch, my kids learned when they were like seven or eight and if you fall when you're seven or eight, it's no big deal. You get

 

Yeah.

 

right back up. Whereas I learned in my mid-30s and when I fell, I could get back up, but it take a second and I didn't fall lightly. So if

 

Yeah,

 

you...

 

I know I'm kind of envious of people who have been doing it since they're like three, because I started at around 24. I'm 28 now, so like,

 

Yep.

 

you know, it still can bounce back up, but maybe don't learn as fast as a child would.

 

Yes.

 

think you gotta be better, you know, live or be born in a mountain town.

 

Yeah,

 

You know,

 

which,

 

where you where

 

you

 

you

 

know...

 

get that for like, six months out of the year, you know, and

 

Mm-hmm.

 

like, every like the local pizza place has like, you know, skis on the wall and blah, blah, blah, blah,

 

Yeah.

 

you

 

Yeah.

 

know, that kind of place and you know, and then if you live there, it's like, it's no big deal. All your buddies are up

 

Exactly.

 

on the hill and

 

Yeah.

 

all that, right. And so yeah, you learn when you're like to

 

Yeah, I'm

 

Yeah.

 

guessing

 

Mm-hmm.

 

there's not many slopes in North Carolina.

 

There actually are, I believe,

 

Really?

 

five resorts in North Carolina. Yeah,

 

Is

 

it's

 

it like

 

like

 

on the Appalachian

 

pretty.

 

side of the

 

Yeah,

 

state

 

exactly.

 

or? Okay.

 

The western side. Yeah, it's pretty much the farthest south you can ski on the East Coast. And so the conditions are not great. But if if you're just trying to learn, it's a good place to go.

 

Very cool. Well, thank you for that. My pick this week is going to be a show called Midnight Gospel on Netflix. It is the weirdest thing I've seen in a long time. It helps if you are in a significantly altered state when you watch it.

 

Yeah.

 

Hehehe

 

It is a weird combination of animation plus extreme violence plus long 25 minute rants on, you know, all kinds of metaphysics and this sort of stuff. It's like people talking about religion and philosophy, while at the same time killing zombies, and or something like that. And the first episode is great. I think it's got Dr. Drew in it. And he talks about, you know, various things. And it's at the main at the same time, he's like, killing zombies. And it's hilarious. And they kind of wind it in like So as opposed to a podcast, it's just the weirdest. Like I kinda, Netflix has this, you know, the quality is extremely variable kind of thing, right? But this one, I don't know who their target audience is. I don't even know how they got a green light for this thing. But the fact that it exists is hilarious. You know, it's like heavy metal. Like how did they ever, the movie, heavy metal. Like how did they ever get any money for that? But that it exists is awesome, you know? Whatever. It's great.

 

Yeah, it's that looking just over the show and it is it is very unique looking. I could definitely say that.

 

That's a word for it.

 

It is

 

Yeah.

 

That's

 

usually

 

definitely...

 

not a compliment when someone says it.

 

yeah.

 

Unique.

 

But it can be, right?

 

It

 

Like

 

can be.

 

in a world where we have a million shows,

 

Right!

 

that's

 

If

 

so.

 

someone told me I was very unique, I would not take it. It's a good

 

Okay.

 

thing.

 

Okay.

 

Might depend on how they said it.

 

Yeah,

 

Yeah,

 

exactly.

 

I think

 

Yeah.

 

it depends on the context.

 

Yeah, it's like that Southern thing where they say, oh, you're so special. It's like,

 

Hmm.

 

that's

 

Yeah.

 

not,

 

Mm.

 

you don't want to be special

 

God bless you.

 

in this

 

Hehehe

 

stuff. Yeah. Bless your heart.

 

Yeah, yeah.

 

Yeah. All right. Well, this has been really fun, Sam. Thank you

 

That's

 

for

 

funny.

 

a deep education on CSS and JS and the issues thereof.

 

Mm-hmm.

 

And

 

Thanks

 

we will

 

so

 

see

 

much for

 

you.

 

having me on.

 

Yeah, we'll see everybody on the next react roundup.

 

Bye everybody.

 

Bye.