JS Party – Episode #45
The CSS expertise kerfuffle
with Suz Hinton, Nick Nisi, Kevin Ball, and special guest Aimee Knight
Suz, Nick, and KBall are joined by special guest Aimee Knight to talk about CSS, how it’s often trivialized and how that in turn affects the people who write it, what CSS in JS is, and how to get started with it.
Gauge – Low maintenance test automation! Gauge is free and open source test automation framework that takes the pain out of acceptance testing.
Rollbar – We catch our errors before our users do because of Rollbar. Resolve errors in minutes, and deploy your code with confidence. Learn more at rollbar.com/changelog.
Vettery – Vettery helps you scale your teams by connecting you with highly qualified tech, sales & finance candidates. Download their tech salary report for 2018 with insights from tech hiring activity in New York City, San Francisco, Los Angeles, and Washington D.C. Download at vettery.com/changelog.
DigitalOcean – DigitalOcean is simplicity at scale. Whether your business is running one virtual machine or ten thousand, DigitalOcean gets out of your way so your team can build, deploy, and scale faster and more efficiently. New accounts get $100 in credit to use in your first 60 days.
Notes & Links
Click here to listen along while you enjoy the transcript. 🎧
We also have Nick. We’re very pleased to have you on the show, Nick.
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.
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.
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.
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?”
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 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.
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.
[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.
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 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.
[32:02] Well, there are some things for which scoping is necessary, or extremely valuable, right?
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.
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.
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?
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.
[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.
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?
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]
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.
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.
Our transcripts are open source on GitHub. Improvements are welcome. 💚