Bedrock Layout with Travis Waith-Mair

Episode Description

Travis Waith-Mair discusses his CSS layout library Bedrock, the evolution of CSS from floats to Grid, and finding balance in the CSS-in-JS debate.

Episode Summary

Travis Waith-Mair joins the show to talk about his open-source project, Bedrock Layout Primitives, a React-based layout library built on styled components. The conversation begins with Travis's winding path into development, from learning QBasic and HTML in high school to pursuing music, then finance, and finally circling back to programming after automating his compliance officer job. The hosts explore the broader CSS landscape, touching on why front-end content dominates free learning resources and how CSS has evolved from float-based hacks to proper layout tools like Flexbox and Grid. Travis shares the origin story of Bedrock, which he built during a Christmas vacation after his employer refused to let him open source the layout system he'd created internally. The discussion moves through opinions on Bootstrap, Tailwind, and CSS-in-JS solutions like styled components, with Travis drawing a useful comparison between Tailwind and CoffeeScript. He explains his philosophy of "encapsulated CSS," where parent containers should control layout rather than individual elements styling themselves. The episode also covers practical topics like responsive design pragmatism, container queries, DOM cleanliness versus over-optimization, and how Bedrock handles accessibility by making the right path the easiest path rather than trying to lock developers down.

Chapters

00:00:00 - Introductions and Travis's Path to Programming

The hosts welcome Travis Waith-Mair, creator of Bedrock Layout Primitives and developer at Anatomy Labs. Travis describes his background as a front-end-focused developer who also maintains a course called Composing Layouts in React. He traces his journey from learning QBasic and early HTML in his 1999 high school class to pursuing music, then pivoting to business and finance.

Travis recounts how he worked as a stockbroker and compliance officer before falling back into programming by automating tasks with Excel VBA. After losing his compliance job, he committed to becoming a developer through free resources like CS50 and freeCodeCamp. The hosts discuss why free coding content skews heavily toward front end, with Chris noting that front-end complexity drives more teaching material, while Anthony highlights how the visual feedback loop of HTML and CSS makes it an easier entry point for beginners.

00:06:17 - The Evolution of CSS Layout and the Complexity Beneath

Travis describes the Dunning-Kruger effect in learning front-end development, where initial confidence from writing simple HTML gives way to realizing CSS and accessibility are far more complex than they first appear. Chris reflects on his own experience with CSS layout evolution, moving from float-based approaches and Clearfix hacks to Flexbox, and now feeling that Grid should be the default tool for most layouts.

Travis characterizes the CSS community as spanning from purists who manage stylesheets entirely by hand to developers who avoid writing CSS at all costs. The hosts ask Travis about Bootstrap, and he explains that while it was invaluable in simplifying layout during the float era, modern CSS has matured enough to handle layout natively. He notes that CSS was originally incomplete and being used beyond its intended purpose, which is why frameworks like Bootstrap were necessary in the first place.

00:10:23 - The Origin Story of Bedrock Layouts

Travis shares how Bedrock was born out of frustration when his employer at R1 refused to let him open source the design system he'd built. During his Christmas vacation, he spent a week extracting his layout library concepts, hiring a logo designer on Fiverr, building a website, and launching it as a standalone open-source brand. The hosts appreciate the scrappy origin story and the quality of the Fiverr logo.

The conversation shifts to why Bedrock is built on styled components rather than Emotion or other CSS-in-JS alternatives. Travis explains it was partly practical continuity from his work at R1 and partly personal preference, as he enjoys the way styled components separate style logic and allow JavaScript sprinkling. Chris shares his own experience switching from styled components with Twin to standard Tailwind for build performance gains, and Travis draws a comparison between Tailwind and CoffeeScript, arguing Tailwind provides good defaults with more freedom than opinionated frameworks like Bootstrap.

00:15:58 - Tailwind, Types of Front-End Developers, and Bedrock's Philosophy

Chris raises the point that the type of front-end developer you are determines which CSS tooling makes sense, distinguishing between developers building design-forward sites versus those assembling dashboards with forms and tables. Travis extends this to include developers building CMS templates and WordPress themes who have different constraints entirely, and argues that different state management and CSS approaches exist because the spectrum of front-end needs is genuinely wide.

Anthony asks where Bedrock fits on this spectrum, and Travis explains the library is built around layout patterns rather than specific CSS technologies. Using the Stack component as an example, he describes how developers shouldn't need to know whether Flexbox or Grid powers the layout underneath. He emphasizes composability as a core principle, where components like Stack handle only stacking while padding is handled by composing a separate PadBox component around it.

00:19:40 - Responsive Design, Spacing, and Encapsulated CSS

Chris discusses the challenges of responsive layout, particularly the awkward middle ground between mobile and desktop screen sizes, and raises the question of whether margin should still be used in modern CSS. Travis introduces his concept of "encapsulated CSS," the principle that elements shouldn't set their own size, margin, or position, and that parent containers should control layout decisions for their children. He connects this to how Flexbox and Grid already work, where the container declaration affects the child items.

The conversation turns pragmatic as Travis and Chris discuss whether internal business dashboards truly need full responsiveness, given that users typically view them on one or two screen sizes. Travis argues that developers often over-optimize for edge cases that real users forgive, and that the era of fixed Bootstrap breakpoints has given way to a much more complex device landscape that includes fridges and 4K TVs, making it impossible to design for every possible viewport.

00:25:46 - Hooks, Container Queries, and DOM Cleanliness

Anthony explores the hooks that Bedrock ships, including useForwardedRef, useStatefulRef, and useContainerQuery. Travis explains that useForwardedRef became his most downloaded package because it was adopted by React Responsive Modal, and describes how useStatefulRef provides a drop-in replacement that makes ref objects trigger re-renders. He then explains container queries, both the modern CSS spec and how his hook implementation differs by returning boolean matches rather than applying CSS changes directly.

Chris brings up the Twitter approach of rendering entirely different component trees per screen size, and the broader question of DOM cleanliness versus shipping features. Travis argues that while a clean DOM is ideal, developers shouldn't over-optimize at the expense of building real value, noting that even Bootstrap's div-heavy markup could produce accessible websites. He advocates finding the right balance between CSS and JavaScript responsibilities, suggesting that whichever approach is easier to maintain long-term is usually the right choice.

00:35:12 - Accessibility, Contributing, and Wrap-Up

Anthony asks how Bedrock handles accessibility, and Travis shares lessons from his design system work at R1, where locking down class names to enforce correct usage backfired because developers couldn't get work done and found workarounds anyway. His philosophy shifted to making the correct path the easiest one, such as exposing the "as" prop so developers can use semantic HTML elements, while accepting that determined developers will make poor choices regardless.

The episode closes with Travis inviting contributors to Bedrock's GitHub, sharing a story about how the Reel component originated from a community PR. He directs listeners to find him on Twitter or the React Podcast Discord server. The hosts thank Travis for being both a guest and an avid listener of their back catalog, and the conversation ends with lighthearted banter about Hacktoberfest timing and Christmas-themed website plans.

Transcript

00:00:00 - Christopher Burns

This iOS 15 update is magical. I can just tell it to ignore everybody, even Slack.

00:00:06 - Anthony Campolo

What a life. Travis, welcome to the show.

00:00:19 - Travis Waith-Mair

What's up, guys?

00:00:20 - Anthony Campolo

Awesome to have you. You work on a CSS framework. I think I would call it a meta-framework. We can get into that a little bit as we go, but we're big fans of frameworks here, and we're even bigger fans of meta-frameworks, so this should be fun.

Before we get too deep into the conversation, though, you have actually been listening to the entire back catalog. I'd be remiss not to ask a little bit about that experience. But first, why don't you just let our listeners know who you are, where you work, and what you do?

00:00:48 - Travis Waith-Mair

I'm Travis Waymire. I currently work at Anatomy Labs, where we build out privacy web solutions, but in my free time I'm also the creator and maintainer of Bedrock layout libraries. I also have a course based on that library now called Composing Layouts in React. Yeah, that's basically what I do.

I would call myself a front-end developer, though I don't touch just front-end. Kind of like being full stack, but I really consider myself a front-end guy, if that makes sense.

00:01:16 - Anthony Campolo

That does make sense. And I would imagine that listening back to our podcast, you get a good range of a little bit of everything, but maybe a little more back end than front end. So you've had a lot of database people on. We've had people from Prisma, but we really haven't had much good CSS content. You actually suggested a handful of CSS people we should reach out to, which I'm still working on getting them on. But this will be a really good chance for us to get into CSS itself. And if we are the full stack Jamstack, then you can't have a full stack without CSS. What was your journey into this whole CSS world?

00:01:55 - Travis Waith-Mair

This kind of goes back to how I got into programming. I've been touching programming and web development little by little since I was in high school. In high school, I needed a computer credit to graduate, and I'm like, yeah, I'll take this random computer class. I didn't even know what it was, and it ended up being programming in BASIC, QBasic. Technically, BASIC has several dialects, but it was specifically QBasic. Loved that class.

At the same time, and this dates me, I graduated in 1999, they were starting to bring broadband to the school, and they were letting the people who were excelling in the programming course start auditing the new web course that was coming out the next year. So I got to play around with HTML and CSS development at the end of my senior year, and I loved it. And then I walked away because at that time I was really a music guy. I had been in every band class that I possibly could get away with and still graduate.

It just never occurred to me, even though I enjoyed that class, that I would want to be a programmer. I started college and realized that I didn't want to be a musician, and I didn't want to be a band teacher, because I had just watched my band teacher in high school start as a new teacher and then, two years later, quit because he hated teaching. I realized being a band teacher wasn't the same as being a musician.

00:03:14 - Anthony Campolo

Definitely can't identify with that. Certainly not. I definitely didn't have that exact same story, word for word, happen to me.

00:03:21 - Travis Waith-Mair

So yeah, exactly. I had watched that happen in front of my eyes. I'm like, I don't want this anymore. I kind of floundered and took some general eds, and I ended up becoming a business major, went into finance, was a stockbroker, then a compliance officer for a while. I fell back into programming because I started automating my job as a compliance officer. The only thing that got me happy every day was writing Excel VBA scripts and reading the actual script tags and recreating the JavaScript in Excel.

Anyway, it took a while, but I finally came back. After I lost my job as a compliance officer, I decided I'm not doing this anymore. I'm going to go be a developer. I couldn't even pay to go to a boot camp, so I was taking any free resources I could. I did CS50, Harvard's basic computer science class. I did freeCodeCamp. I just did whatever I could until I convinced somebody to give me my first job.

And then from there I was able to go, and just like any free resources, there's a lot of heavy front-end content. You've talked about this on your podcast. Boot camps say they're full stack, but they really emphasize the front end. I think, for some reason, the front end is either easier to get people jobs or it's just easier for people to understand. I don't know what it is, but it seems like the content online, especially that's free, is really front-end-heavy. And that's what kind of got me back into that.

00:04:40 - Christopher Burns

I think it's the complexity. At the same time, front end has so much more complexity to it than back end. We're seeing brand-new things like GraphQL take the industry in that direction, but we're seeing things as simple as, when you're teaching back end, if it's modern back end, it's function-based. You can't really go wrong with functions. So is there so much that you can teach there? Well, there is, but we tend to remove a lot of it from teaching. I think front end gets reinvented every seven years, unlike the back end, which has been the same for 20.

00:05:13 - Anthony Campolo

I think there's also an idea that people can see it, so it'll make more sense to them. And I think, for the most part, this is true. I think some people's minds work in a little bit of a different way, and the back end does make more sense to them. But for the most part, when you can write some HTML and then kind of see something appear on the screen, and then write some CSS to change it, and then see that change on the screen, you get that really good feedback loop.

Versus, as you're saying, Chris, you can write functions and then that function will just return some data. But if you're starting from total scratch, you don't even know what a function is yet. So even learning how to write a function, you're going to have to get beyond that before you can start seeing something happen. So that's, I think, some of the idea. And then usually you'll kind of work your way further back into the back end, and more people will drop off as you go.

And some people will kind of stay where they are. So you end up with more people on the front end and more people making content for the front end. But I also think it works out because, as you're saying, the front end is a lot more complicated. We need a lot more people who know front end and can kind of work with this stuff. So it all seems to balance itself out, for the most part.

00:06:17 - Travis Waith-Mair

You're an educator, so you probably can explain this better than I can. There's that initial hump where things are easy, and then you go down to that pit of like, I know nothing, and then you climb up a little higher because now you know a little bit more and you're more confident. The whole front end has this initial confidence-boosting ability, like you were saying, like, oh, I just put some tags here and things work.

Also, you start realizing CSS is way more complicated than just the cascade makes it seem like it is. Especially because when you first teach about it, they're like, oh, it's just these three levels of cascade. It's much more complex. There's a whole calculation based on that, but you don't get into that until you start actually going into some non-trivial apps. And then, yeah, things like HTML, it seems so easy until you start realizing, oh, I have to account for accessibility and all these other things that are all in the HTML.

00:07:01 - Christopher Burns

One of the biggest things I think I've seen in CSS in my time is the different ways of producing a layout. When I started learning CSS, you would float basically everything on a page. You'd float it left, float it right, you'd use clear... what was it?

00:07:18 - Travis Waith-Mair

The Clearfix?

00:07:19 - Christopher Burns

Yeah, Clearfix and all of that. And then we got told, now flex is here. Start using Flexbox for everything. And now I kind of feel we should be using Grid for everything, and Flexbox is this thing that you should only use sometimes. It's confusing, but there are so many ways to just put something on a page. And then there are also people saying your whole web app should just be a canvas. Like, what?

00:07:43 - Travis Waith-Mair

That's really the funny thing with CSS. There's the CSS purists all on one side. And I said this before, but I'll say it again. There's some who are just so pure, like, don't mess with my CSS stylesheet. I don't even want to use tooling or anything. I'm going to manage that thing, and I can keep track of that whole stylesheet in my head.

And then you have the other extreme, which is, I hate CSS. It's a horrible language. I can't believe this is our visual language. I'm going to do whatever I can not to write an official CSS line in my app at all, and I'll use whatever tooling I can to get away with that. I think there's some good balance right in the middle, depending on where you are with your app and your needs.

00:08:20 - Christopher Burns

My first big controversial question is: what's your opinion on Bootstrap if you call yourself a CSS guy?

00:08:27 - Travis Waith-Mair

My opinion on Bootstrap now, and I'm going to preface this: I have not checked out the latest Bootstrap that's been announced. I haven't even been following it other than I know it's there.

00:08:36 - Christopher Burns

Bootstrap 3, then.

00:08:38 - Travis Waith-Mair

Yeah. And for it a little bit before. Yeah, basically Bootstrap 3. I got my first job really knowing Bootstrap 3 better than I knew real CSS, and I think a lot of people did when I was coming up because it was great. It made complicated CSS easy to understand. It's like, I want three columns. Let's just throw these class names on. You didn't really understand what was going on under the hood. That's fine. It's kind of like learning React first. You don't really understand the JavaScript that's going on underneath, but that's okay. You can be productive and then you can do a deeper dive later.

It simplified layout in a time when it needed to be simplified, because, like you were saying, floats aren't as simple as just float left, because then you have to think, well, I want some margin in there. How much margin? I'm not really taking up 30%. I'm not doing three-column layouts, so it's not like 33-point-whatever percent I need to account for.

So you had to do a lot of math, and it became a lot of who likes to do math. There was still... the only math you had to do was like, okay, I want three columns, so what's three divided by 12? So I want a four-column. You had to do that little play. But that's a lot easier for most people to handle. Nowadays, I don't think it's necessary because CSS, I think, has kind of graduated to the point where it's now a complete language for what it was being used for.

That was, I think, the biggest problem. CSS was incomplete when it first got adopted, and we were using it for more than what it was technically written for. It didn't account for actually doing layout. The only layouts were normal flow and floats and all that. That's part of what they call normal flow. Floats are really just designed to float an image or a div on the side that's supposed to be on a side and allow the main content to wrap around it.

That's all it was technically written for, but we were using it for these complex layouts.

00:10:23 - Anthony Campolo

Before we get too deep into some of the CSS stuff, I would first like to hear the origin story here, because I think this project has a pretty cool origin story, based on the things you've told me: that you open sourced this to send a message to your last job that they should have let you open source it, right?

00:10:41 - Travis Waith-Mair

Yeah. Well, I mean, I was part of two different design systems. The first one I was more of a junior developer on, so that was never even part of my discussions to try to open source it. I know the leads on that team wanted to. But the biggest one was when I was at R1. I was hired to create the design system team. I was the new tech lead, and we were building the design system team. And I'm like, hey, I would like to open source it. I got this interview with management to be like, I really want to do this. Here are all these benefits we can get. We can integrate with Figma and all these things a lot easier if it's actually open source and not in some private npm repository.

Before I could even get a word out, they were like, no, we're not going to do this. I was just like, okay, that's it. And I was going on vacation soon after that for my Christmas break. That week I just spent all my free time moving everything that was my bread and butter, the things I was bringing to the table.

We had a designer who was doing all the design tokens and all the style guide and all that, but I was bringing this layout library that I had been learning through different sources and this concept of composing layouts. I'm like, I'm going to do this, and not just do this, I'm going to do this right. And I hired a guy on Fiverr to go get me a logo. I'm like, I'm going to make a website and everything, and I'm going to make this a brand in and of itself. I did it in a week, got the first few components in there, and just kept adding to them.

00:12:02 - Christopher Burns

That's really cool to hear. I like the Fiverr part. Fiverr is this risky thing for me. I keep thinking everybody on there is just going to rip someone else's work off and then say that they made it, but there's probably some pretty good stuff on there. And your logo looks pretty good, to be fair.

00:12:19 - Travis Waith-Mair

Actually, I was surprised. I was like, I just want a logo. Here's my name. Find something. And I was like, this is pretty good. And I gave him a $10 bonus on top of that.

00:12:29 - Christopher Burns

That's pretty good, because I think Fiverr gets a bad rap sometimes. One of the big things to talk about with the framework is that it's based on styled-components as the base.

00:12:39 - Travis Waith-Mair

Yep.

00:12:39 - Christopher Burns

Why? Styled-components and not Emotion?

00:12:42 - Travis Waith-Mair

Not Emotion.

00:12:43 - Christopher Burns

It's a good question.

00:12:44 - Travis Waith-Mair

No, it is.

00:12:46 - Anthony Campolo

Why Emotion and not any other ones?

00:12:48 - Christopher Burns

Have you heard of these new ones called, like, Stitches?

00:12:51 - Travis Waith-Mair

Oh, yeah. And there's down in Australia, the CSS Braid guy. I can't think of his name. He was part of CSS Modules, but now it's Vanilla Extract. That's what it was. That's the new kind of cool thing going on.

But styled-components, honestly, because we had decided to use styled-components in our design system at R1. That was one of the decisions we had made, that we were going to make that our base, partly because of my influence, because I actually do like styled-components, and I'd been using it long before Emotion came in. I hadn't run into a compelling reason to switch to Emotion while I was deep in the styled-components world. And at this point, it's sixes. As far as performance, the difference between them, there's really not that big of a difference between the two libraries. They really push each other to be better.

But anyway, styled-components. I decided to keep styled-components for Bedrock because, A, it made it easier for me to rewrite the components I had already written in our other style to Bedrock, and it's my go-to library. When I write an app, I typically bring in styled-components on my own, and the team will make that decision. But if I'm just going to write something on my own, I usually bring in styled-components. I like the way I write components with it, and I like the way it keeps the style logic separate from everything else. And I typically want more than just CSS. I typically want a little sprinkling of JavaScript. So if I'm going to do that, styled-components makes that a lot easier to handle than anything else.

00:14:13 - Christopher Burns

I've gone back and forth on multiple of these, CSS-in-JS to PostCSS and back to it.

00:14:22 - Anthony Campolo

Macro.

00:14:23 - Christopher Burns

Yeah, yeah, that's in there as well. What I've learned is that there's definitely a place for all of them, and it's picking the right one for the right thing you're doing.

00:14:33 - Travis Waith-Mair

100%.

00:14:34 - Christopher Burns

I actually had styled components plus Twin in an earlier version of our dashboard. It was making the compile times like five minutes, six minutes. It was getting crazy. I replaced it with just standard Tailwind, obviously through PostCSS and the JIT, and it went down to a minute or two, and I was like, wow, all of this extra CSS, what was the point of it?

But the point of it all was that it was providing this really nice syntax to work with that I do really enjoy. I really enjoy the styled syntax. And when I said why styled over Emotion or whatever, it's because styled-components really set that syntax in place. And I think a lot of people do enjoy it. And that's what you miss out on with Tailwind. It's just scattered everywhere across all your class names.

00:15:23 - Travis Waith-Mair

Exactly. My opinion of Tailwind is that it kind of has the same relationship to CSS as CoffeeScript has to JavaScript. It's not high enough to really call it a framework in the sense that it's a bunch of design tokens and design decisions, but the language is written with classes. Anyway, it's doubled down in that. I think that's why a lot of developers like Tailwind, because they have a bit more freedom than they have with Bootstrap or Ant or Material, but they still get some good defaults. And I think that's why Tailwind has taken off.

00:15:58 - Christopher Burns

I think it is only because we're seeing a majority of front-end developers that focus on the design. And I think this is something that not much of the industry is talking about, to some extent: what kind of front-end developer are you? Do you just want to put some graphs and forms and some tables on a web page and call it a day without thinking about the design? Then Tailwind is definitely not the thing for you, because you're going to be wasting all your time deciding what a button is, when if you go to something like Bootstrap or Bulma...

00:16:32 - Anthony Campolo

Bulma.

00:16:33 - Christopher Burns

Whatever's out there, it's just a button. You just type button and it's done. It is this thing of like, well, we think Tailwind is really, really popular. It is. But the people shouting the loudest about it are the people who are like, look at my design that I made in Tailwind, when the people who just make 20 dashboards don't really care about that.

00:16:53 - Travis Waith-Mair

Or you have the people who are building Gatsby sites or CMS sites, you know, WordPress themes, whatever. That's not going to be helpful in those kinds of cases because you're also having to deal with other people's markup and classes, and then you're injecting things on top of that. It's like you're saying: what kind of front-end developer? That's a huge spectrum in itself.

You have people who are building complicated, sophisticated apps. It's why there are 30 different ways to manage state with React by itself, because everybody has different needs. Some people are like, 100%, everything is on the server, and they don't want to maintain any state on the front end beyond, is my tooltip open or something like that. And then you have other people who have to keep large, complicated things and data processing in the browser, and they know that, and they have to build around that and optimize for that.

I think it's the same thing with CSS. You have people who need to build templates for CMSes and things like that, and then you have people who need to customize and have a sprinkling of logic that only JavaScript can do at this point riddled throughout their app to control their styles. Everyone's right in the decisions they make.

00:17:56 - Anthony Campolo

Yeah, so I'd like to get more into your specific project here, Bedrock layouts. I would be curious whether it's aimed at the people we've been having this conversation about. Do you build your library so that you barely have to write CSS? Do you really have to know CSS very much? Or do you aim it more at people who want to get down and dirty with the CSS? Do you feel like you're abstracting away CSS? Are you enabling people to write more CSS? Who is it kind of aimed at in that respect?

00:18:28 - Travis Waith-Mair

It is aimed at really anybody who wants to just follow some common patterns and think about layout as a pattern rather than a specific technology. For example, the Stack component, I go to this a lot because it's really easy to understand. The whole purpose is to stack something on top of another and have a space between them.

Well, whether I'm using Flexbox or Grid or just normal flow, you shouldn't have to care about that as the person using it. It should just be like, I know that if I put this in and I pass in the correct props, I will have something stacked on something else and I will have space in between it. And that's really what I try to do with all of these.

At the same time, I've also gone with the intention that I shouldn't recreate anything across components if I can avoid it, and if I need something in components, I should compose those together. So, for example, if I wanted that Stack to also have padding around it, it should be composing a PadBox around the Stack.

The Stack shouldn't know about padding. It should just know about stacking something on top of the other and putting space between. That's been my opinion of how a layout library should be. If these don't match what your requirements are, then, yeah, you need to dive a layer deeper and go to the actual CSS.

00:19:40 - Christopher Burns

I think these things can be super useful to get things moving faster. I find with myself, I don't actually write down my layouts how I want them to look. I just visualize it in my head and then code it as fast as I can. I'm one of those type of people. I like to get a rough draft first, you know, get it down as fast as I can, not looking pretty, just in the way you want it, and then build it up from there.

I find that stacks are one of these things that can catch you off guard really fast, depending on how you want your data to be shown on different screen sizes. Do you want all your data showing on every screen size? If you've got two separate columns and now you go to mobile, do you want the column on the right to come first instead of the column on the left? There are so many things that, obviously, we now have the freedom to do without these CSS hacks, as we say, but you just have to think about and plan.

And spacing, I think, is one of these things. Is there a true answer of what's the right amount of spacing to have around a card or padding? Should we even use margin anymore? I know there are some people on the internet who are saying stop using margin, just use padding and also rems.

00:20:51 - Travis Waith-Mair

And I think they have the right intention. Yeah, I've seen it. Max Stoiber and Ryan Florence have probably been the largest voices in this that I've seen. They're like, margin is bad. You should never use it. And I think margin isn't bad, but the wrong application of margin is what is bad. It's kind of like saying JavaScript isn't bad, but when it's really bad, it's bad. That's how I think of margins.

I follow a principle whenever I lay out things of what I call encapsulated CSS. It hasn't taken off, but it's a term I've used to group how I do layouts, which is: an element shouldn't lay itself out anymore, meaning it shouldn't set its own size, it shouldn't set its own margin, it shouldn't set its own position. That should be for the parent container to decide. The parent container should have the rules about where elements should be, what size they should be, and how much margin is in between.

And you can see that's kind of been the evolution of CSS as they've added things with Flex and Grid. It's the grid container where you set display: grid, but it impacts the grid items inside. It doesn't actually change the element itself very much. And then they have these one-off properties. But for the most part, when you learn Flexbox or learn Grid, you're creating div containers that are impacting grid items or flex containers that are containing flex items.

I think that's the right mental model in modern layout, which is, if you need to set margin or anything in between things, it shouldn't be set on the element itself. It should be set on the parent container, or using the parent container and a direct child combinator or something like that.

00:22:28 - Christopher Burns

Mm-hm. Yeah, I totally agree. I feel like we've gone through this weird evolution with everything. We would have a width and a height and a min-height and min-width. And now it's just: make the component work on a big screen or a small screen. It just needs to kind of work.

Where I see the most complexity with these is that really awkward position between a small screen and a large screen. You're shrinking your grid and you're like, okay, I need to go from 12 columns to six columns and then down to four columns, then one column, and it's just getting those numbers right so all the content just looks right. It's so, so hard.

I think even today, as an example, is a table. So you've got a table in a grid and then you start shrinking and shrinking it. And the table is like, what do I do? Do I just keep overflowing? Do I just overflow with scroll? There are so many things that you just have to get right.

00:23:21 - Travis Waith-Mair

And that comes down to different things. Like, what is the right answer? Because sometimes when you go down, it really just means let's move the data that doesn't need to be displayed into some other form so that you're still working with the table, but you only have three columns instead of six, because some of that information is interesting, but it's not critical. And so you move it out to some other form.

So responsiveness, for a while, we liked to think of it as this, like, oh, it's just simple. Just shift the layout to stack things as soon as we move to certain breakpoints. And this kind of goes back to the Bootstrap days. They had these fixed breakpoint systems, and it was a pretty good breakpoint system for the time because most screens fit within those kinds of things. But now we have to deal with, like, am I pulling up my web page on a fridge? Because you can do that now. Like Samsung, you can browse the internet right on your fridge.

00:24:10 - Anthony Campolo

Brave new world, right?

00:24:12 - Travis Waith-Mair

Well, yeah. And there's some people who are bringing up web pages on their 4K TV and making it go the whole width. And what does that mean as far as responsiveness?

Also, I dealt with this with a previous designer. We were working on an app that was an internal-only app, and I'm like, the company only buys one screen size. Why are we making these layout shifts for screen sizes that will never happen? If they're pulling this up on their phone, we have a bigger problem than if the layout looks right.

00:24:42 - Christopher Burns

I think that's a really interesting question. When it comes to business, do you have to make your dashboard responsive because that one person may open it on their phone and then be like, it doesn't look good? And it's like, what's the likelihood someone's actually going to load that internal dashboard on a phone? It's probably very, very little, but we're still spending so much time making sure it's responsive because I think as developers we like to be perfect, and we like to think, oh, we're going to view it half screen, half code window, half the dashboard. Oh, it's all broken. So we need to fix it.

And then you go into the real world and everyone's just viewing it full screen, super zoomed in because they've not got their glasses on that day. And that's just reality.

00:25:22 - Travis Waith-Mair

Or they only view it on two different screens, like their desktop, like you said, or their phone. And you don't have to worry about all those different variations in between. If the 98% use case is those two screens, just design for those.

I think we assume people are not forgiving, but users will go, yeah, I'm obviously using this on a device it wasn't intended for. That's why my layout sucks. And people just kind of accept that.

00:25:46 - Anthony Campolo

So I'm looking at your docs page right now, bedrock.dev, and you have it organized in kind of two big buckets. Here you have components, which include things like the Stack, which you've already talked about, and then things like Columns, Grid, Reel, Split, and Inline. And then you also have hooks.

I'd be curious to get into the hooks a little bit. So you have useContainerQuery, useForwardedRef, and useStatefulRef. Are these React hooks that are already built into styled-components, or are these your own custom hooks that you created?

00:26:21 - Travis Waith-Mair

These are my own custom hooks I created to solve problems that I needed with Bedrock. At first I almost inlined them all, but I decided, hey, I'm doing this, I've got a monorepo, let's go publish these as separate items. Might as well.

And it's funny that you say that. For example, the useForwardedRef hook. The whole intention is, when you're using React, forwardRef is great because it gives you that ref that you can then map to the correct ref that you want. But what if you also want to use that ref that may or may not be coming from somewhere else, and it may be an object or it may be a callback function? You don't get to know what that ref is coming in as, but you still want to use it because you're doing something under the hood.

So that's why I created useForwardedRef. That way I could take the ref from the forwarded ref, keep it in sync, and then return a ref object that I can keep in sync with the ref they're passing in.

The most downloaded part of my library is useForwardedRef, because I think React Responsive Modal has brought it into their library. So every time someone uses that, and it's more popular than my library itself, that gets lots of downloads and lots of love. That's what those are for.

useStatefulRef is also... I kind of got annoyed with the fact that you start off with a ref object, which is not stateful, but then you run into a situation where you need it to be stateful. So then you have to change the way you write the code, because you have to change it to use state and then just wire it up a little bit differently. And I just wanted a drop-in replacement. You can drop in useStatefulRef and it will pass out a ref object, but it will be stateful. So anytime you update the current property, you will potentially cause a re-render like updating your state would.

00:28:00 - Anthony Campolo

Good naming there on useStatefulRef. It's nice, clear naming right there. I dig it. And then useContainerQuery. That should be intuitive to people who know what a container query is, but I would guess that that might not be super common knowledge these days.

It's funny, the way I know container queries is I listen to ShopTalk a lot. And so Chris Coyier obviously runs the most successful CSS website in history, CSS-Tricks. And it's about other things aside from just CSS, but I get a lot of my CSS knowledge via him and listening to their conversations. And container queries I've always thought of as a thing that everyone wants in CSS. I never really knew why, but I know it's an extremely coveted feature they've been wanting to get in. So what are container queries?

00:28:46 - Travis Waith-Mair

Here's the funny thing: how I thought container queries should be, and how they are now, is not what this hook does.

And so now I'm running into it. But the idea of container queries is that, as Jen Simmons put it, you want algorithmic design, not responsive design. You just want to let the browser algorithmically optimize the layout for you based on the dimensions it happens to be in. And then you just kind of let the browser take the wheel, let Jesus take the wheel there. You just set up as much as you can and let the algorithm take over from there.

And that's where container queries would be helpful, because you're like, hey, if my container is this size... Well, this is how it is now. So I'm going to explain what container queries are now. That way there's no question. You can go, hey, I want to listen to this container, and you can do a little bit of wiring up and say this div or this element is a container, and then you can have something else listen to it.

And as it changes size, just like a media query would, you can do things. You can change your CSS. You can make it blue. You can do dumb things, but mostly for layout you can try to switch your layout. That's not what my container query hook does, though, unfortunately. What I'm doing is I'm connecting it to an element, and then as it resizes, I'm coming back and it will return, hey, this element changed its size and did it match the size I want? And if that thing matches the size, it's true.

So I guess it kind of does, but it's not getting the same information in exactly the same way. You couldn't just drop in and replace container queries now for what you're trying to do. Because what I end up doing with that is I'll typically go, hey, this element changed to this size. I want to change this to a Stack layout instead of a Split layout, or I want to change this to a Stack layout instead of a Column layout, for example.

So it's in the same vein, but it doesn't do exactly what the modern CSS spec is.

00:30:43 - Christopher Burns

Yeah, I've just looked up the CSS spec, and to me it looks like what it's doing is, instead of saying min-width of the whole screen, it's looking at the min-width of the actual div and then it will change the CSS based on that. Interesting.

Because I've seen, like, I think it's Twitter, they've said have a completely different component for every screen size. I think it's something like React Socks, the open-source version that's based on the Twitter version, but they're saying have a mobile component, have a desktop component, and then completely switch out the DOM depending on the screen size. So taking away all that CSS computation for a more React-based computation.

I personally never saw any benefits from that except, well, I'm on mobile and I've got tons of divs that are now hidden that I may want to remove. But I guess what I'm trying to say is: should we rely on CSS more than developers want to? As in, it's okay to have 20 div trees and 19 of them are hidden on mobile, instead of saying the div tree must be clean and only have the HTML in it that's currently being seen.

00:31:50 - Travis Waith-Mair

I think that's a complicated question, which you probably assumed by giving that to me. The Twitter thing, I feel like that's optimized for their developers so that they can have a team that only develops the mobile, and a team that only develops the screen. I think that's what it's optimized for, and they're willing to deal with the fact that they're potentially ripping out the entire DOM and starting over again and whatever implication that has, with people potentially shifting their browser, knowing that people don't typically shift their browser that much, and that they're probably going to only be on one or the other, and it's only the weird developers who are constantly moving things around.

But to say, should we have a clean DOM? I think we should, within reason, do that, but not to the point where we're over-optimizing, like your for loops when an array map or an array forEach is probably just as good, even though they're technically slower. Sometimes I think we get too obsessed with, oh, I need to have this super-clean DOM, or, oh, we've got quote-unquote div soup out there.

People don't even know what that means anymore. So they're just like, if I have excess divs, that's a bad thing. No, they're not technically bad. The problem is when you're using so many divs that it's hard to get to the content, and it's hard for the accessibility tree. But people were writing accessible web pages with Twitter Bootstrap, and that definitely created a div soup to get all those layouts right. And you can create accessible websites.

So when possible, keep it clean, but not to the point where you're not building actual features, building actual value for your customers. At the end of the day, we have pretty powerful computers, and even low-end 3G phones in India can handle a few extra divs that are hidden in the background, already downloaded, already created, already rendered.

00:33:32 - Christopher Burns

It's just hidden with CSS. It's that thing of, like, some developers just don't want to deal with CSS. They'd rather put a JSX element in a breakpoint saying, at this size, do this, show this component instead. I think there's definitely value in there. If there's a very specific use case, I feel like we forget that HTML and CSS are completely separate languages that are combined. It's like a relationship, and you could do more in one than the other. But it's that agreement that I think works best.

00:34:06 - Travis Waith-Mair

I was just watching a thing today about how CSS can cause layout shifts if you write it the wrong way, and just about the different ways that if you write it wrong, it'll cause a layout shift. So if CSS can do it, we'll probably offload as much as we can to CSS because JavaScript is already overloaded. We already have this huge bundle size with JavaScript, and it's not necessarily the optimized way to do certain types of things. CSS has got an engine that's closer to the metal that's probably going to do things a lot better than we can.

Yes, but that doesn't mean that just because you put it in CSS, everything's going to be wonderful. You're going to have problems if you put it in CSS just as much as if you do it in JavaScript, potentially. And it's finding that balance. Sometimes it's like, yeah, I just want to do this quick and easy dirty thing, and it's easier in JavaScript. I can do it in one line in JavaScript, or I can do it in six lines with CSS, and it's harder to read and understand. What's going to be the easier one to maintain? The one line of JavaScript, potentially.

And as long as the user doesn't have any visual notice, who cares if it's in CSS or JavaScript? When you do it, it's what's easier for you to maintain long term.

00:35:12 - Anthony Campolo

You mentioned accessibility a little bit back there, and you actually wear a shirt that says accessible right now. Accessible something. I can't see the rest of it. I'd be curious how you think about that within the bounds of this library. Are you trying to build in accessible conventions, or are you trying to say we're not handling accessibility and that's still up to the developer? How does that come into the picture here?

00:35:33 - Travis Waith-Mair

Generally, I try to create as many hooks to make developers do the right thing as possible, but that was something I learned when I became the tech lead of the design system. You can't control developers. They're going to use your library the wrong way, potentially, and you can't control that.

00:35:49 - Anthony Campolo

Chris, though, is all about that.

00:35:50 - Travis Waith-Mair

Early versions of our design system, when I was at R1, we tried to lock down the class name. We tried to lock down all these kinds of things so that way they couldn't mess with the styles. And then nobody could get any work done because everybody had that one-off situation where they needed to do it. And developers who were really smart found ways to still do the wrong thing if they really wanted to. They just had to go about it in a much more difficult way.

And so I kind of learned that just make the path to the right way the easiest path and then just hope for the best. So, yeah, it is important, but what I've embraced then is I'm just going to make the as prop available because, with styled-components, people can change the actual element under the hood so it's the correct semantic element.

And other than that, if they're going to create a clickable div, they were probably going to do that anyway. And my library wasn't going to make that any easier for them.

00:36:43 - Anthony Campolo

As we start closing out here, we'd be really curious: are you looking for contributors? If someone wants to contribute, how should they go about doing that?

00:36:51 - Travis Waith-Mair

100%. I'm trying to get better about putting all my issues out in the issue backlog that I want to get done. I think there's four or five there right now, and putting the hey, I want help on this, out there. But yeah, 100%, I take contributors.

The Reel component actually was originally a PR where someone said, hey, this is a component I've done before. And I kind of moved it, morphed it, to how Bedrock would think about a Reel component. It's different than that original PR, but yeah, if there's a use case, a layout use case, that you think is common enough that you use all the time but isn't covered by Bedrock, I would love for people to propose things.

And so, yeah, if you want to contribute, you can do that on GitHub at Bedrock. It's under a different organization. So it's bedrock slash bedrock layout, I believe. I should know my own GitHub probably off the top of my head.

00:37:41 - Anthony Campolo

We'll place that in the show notes. Where should people get in touch with you? What's your Twitter or anywhere else that people can get ahold of you?

00:37:48 - Travis Waith-Mair

I'm on Twitter. It's Travis Waymire in CamelCase: Travis, and then W and M are uppercase. Or if you go to the React Podcast Discord server, that's where Anthony and I met. I'm there every day. Probably between those two, that's the best way to get ahold of me.

00:38:04 - Anthony Campolo

Yeah, it's addictive. I spend a lot of time there, too. And as you say, that's how we got to know each other. So it's been great getting to hang out there and get to chat about this stuff.

I've been kind of looking over your docs as you've been going. I've given you some notes on them, so I am almost a contributor. Don't technically have PRs yet, but I'm kind of a semi-contributor at this point.

00:38:23 - Travis Waith-Mair

If I could find a way to put your face on there, I'll do it. But that requires more than just an automated badge.

00:38:30 - Anthony Campolo

Totally. Yeah. But thank you so much for being here. Thank you for listening to the show as well. We're always happy to meet our listeners and give them a chance to get on here and talk about what they're doing. So anyone else who just listens to the show and wants to talk about what they're doing, feel free to reach out. I think that about wraps it up for today's show. So thank you so much, Travis, for being here with us.

00:38:50 - Travis Waith-Mair

Happy to. Thanks for inviting me.

00:39:21 - Christopher Burns

Will you be having any October issues and potential pull requests, as it is that time of year?

00:39:27 - Travis Waith-Mair

That's a good question. I have not thought about it. I've been knee-deep in moving from Utah to Houston for the last month, and I have been basically just updating dependencies. And that's about it for this library for the entire month.

00:39:41 - Anthony Campolo

Yeah, I won't worry about this episode. It's going to air after October anyway, so don't even trip.

00:39:46 - Christopher Burns

Oh, it's after October.

00:39:48 - Anthony Campolo

Yeah, October is over. What are you guys talking about? October already happened, Chris.

00:39:52 - Christopher Burns

Yeah, you should have said that sooner. What's the plan for Christmas?

00:39:55 - Travis Waith-Mair

I'll see what I can do. What's planned for Christmas? We're going to have a Christmas-themed website. It's all going to be red and green.