Episode 002

Claire and Steph talk about their experience with CSS - why it matters, what flavors they've seen, and why that experience matters. Tailwind, CSS-in-JS, even Bootstrap gets a mention!

Transcript#

Claire:

Hey.

Steph:

Hey there.

Claire:

I'm Claire.

Steph:

And I'm Steph.

Claire:

And this is Word Wrap.

Steph:

Last week on our first episode, we brought you a lot of topics. But this week we're going to get a little more focused and talk to you about CSS. CSS is one of the fundamental languages of the web and yet attends to get a pretty bad rap. So coming from a couple of folx who have been working with it for a significant amount of time, we'd like to talk to about the joys of CSS, but also some other topics that frequently come up in the modern web.

Claire:

Yeah, I think one of those items is: is it really a programming language? And I see this all the time on Twitter.

Someone says it's not a programming language, or you don't - you're not a real dev if you say that you write CSS. And you know, I've never really seen anyone master CSS in a consistent manner

... and I find that really funny for to one think about because programming languages in general are kind of not systematic. They've got documentation and like, you know, you don't really have to remember everything. Like for example, I don't remember everything that's on an array in JavaScript, but in CSS, you have to know all of the property types and all of the measurement units. You have to know all of the selectors and pseudo selectors.

Steph:

You also have to kind of imagine what's going to happen before it hits the page.

Claire:

Yeah, but CSS is really, really, really great to write and see your like, words, essentially, you know, written in CSS come to life. And then sometimes not come to life depending on browser support.

Steph:

So we both have a pretty deep background in terms of starting on the web and having that start be pretty ruled by Bootstrap. And so it's interesting to me to see the evolution from Bootstrap - which is still alive and kicking - but to other methods that folx are using. Things like Tailwind, or Cube CSS, or their own variation. Or going full in on a design system solution that maybe uses a particular naming convention like BEM. And I would say none of these approaches are wrong. I think where the interesting discussions come out on the web is folx - just like any other programming language to your point, Claire - is folx getting like "Mine's the best!". And when really - again, just like any language - it's all context-dependent. And it depends on the skills of your team. It depends on your goals. And it, I think more than anything, depends on the process that you have in terms of meeting the needs of your clients, meeting the needs of your users. And I really go back quite frequently to assessing the skillset of the team because that is such a huge impact on any selection in your tech stack.

Personally, I really enjoyed Bootstrap. I think it did a lot of great things. I think it gave us a good foundation for moving these ideas forward on the web. I liked that it was a utility framework but had a bit of opinions. So it was kind of a middle ground between full utility and borderline design system. So I think the idea of like helping more developers understand how to componentize their CSS was a really positive thing that Bootstrap brought for a whole generation basically of developers at that time, but I think we've kind of strayed from that. And I'm wondering - so I've been thinking about things like Tailwind and wondering "Why is that so popular?" And recently I asked what parts of building a website folx tend to get stuck on, and to my surprise most of the answers had to do with design. So that led me to kind of a theory that the reason why Tailwind in particular is so popular is because it's not only giving you the CSS - which makes folx grumpy if they're doing it themselves - but also it's giving you full-on designed opinions.

So I would be interested in your opinion, Claire, on like frameworks and whatever else around like the process of creating CSS.

Claire:

Yeah. So Bootstrap was... I actually got introduced to Bootstrap when we worked together several years ago. But I think that Bootstrap really helped me kind of develop those mental models of how to combine your CSS in a way that like is meaningful. And also just write it in a way that like someone can come back to and be like, "oh this makes sense" or you know, like "oh I can extend off of this". Obviously with Bootstrap, you know had a really great documentation system, which was fantastic. But like you said, I feel like the web has kinda moved on or at least has diversified. Which is great because I remember a couple years ago we were talking about how like everything looks like it was made with Bootstrap.

And - and really that was the case. I'm a big proponent of BEM. I'm a big proponent of you know, really obviously doing what's best for your team and stuff. But, you know having those strong opinions about you know, like how you've come through with your CSS and stuff.

So on the topic of Tailwind... Tailwind is one of those things - and I feel like this gets stronger as I become more of a seasoned developer and like, I, you know, I become a curmudgeon - I'm just like "Arghh" you know - but I think Tailwind actually emulates something that a lot of people, especially if when they're learning CSS that they do once they figure out they can do it, which is: open up the DevTools and you know start playing with the properties. CSS properties on certain elements. And I think that in a way as long as you learn the Tailwind like, you know, like the classes and stuff like that to do the certain things - you don't have to really, you know, remember like, you know, all of the intricacies of you know, like margin. Like margin's four properties or three properties - the three properties always messes me up because I always forget which one is combined but you don't have to understand that with Tailwind. You just know, you know, you want margin-top whatever. I actually got into an argument fairly recently about how Tailwind - how you should just learn CSS and someone was like, well, you can just once you find what you want, you can use the @apply rule to essentially codify that. And I thought it was silly at first because it's like, well, wouldn't you just put those CSS properties into a class and call it good?

Part of me wonders if it teaches CSS, and part of me wonders if it teaches a specific language variety of CSS, and I would argue that the latter is not beneficial to someone learning CSS.

But if someone learns CSS and then takes on Tailwind, obviously their opinions can shift that way and that's okay. I feel like although it is a valuable learning tool - you shouldn't learn it [CSS] in the context of Tailwind. It's the same thing I hinted at in the first episode with React and JavaScript - you know at the end of the day, you're writing JavaScript, but you're doing it within a React worldview and that can skew some of the ways that you write things when you're not in a React worldview. So I guess that's my main concern with that stuff.

We also have it on our topic list, but CSS in JavaScript, which is kind of a nice segue. I feel like Steph - I haven't really had a lot of experience with CSS in JavaScript, because I haven't really touched a lot of React things. But every time that I look at something that has CSS within JavaScript, especially like - and we'll get to this in another episode, but Active CSS - which solving problems does great, but I will still have my opinions.

What are your thoughts on CSS in JavaScript Steph?

Steph:

So I do have experience with that. At my previous position I was creating a multi-platform design system with one flavor of that being React, and it was also highly based on Material Design system. We used Material UI as an underlying - kind of to kick-start - and so with that I sort of inherited the JSS flavor of CSS in JS. So as opposed to Styled or Emotion - I'm not quite sure, I didn't get to play with those other kinds - at first I was a little annoyed by it, but then I came to understand the benefits.

Oh, by the way, I'm not about to advocate for it, but I will discuss what the benefits I saw were. So one of those that annoyed me at first and I came to enjoy was the idea of scoped CSS.

So while I am a little sad that it makes somebody who's trying to like look at something you've created and learn from it more difficult by having scoped CSS because it's crazy nonsensical class names and whatnot. The benefit that that's providing - at least the JSS method (which is the only one that I can speak of) - of that class is that it created dynamic stylesheets for your particular view. And so, once the app is hydrated (since we're talking about React), once the app is hydrated, you know, page to page it's continually making dynamic stylesheets. And I'm not quite sure what that does for performance page to page, but when you're using that coupled with server side rendering, then you know you do get a performance boost on the fact that it's not loading your whole class. The other thing that's unique about React though is that it drives you to make everything component-based, whether you're doing a design system or not. So, I think all those methods, all those types of ways to do CSS in JS, they all drive you to do that scoped classes idea. It just kinda renders it differently depending on the method you choose.

So, it's interesting - you don't end up writing it too much different - like JSS actually borrows a lot of ideas from Sass, like you could do nested selectors. And with Material, and of course it's all flowing through JavaScript first, so you can use JavaScript to mimic some of the things you also use in those other tools, such as various color functions, and what have you. So also from the perspective of making sure that our design system - which was intended to be themeable just like Material is, we kept that idea - it offered some methods to insure that colors maintained accessibility because we could check them using JavaScript.

So there are some benefits for sure, I think again - everything really goes back to your team and your goals and what kind of - what are you building? Are you building a website? Okay well, that's still a big question, right? Are you building a static website? Are you building a WordPress website? How many editors are getting in here? How many developers are getting in here? Who needs to know the styles?

I think that's the biggest question when we're talking about CSS is who needs to know the styles? How easy does it need to be for somebody to pick up and create a new feature and with styles intact.

And that's where the rise of design systems have come through - and that's why Bootstrap remains popular.

I'm going to jump back there for half a second - so back to Claire's point about making all sites look the same -

the one thing about any system that you choose to use is that one of the potential pitfalls of choosing a path to design your CSS is feeling trapped that that is now the only way you can design new features. And that traps developers sometimes - and it can hinder UX and UI improvements.

So, have you had any experience with your chosen CSS method feeling like it was hindering more than helping your team?

Claire:

Uh yeah, actually I have, and it's funny that you ask this because it's happened with my preferred way of doing it - which is BEM. So, we, at a previous employer, we had a component that had a lot of different extensions on it, and a lot of different elements within its block - and I say extensions I mean modifier. In BEM, it's block - element - modifier. But, you know, there's a point when a CSS component can get too complex and I feel with BEM it is a little harder to figure out where the separation of responsibilities lies, and where you should go about like, essentially making two components that do similar things. And I guess I can't say I felt trapped, but I definitely got into one of those situations where I wasn't really sure where to go from here. Because it's one of those things where it's like my opinion could differ from someone else's on the team and although it's not necessarily a bad thing - when you get to that fork in the road it's not necessarily clear where to go from there. You have two obvious choices I feel like - one, break up the component, two, don't break up the component. But if you don't do it then, when are you going to do it? And then it becomes an issue of tech debt.

So to answer your question, I guess I don't really know if that's feeling trapped as much as it's feeling trapped based upon the conventions that were previously set out, if that makes sense. And I think that all leverages whether or not you have a strong relationship with your design team and making sure they're aware of what is already codified, and like if they can utilize that instead to make it less complicated.

Steph:

Yeah, I would agree - I think one of your points in there was essentially extending what the system has to offer for you.

I also realize we've been talking a lot in the context of teams, and of course we have folx who are beginning CSS, who are freelancing, and you know, then at that point you're having to of course make those decisions kinda solo, or wading through and trying to make the right decision, and I think in a future episode we can maybe re-attack that in the future. You know, the idea of approaching learning. But I think we've covered a lot of really good topics today. We hope that something resonated with you and we'd love to hear your thoughts.

Claire:

Yeah we wanted to talk a little bit about our opinions with CSS and just kinda our experience, but we also recognize that we might have listeners that are all across the spectrum of experience and so we want to extend - maybe you have questions? Feel free to let us know at @wordwrapshow on Twitter. We might address them in a future episode.

Steph:

Thanks for joining us on another episode of Word Wrap. Be sure to subscribe on your favorite platform, or pick up the RSS feed on wordwrap.dev. You can also catch us as @wordwrapshow on Twitter. Until next time!