The CSS expertise kerfuffle

Good day! You’re listening to JS Party, a weekly celebration of everything JavaScript. I’m Suz Hinton, I’m your host for this episode, and as always, I’m joined by some fantastic panelists. First of all, we have Kball. Welcome back!

Hello, hello!

We also have Nick. We’re very pleased to have you on the show, Nick.

Hi!

And I’m very excited to introduce our special guest for this particular episode. We’ve been trying to get her on for a while now, so we’re really excited to introduce her… We have Aimee Knight.

Hey-hey from Nashville!

Awesome! So you’re currently based in Nashville, Aimee… Why don’t you tell the listeners back home a little bit more about yourself as well, and sort of your experience in CSS, and that kind of thing.

Sure. I’ll try to keep it a little bit short, but sometimes my story gets a little bit long because there are some interesting twists and turns there. I went to a bootcamp here in Nashville about four and a half years ago, and I’ve graduated from that, I was doing JavaScript on the front-end and then back-end for a while. I will preface that most people may know me as the girl that used to figure skater, too. Before I did the bootcamp, I was a competitive figure skater for most of my life. But I did full-stack JavaScript for a while, and then I started working for a company that was acquired by Warner Brothers, and when I was in that role, I went from full-stack JavaScript to being solely focused on the front-end… And not just front-end, but when you work for a company like that, their styles are really just as important as the functionality… And when I was there, I realized how poor my CSS skills were. That’s when I really decided to treat learning CSS like I did learning JavaScript, and that’s how I’ve kind of just decided to really deep-dive into CSS and how the browser is actually rendering your style sheets.

I think that’s an excellent segue into the type of topic that we’re focusing on for CSS in this particular episode. That’s really cool. I wanted to talk firstly about the fact that we do tend to revisit CSS as questioning the cascade, talking about modern approaches to it and things like that in different cycles, I guess, and this does come around a lot…

[04:11] And I wanted to bring up an article that Kball actually wrote really recently, and I thought it was really interesting. It caused a bit of a discussion around a Twitter CSS kerfuffle… So I will actually pass to Kball and ask him to introduce what he wrote the article for, what the reasoning was, and also just a little bit of background as well.

Sure. A little over a week ago there was one of these big kerfuffles that seems to go around over and over again with discussing the value of CSS. There’s kind of a camp within the JavaScript community that tends to make pretty dismissive statements about CSS and the value of CSS, and saying “Oh, this is an old and outdated technology” and “Cascade is broken” and “We should be doing all of our CSS in JavaScript.” And there’s another camp within the web development community that tends to say “No, that’s wrong. CSS is really powerful. If you don’t think it’s working, you don’t understand it.”

There’s extreme versions of both of those arguments, and that seems to go around regularly, at least for the last few years. I see flare-ups, and there’s lots of dismissive arguments on both sides there. I had actually gotten in this debate before, almost exactly a year ago - there had been a whole bunch of kerfuffle about this, and I’d written a relatively provocative post arguing that CSS and JS was not a very good solution. The blog post was very provocative, and there’s a much more nuanced answer than that presented… But it was funny to me that this year, almost exactly a year later, this whole big argument was blowing up again. But I had noticed something in a lot of the discussions that I wanted to highlight, which was 1) a lot of the discussion and language started to move rather than just talking about technology choices, kind of dismissing whole swathes of the ecosystem.

I think one thing that we need to be very cognizant of is the moment that a discussion moves from “This is not my technology choice” or “This doesn’t work well for my use cases” to saying “Anybody who’s working in this is wasting their time”, we’ve stopped talking about technology, and we’re starting to talk about culture, and about who belongs, and things like that.

This was something that I had seen particularly a lot of women bring up. The CSS world is interesting because it’s one of the few areas in technology where many of the dominant people are women; some of the top teachers in this space, the top people involved in the spec - I’m thinking people like Rachel Andrew, I’m thinking people like Jen Simmons… It’s one of the rare areas in our industry that is much more dominated by women. So I’d seen some of these cultural conversations coming up about a lot of the dismissal of CSS actually being able to be viewed in a gender context. I started digging into that more and found that this is actually not that uncommon in the tech industry, for areas that are women-dominated, if men start to try to get into them, they start to try to push and change the cultural conversation and exclude things… And I thought “Well, I could write something about that, and I’m a privileged white man. Maybe different people would be able to hear that differently than they do or don’t hear it coming from women”, which I’m not sure that that was the case. I think we should talk about it a little bit; the reactions were very bi-polar… But that’s kind of the background.

[08:07] The blog post is titled “CSS dismissal is about exclusion, not technology”, and kind of talking through the history of this and highlighting that we have a lot of challenges to address in this area, and that a lot of the discussion is starting to look like essentially trying to push people who traditionally do CSS out of saying “Oh, those aren’t real front-end developers. If you’re focused on CSS, you’re not really doing engineering”, and that that has a privilege and a gender component.

I think that this is a really excellent point, and it’s something that just in the Women in Tech backchannels I see this topic come up a lot… So I definitely think that this is a valid point of view.

It’s interesting, because I think that Aimee and I have had very separate transitions; I’ve gone from primarily doing HTML and CSS and knowing those two technologies incredibly deeply, as well as how accessibility fits into that, and then I transitioned halfway through my front-end career into writing primarily JavaScript for a long time… Whereas Aimee, you started with full-stack JavaScript and then you moved into CSS. What has been your experience, given that you had that realization that you didn’t know it deeply enough? What sort of things do you think make you not really understand it as deeply as you might have thought you needed to at the beginning of your career, while writing JavaScript and front-end?

Yeah, totally. Thinking back to everything you’ve just said, there is a lot of truth to what we’ve been talking about, and I will (in a roundabout way, probably) answer the question, but in my bootcamp I was the only woman; I did a six-month bootcamp where you had to finish the first three months, and then based on how you were doing, you finished the last three months.

After the first three months, I was the only woman left in my bootcamp, and I can remember a number of times the guys in my cohort – and they are all great; and also too, when we talk about gender and stuff like that… I live in the South, and the typical gender rules are very much a part – Nashville is a little bit better, but being in the South, the culture here is very “traditional.” So all that to say that even in my bootcamp, the men would say “Well, you’ve gotta focus on the CSS, because you’re the girl”, and stuff like that. Or jokingly too, because I think they knew it bothered me… And you know, just in like a big brother kind of way, not in a condescending or negative way, but just in a joking way, saying “Can you come over here and help me with my CSS?”

But I think that had an impact on me, even if it was in a joking way, where the more that they kind of teased and picked on me, the more I wanted to kind of break that mold and focus more on the back-end and more just in JavaScript. I’ll also say too not only that, but just… You know, my personality is just that where I always kind of search for something that I think - and here’s the key here, that I THINK is going to be the most challenging. So being that CSS was kind of picked on as being not a real (you know, real programmers don’t focus on CSS), I wanted to focus on what I thought was gonna be the hardest.

[12:08] So all that to say that’s why I decided to really try to go the JavaScript route and really not focus on front-end. I really wanted to do full stack, so I could do a lot more on the back-end… But just in the JavaScript space, you know, there’s so much more opportunity right now on the front-end.

After about two years of doing full-stack, that’s when I went to front-end and realized that I had kind of like fallen victim to this mindset that CSS was dumb, and not for real programmers… And I think I had to have a check with myself, because if I wanted to call myself a front-end developer and I’m handed a very complex layout, I should be able to implement the styles for that layout, just like the functionality in the JavaScript.

I definitely went through a very similar journey, I think just in the backwards way… [laughter] I was like, “What is this JavaScript thing that people think is more important than writing really good semantic HTML?” So that’s super interesting, but I definitely have heard that same attitude where CSS becomes this feminized thing, which is in a roundabout way a way to trivialize it. That’s really what it comes down to… And when JavaScript became more performant in browsers, and when V8 was released, and things like that, I definitely felt threatened and felt like I wouldn’t be taken seriously as a front-end developer if I didn’t pick JavaScript up… And I’m not gonna lie, the main reason why I focused on JavaScript for the next few years after that was because I wanted to be taken seriously.

I think it’s really interesting that CSS is seen as easy, which again is just a way to trivialize it, and people tend to feminize things if they think it’s easy or not important as well… And honestly, I’m actually really interesting to hear Kball and Nick’s feelings on this, about whether they think that CSS is difficult… Because I think that it is difficult to scale and it is difficult to write with large teams, and also just being able to, at the time, navigate the different cross-browser incompatibilities was particularly challenging as well.

Yeah, I agree with that. I think that it is difficult to learn. I feel like my CSS skills have atrophied a little bit in the recent months, just because I haven’t been paying as much attention to it, just because of the work that I’m doing, working on other things… But it is a super-important skill to have, and it’s something that I always struggle with, and one of the harder parts of a project that I come in on is how to effectively organize it in a way that is reusable, and avoids the cascade when I don’t want it, and issues like that. So it’s definitely something that I need to work on and get better at.

I think one thing that’s interesting to notice is that the same people who dismiss CSS as easy are often in the next breath saying “Oh, it’s impossible to do this right. The cascade is so hard… It must be broken”, and all these other sort of comments about how difficult it is.

I was gonna say, and I think this is potentially what spawned the blog post that you wrote - I’ve been giving this CSS talk, which is a CSS talk, but really at the end of the day I think it’s more a talk about understanding browser internals and how the browser goes through this whole rendering process… And Max Stoiber tweeting out this little CSS quiz, I’ve had very similar results.

[16:10] In this talk I give, I have what I would consider a pretty simple specificity quiz, and I would say of the people in the audience - I’ve given this to rooms of 300, to smaller rooms, but on average, I would say there’s really only one or two developers in the room who usually know the answer to the little specificity quiz that I have.

So it’s interesting to me – I like to say that there are tradeoffs for everything, and that’s just the honest truth… But I think if you’re going to pick one side or the other, you should at least understand the trade-offs you’re making and understand how CSS is working, so that you can make an educated decision.

It all goes back to what our mom and dad used to say to us when they say “Well, you have to try one bite before you decide you like it or not.” [laughter]

That’s a really good analogy, I like that.

I was a picky eater when I was little, and my parents were like “You’ve gotta try one bite before you make a decision.” So yeah, I think you need to make sure you fully understand things before you put your stake in the ground and say “This is the camp that I’m in.”

Yeah, I definitely agree.

This might be a low self-esteem thing, but if I’m having trouble understanding something, I tend to blame myself first, instead of lashing out at the technology…

Yeah, me too! [laughter]

…and then I will read everything in-depth before I slowly start to realize and it coagulates in my mind, and I’m like “Oh, this might actually be a bug in the tool that I’m using, and it’s not me being dumb.”

So true. I can relate to that so much.

I think one thing to highlight is while I may be provocative on one side of this, I think there’s real nuance in the decisions for the tools that you make, and I think your problem domain lends heavily; there are problem domains where CSS and JavaScript is absolutely the right technology choice, and there are problem domains where it’s absolutely not. Engineering is about tradeoffs.

I do think there’s also something to be – I think we’re gonna talk about a lot of that a little later, but we really should highlight this question of “How do we make these decisions and what are the human sides of that?” We as engineers often like to ignore the fact that there are – well, how should I say this…? We’ll often make debates claiming they’re completely technical, and ignoring the fact that every engineering decision has human consequences… And that shows up for us in terms of things like machine learning, we’ve talked about the ethics of machine learning and debates on that, but I think that also shows up when we talk about the value of different technologies, and what we should or should not be using - we can’t say that without thinking about the context of what does that mean for the people working in those technologies?

Taking CSS aside, WordPress is a really interesting example. As a developer, I love to hate on WordPress. For people who are trying to get content sites up and are perhaps not super technical, I recommend it every day. So having that distinction between “Well, this isn’t my technology of choice, but I can see that there’s still value there for different types of people”, and if I were to say “No, you absolutely should not do WordPress”, I’m actually doing an incredible disservice to a huge number of people.

[19:50] Yeah, I think it’s extremely hard, in my opinion, to be able to say that any decision you make as a human has absolutely no emotion in it and is 100% logical. I think that’s a huge fallacy that people try to perpetuate in this culture, so I’m really glad that you made that point, Kevin.

So true.

One other thing that we were talking about a little bit before we went on, but we wanted to sort of go out here is the value of being a little provocative in pushing things out. This post created a very bipolar set of reactions. There was a huge number of primarily men who jumped in early and were saying “What is this? This is terrible! I don’t even understand what you’re saying. You must have a big, huge agenda. You’re a social justice warrior” and all these other things.

Then there was another wave of much more mixed genders who was saying “Oh my gosh, this is exactly right!” There’s a question to be said, if you have that type of polarized reaction or you’re actually making an impact, but I think I draw a lot of inspiration from a woman named Kim Crayton, who is doing something she calls “Cause a scene.” She has a podcast and she does a bunch of stuff online… She’s highlighting particularly the impact of white supremacy throughout things, but one of her big points is people don’t ever change when they’re comfortable. So if we have a situation that has negative human consequences - and I think that we do very much have that situation when it comes to race, when it comes to color in the tech industry, we have huge problems here - the only way we can ever actually have an impact on that is to make the people who are currently in privilege uncomfortable… And I include myself in that. I follow a bunch of people whose commentary - including Kim, actually - will often make me uncomfortable, but it makes me think about “Am I seeing the world right? Is there something real to this? How am I complicit in maintaining things that I nominally disagree with?”

That’s so true, and I think it takes a good bit of introspection to be proactive in putting yourself out there like that, but it’s so valuable… To yourself and to the people around you, to the community.

So we’ve danced around the topic a little bit when we were discussing some parts of your article, Kball, but we wanted to focus this segment on specifically what exactly is CSS in JS, given that it is a new(ish) approach to being able to develop front-end applications that need specific styling… And for me, a very loose definition of what I understand CSS in JS to be is that some approaches might move away from having a single or multiple cascading style sheet files, and moving CSS to be defined more on a very heavily-scoped level by creating CSS styles with JavaScript code itself, and a lot of the time, as I said, heavily scoped - it’s scoped down on a component level, especially when using frameworks such as React, or Vue, or Ember, or Angular, or something like that. Is that sort of on the same page as everyone else, or do you see it to be a little bit more broader than that?

[24:32] That makes sense to me. I would say one point of clarification for people who haven’t really looked into this much is sometimes people assume CSS in JS to mean it’s actually applying a style attribute, but that’s just inline style. CSS in JS would actually be applying a style sheet.

Got it.

There are a wide range of approaches to CSS in JS. It is actually a relatively complex topic, and there are also ranges in terms of people’s approaches to it. I think you get everything from what looks very much like inline styles, like we’re gonna define all of these things essentially as inline styling in your (commonly) JSX, because React is so dominant on a lot of these things, and I think that also was one of the big entre points for CSS in JS. So you get what looks like inline styles, even though it may end up compiling out to something else… To other approaches – I really like the CSS Blocks library that came out of LinkedIn, where they are essentially using separated CSS files, and they’re applying a ton of static analysis to it, and then putting in scoping.

So I think your definition, Suz, of basically being able to scope styles programmatically to components is kind of the core, common shared thing… But there’s a very wide range of ways that people approach that, some of which I think lead to very bad practices, and some of which I think are extremely positive.

I think I may have misspoke, too. I said style sheet, and I meant like a style tag.

I think one of the main reasons that CSS in JS has come about is because we are thinking more in components. Like Kball said, with React specifically everything is a component in there, and we’re working with that; we change the paradigm by mixing our “HTML into our JS, via JSX.” But then we still have this separate thing, CSS, that we have to get loaded somewhere else, and now as we’ve moved on to – npm is kind of our main source of components and frameworks and everything related to the front-end, and CSS kind of is a different thing that might be a little bit harder to pull in, because you’d have to think about managing your components, but then also pulling in a style sheet when you’re taking components from a library or something, and managing that… Whereas if you can put that into JavaScript, then you can think about it just as one component that contains this markup and this CSS, that’s all defined in this one file that JavaScript will define for me, and then manage loading when you need it, and it won’t be there when you don’t. So if a component is not used, the CSS that’s associated with that is not brought in and left as unused rows on the page.

I can critique a lot of things about CSS in JS, but let’s actually highlight some of the places where it really shines. One of the things where we see a lot of folks who are really going whole hog into CSS in JS and where it is extremely valuable is in development environments where you have very large numbers of components, particularly developed by large numbers of teams, or across different teams, where having to worry about anything that is in any way global is a huge headache… So you want to be able to scope things down.

[28:34] Now, one of the interesting things to me about the CSS debate, one of the big critiques that people make of it is “Oh, globals are always bad”, and I think we found in programming that tends to be true; globals are very hard to reason about, and I think that’s one of the big challenges in CSS.

The thing I want to highlight there is thinking about domains… People’s reaction to a product visually is global, it is not isolated. People perceive a product as a whole. If you ever go and walk through a demo with somebody who is non-technical and is using your application, you’ll be shocked at the ways in which they don’t think about it the way you as an engineer thinks about it; they’re not looking at “Oh, that’s a component, and that’s a thing down in there.” They’re just having a global perception.

One thing that we often run into, and that I’ve talked to a number of folks about and nobody has a great solution for is when you don’t have a global perspective on it, you end up with a funhouse mirror where things are almost alike, but not quite alike, and you end up with what is sort of like what Amazon has ended up with, where people get really confused because everything looks slightly different, especially if you look in AWS. The AWS UI is the most confusing thing you’ll ever see, because everything is isolated by components; there’s no global perspective, there’s no coherence across it.

I would actually highlight that while there are some things that are extremely valuable to isolate completely, and there are situations in which the possible downsides of a global perspective are higher than the downsides of isolation, going towards a complete isolation is not necessarily the right answer for something that is on a kind of design and visual level.

I almost feel like the tradeoffs kind of depend on the team. I know for me, when I was really trying to learn CSS, apart from the basics I had learned, what was challenging to me is kind of like you’re saying… When I was writing JavaScript, I’m used to really thinking about things in isolation, and CSS is just not designed to work that way. There are side-effects, and those side-effects, from my understanding of reading old blog posts and people’s thoughts who have been in this for a while is that CSS was designed that way on purpose. All that to say, if the people on a team are used to these side effects and actually use these side effects to their advantage, because they understand them, having things scoped by default could actually be confusing. But if you have a team of people who feel more comfortable in JavaScript and are not really up to date with the nuances of CSS and how these different side effects all kind of communicate with each other, then having things scoped is gonna be helpful.

[32:02] Well, there are some things for which scoping is necessary, or extremely valuable, right?

Yes.

Even CSS best practices where we’re using pure CSS - a lot of things you’re moving to try to make them isolated and scoped. However, that is not necessarily the same statement that everything should always be scoped.

Yeah, and it’s funny that you brought up Amazon earlier, with their UI, because I did work for an Amazon subsidiary a number of years ago, and we had a lot of insights into why a lot of their UI was fragmented, and not necessarily in AWS, but across the actual Amazon retail website as well… And we watched their latest UI update strategy where they were trying to solve that… Because it’s like what Aimee says about teams - their teams were so siloed, even on what looked like very similar parts of the retail site, and they had a lot of trouble where they were creating their own very heavily scoped things for their own teams, but not able to communicate or share code effectively enough across those siloed teams… And that became a huge problem for being able to deploy multiple parts of the site at once and not have this really weird fragmented and disconnected experience for the users to then have to deal with afterwards.

So it really does depend on teams, based on what I observed there, and then what I’ve observed while working on other teams that actually managed to make something like that work.

This comes back to that question of nuance. Every engineering choice is about tradeoffs, and those tradeoffs are not purely technical, they also include team-level tradeoffs and human-level tradeoffs. And I think it is 100% legitimate to evaluate and decide and say “You know what, for our team setup, CSS in JS is the right approach, and we should be doing that.” And I say that as someone who’s generally a critic of CSS in JS, and I don’t like it for many situations… But I think it is 100% the right solution in some scenarios.

That said, one should also be aware of the tradeoffs with that. Many CSS in JS solutions have performance tradeoffs, because your JavaScript is the most expensive thing in your system… So if you’re moving all of your CSS into your JavaScript and not making it parsable, you may win a little bit of fragmentation benefits, and lose on performance, particularly on cachability and things like that.

There’s lots of other challenges that you run into… I think there’s maintainability challenges. I know we all love the rethinking of how separation of concerns works that React or JSX prompted, but looking at some of these things that have JSX with inline CSS in JS, with whatever - I have serious trouble reading those things. It’s just so much different things you have to observe all at once. I far prefer something closer to Vue’s approach, where you still have potentially this scoping by components; they have a built-in way to scope styles, and they do module-level styles… There’s really interesting stuff that Vue is doing there, but they still separate conceptually “Okay, here’s the template, here’s the JavaScript, here’s the style”, and I think there’s tremendous value in being able to isolate how many things you have to hold in your head at the same time.

So while there are absolutely situations where completely scoped CSS in JS is the right solution, one should be very aware of the tradeoffs you’re making to do that.

[36:04] I think you can live in both worlds, as well. Angular, for example, has the ability to do inline styles or reach out to a separate style sheet, but then it’s going to scope all of that to the component you’re working on… But then you can have any number of top-level style sheets that are just applied to the page; you could have anything that needs to be utilized by all of the components that you might be making - it can be up in the global scope, but then anything that’s structural to that component can be scoped specifically to that, so you’re not bleeding that out anywhere that shouldn’t be.

I don’t think this is probably the case for a lot of people, but maybe potentially more beginner developers… The thing I see a lot happened is people reaching for JavaScript to still do things like animations, and that, like you were saying, is going to have a performance hit, because the browser is going to use the GPU for these animations, whereas if you’re using JavaScript to do them, it’s using the CPU and it’s going to be a lot slower.

That’s a good highlight of – we don’t hesitate to use third-party code to get our job done better; well, consider that CSS is essentially a direct line into the browser’s rendering engine. We are able to lean on what is, in my opinion, probably the most powerful rendering engine out there, and get directly into that. And if you try to reinvent all of that with JavaScript because you didn’t bother to learn CSS, you’re gonna have problems.

I think it was Sarah Drasner who famously tweeted at some point that she had seen a team where somebody had implemented something in two or three thousand lines of JavaScript because they didn’t understand how position:absolute worked… And that’s extremely plausible. You get tremendous power from CSS, especially modern CSS. It’s funny to me that CSS in JS is such a thing right now because the CSS spec and what’s supported is improving at a faster rate than it has ever in history, and the power that we have available to us tapping directly into the browsers with CSS is phenomenal. So it’s like the Not Invented Here thing; it’s not a good idea to choose to reimplement every library that I might wanna use, because I’m gonna do it badly and it’s gonna perform worse. Really, we should use the tools that are available to us.

I totally agree, and that calls out another disadvantage of doing all of the CSS within JavaScript, and that is that a lot of the time some of the approaches are requiring additional library in JavaScript in order to do so. I had a look at a bunch of different options out there, of which we will share a link as well in the show notes… But some of them – “Oh, it’s only 5 kb gzipped”, but that’s another 5 kb you’re adding to your payload that your use is downloading, and you mostly have that payload because that was a developer experience improvement, and not necessarily a user improvement.

Sure, that might allow you to have less CSS bugs, because you find that particular library a good experience to use, but you are still pushing that tradeoff off onto the user. And it’s interesting, if CSS is getting these extra features, even things such as custom properties and variables and things like that, there’s no reason why we shouldn’t be going back to revisit it, because we do have a direct advantage in using those features, and those features are being developed for us… And being able to provide that feedback is something that I really admire that Rachel Andrews pushes. If no one is using these new features, then you’re not gonna be able to have them be developed into even better quality features for us to use… So this cycle perpetuates where we’re trying to reinvent things.

So in the previous segment we danced around a couple of different approaches to CSS in JS, but for this segment I wanna dive a little bit deeper into just a couple of examples, just so that people can get a feel of what the differences are between several different approaches. Nick do you have a particular strategy that you’ve either used and liked, or have just been able to play with for a little bit?

Yeah, I’ve played with styled-components a little bit. It’s using template literals in JavaScript to allow you to implement CSS, and it allows you to do that by using the template tag – for a div you can say style.div or style.a and create an anchor tag or a div tag. Then you use the backticks and you put all of your CSS in there, without the curly braces… So just all of the CSS rules, like padding, margin - all of that just directly in line, and then that gives you back a component that you can use that has all of those styles that will be applied to it… Not in line, but they’ll be applied via a style sheet that is generated and scoped directly to that element. So it allows you to take advantage of doing JavaScript within that, because you can do interpellation within those template tags, and add in specific rules from your JavaScript in there, which makes it pretty easy.

Another one that I’ve played with is what we do on Dojo, which is not really CSS in JS, but it’s more using PostCSS and specifically CSS Modules to scope the CSS that you would write in a CSS file to the module that you’re working on. Then additional to that, we generate typings files; because we use Typescript primarily, we generate typings files for the CSS so that you can get feedback on the rules that you have available, and to ensure that you don’t accidentally misspell those classes.

That’s a super-interesting approach. I’m actually really excited to read more about that on the Dojo website. Thanks for sharing that.

Yeah.

One of the things I really like about CSS Modules, and then also this newer thing from LinkedIn called CSS Blocks is that they are both – I’ve looked more into blocks than modules, so maybe you can speak to the modules bit… But they’re both learning into the principle of least power, and the fact that CSS is much easier to statically analyze than JavaScript is. CSS Blocks, which I can speak more to, they do a static compilation, and they do a ton of analysis and optimization and various other things as a part of that compilation step. And unlike many of the CSS in JS libraries that you alluded to, with the 5kb minified or whatever, the runtime is minimal. In CSS Blocks it’s like 500 bytes; I don’t know what it is for CSS Modules, but it’s tiny, because they’re doing almost everything at compile time, taking advantage of the fact that the less generally powerful a language is, the more statically analyzable it is.

This goes back to this idea of like “Do it in HTML. If you can’t do it in HTML, add CSS. If you can’t do it in CSS, add JavaScript.” That principle - we’ve kind of gotten away from it, but there are serious values to that, because the more simple the language, in some ways, or at least the more statically analyzable the language, the more that machines can do with it.

I guess I can chime in with what I’ve been using the most; our team is also using CSS Modules, and I think the decision for that – so I actually have not been writing any CSS at the job that I’m at now, because I’m no longer at Warner Brothers, because I actually did wanna get back into JavaScript land… So we have a designer who does all of our styles. But I think that they probably chose CSS Modules because it seems like a little bit of a happy medium if you’re not ready to go all-in with JavaScript. It kind of gives you some of the benefits where you can kind of have – I guess you would think of it as like automating Vim; you can encapsulate things without going all-in with JavaScript.

[47:36] Yeah. Suz, I think you were mentioning you could talk to this, but I can also talk to it - I’ve been using Vue quite a bit recently, and they have an approach where within a single-file component you can use CSS Modules, so you could do a module type of a style thing, that’s within a single-file component it gets compiled to a CSS module… But you could also do just scoped components, which isn’t quite as rigorous. It uses kind of a data attribute on the component to scope your styles to that component, and the distinction that gets made is with a scoped component it actually applies to that component in every child thereof, whereas with the CSS modules it keeps it straight within your code, and I think that actually gives you also a really nice way to get this kind of combination effect.

I particularly like the scoped approach, because I think if you want to lean into the cascade, but you also want to have some level of isolation to just this component or have this only be loaded when that set of sub-components is loaded, it gives you a really nice way to do that.

I totally agree. That is something that I did with a project that I did recently. I’ve been out of the front-end world for a little bit of time. I was a front-end developer for 13 years just for that context, and then I moved into IoT and cloud stuff for my latest job… And I had to write an application that was IoT-based, and it’s actually an open source project that I work on on my stream on the weekends… And I thought to myself, man, I’ve been out of front-ends for a year and a half now and I feel like so much has changed, and I didn’t really get a chance to look at CSS in JS or anything… So I guess I felt really intimidated, so I thought “Well, I’ll write this app in Vue, so that I can learn a new framework.” Then when I got to the CSS side, I noticed that they have those sort of template setups that you were mentioning earlier, and I liked that, but part of me was still wanting to reach for what I was really comfortable with, which is leaning on the cascade and having actual physical .css style sheet files, and things like that.

So the balance that I came up with just so that I didn’t get myself in a huge mess was to define everything in the style sheets that were inherently going to be quite static and fixed, and then anything to do with components that we’re going to change or could take advantage of JavaScript to do sophisticated calculations and things, that’s when I would specify certain things to override the cascade from there, and that’s just directly using a JavaScript object, and then assigning it as an actual style attribute.

There could be reasons why that would have gotchas in it, but I found that to be really successful even just trying to ramp up to something that I wasn’t really sure was going to be that beneficial to me… And I would say that so far that’s been a success, but I’d also have to ask some of my other contributors what they think about that.

I posted a link to the room (it will be in the show notes) that gives you a good demonstration of CSS in JS with 14 different implementations of a login page using all sorts of different libraries… It’s a good way to compare different strategies and approaches.

That looks really cool. I’m absolutely gonna check that out. That’s using the Stripe page, you said?

[51:11] It was originally based off of that. I think it’s changed a little bit.

Oh, cool. Yeah, I feel like there are just so many approaches right now, and the biggest thing when you start along this path is just choosing something and feeling like you don’t wanna waste your time on something that’s not gonna work for you at all… So this was really helpful.

I wanted to touch on something that hasn’t been mentioned yet, that is sort of still very relevant to the CSS in JS discussion, and that’s the Houdini project. Has anybody looked deeply into Houdini, or is particularly excited about it that wants to talk about that is?

I love Houdini! It is so cool.

[laughs] Go ahead.

This is something that I actually didn’t know about until JS Conf this year, just a month ago or so… It’s something that one of the speakers brought up to me and was really excited about, and I started looking into it and it’s really an interesting approach to extending CSS going forward.

Yeah, when I was talking about being able to directly tap into the browser as the most powerful rendering engine in the world - this is taking that and 10x-ing it and saying “Hey, not only are we gonna let you build using these things that we’ve already figured out, but we’re actually gonna give you hooks into that underlying engine, so you could build your own.”

I hear that, and the cynic in me is like “What could go wrong?” [laughter]

Everything.

I feel like the most exciting part about Houdini is they are opening this up I think more so for feedback. I kind of think of it as Babel for CSS, because now that developers kind of have the ability to hook into the rendering pipeline, we can communicate back and forth with the different browser vendors and say “Hey, we’ve built this thing, and the community thinks it’s valuable”, and then the browser vendors can go back and implement it.

Exactly. Yeah, the Babel analogy is exactly right. One, it lets you polyfill things transparently for a very large number of things, which is extremely valuable; it’s something we’ve had in JavaScript for a while, but haven’t really had in CSS… But two, Babel has completely revolutionized the speed of change and improvement in the JavaScript language - having that feedback loop; that tight ability to test these new things out before they get fully resolved and inspected and laid out has just been incredible. It’s taken JavaScript from what was essentially a moribund language to being the most dynamically changing language in the world, and now we’re talking about that for CSS. It’s great.

[54:05] I’d like to just take a step back and explain what Houdini is from a high level, just in case you haven’t heard of it… Because a lot of people haven’t, like me. It’s really a collection of APIs that allows you to get into the rendering context of the browser, and it allows you to get in there and change things about how CSS lays things out. So there’s a layout API, a paint API, a parser API (which is what you’d be able to use to create your own CSS syntax), and then from there there’s things like worklets, that allow you to run code parallel to the other JavaScript code that you’re writing; something that’s like a worker, but then have access to the 2D rendering context, kind of similar to Canvas objects… So you can actually do a lot more animation-friendly things just by writing and using custom CSS rules.

Do you think it’s going to replace a lot of CSS in JS techniques? Or where do you think it can smooth over things the best if we take it back to some of the problems that CSS in JS is solving?

I think it’s solving different problems. I think this is about solving the – well, a couple of things, but one big piece of this is solving the browser support issue. CSS has historically had a very slow adoption curve for new features because of the browser adoption curve, and one thing we’ve gotten a lot better at on that is having evergreen browsers that keep updating… But this would be taking that to another level, because it creates the equivalent of a Babel, where you can not only have modern stuff getting adopted faster, but you have the ability to pre-distribute things by having polyfills that actually hook into the low-level rendering APIs.

How ready is Houdini to be able to use it today? Or is it still something that’s in process, that’s a little buggy etc.?

It’s not ready.

Yeah, there is a really good site called IsHoudiniReadyYet.com and they update that with the various different APIs and kind of where they are, and the progress of things. Unfortunately, I think the only sad thing is it seems like although this is an effort between multiple browsers, I know Chrome just really is kind of blazing ahead more than others.

Yeah, right now Chrome has support for the paint API and the typed object model, and then behind the flag in Canary it has support for three other APIs. They’re really leading the charge with that, with Mozilla coming in second.

I do think one of the things that we’ve seen in some scenarios is having somebody willing to lead the charge like that can often be a catalyst for change. Once you have it out there and people are actually using it and demonstrating the value, then the rest of the browser vendors can come along behind, and we’ve seen more enthusiasm about that broadly of late. I think one actually really interesting example of that is (in sort of a funny way) Safari with iOS.

[57:21] There are a whole bunch of mobile-specific browser techniques that were introduced by Safari first, and then have kind of gotten standardized across because they were useful… And this is a place where Chrome is really blazing ahead, which is not uncommon, but if we could get a lot of demonstration of the value of this, it may encourage the other browser vendors to push forward.

Does anybody have any more resources for those who wanna get started with either Houdini or CSS in JS?

So I posted in the Slack, Houdini.glitch.me is a fascinating site, set up by (I think it’s) Sam Richards, that really demonstrates a lot of the power of Houdini, with a bunch of interesting examples… And they both have an explanation of how it works, but then you can also often see examples if you’re in a browser that supports it.

I’ll also add into the Slack the actual Houdini drops, if people want to read through that on GitHub.

Awesome. And Ben in our community Slack has said that for the Emotion library for doing CSS in JS, the documentation apparently has some really awesome examples for getting started with… So we’ll also drop a link into that, which is emotion.sh.

So that finishes up this episode of JS Party. We hope that you’ve enjoyed it as much as we did producing it. I think that CSS in JS is a fascinating topic that we could always talk about forever, but we’ll leave it there today. We wanna thank you again for listening, and we’ll catch you next time. And thank you so much to Aimee for coming on our show, too. You’re absolutely delightful to speak to.

Thank you for having me, I had fun with you guys.