https://www.frontendhappyhour.com/static/js/1845.709311f6.chunk.js

1(self.webpackChunkfront_end_happy_hour=self.webpackChunkfront_end_happy_hour||[]).push([[1845],{1845:e=>{e.exports=function(){return"\n  \n\n  <p><strong>Ryan Burgess</strong><br /> \n  Well, welcome to another episode of the front end happier podcast. In this episode, we're joined by Brad frost to talk with us about CSS, and how to build out CSS in large applications. Brad, do you want to give us a brief introduction of who you are, what you do, and what your favorite happier beverages?\n  \n  </p>\n  <p><strong>Brad Frost</strong><br />\n  Yeah. Hi, thanks for having me. My name is Brad Frost. I'm a web designer based in Pittsburgh, Pennsylvania. I do a lot of what I call like front of the front end, web development as well as a lot of consulting and speaking in workshops and stuff like that spend a lot of time on design systems and created something called the atomic design as far as happy hour drinks. I'm very much a beer person, hard alcohol and soda tails and stuff on like, the occasional gin and tonic maybe I guess or Margarita, sort of locale specific. I feel like my my beverage changes like on on geography but if I'm at home, I'm drinking beer. And when I'm out I'm usually drinking beer and right now I'm drinking a beer called squish by a Pittsburgh based brewery called Sunderland's which is right up the road for me so that's my my way of getting out and about in my in my home city. Well what\n  \n  </p>\n  <p><strong>Ryan Burgess</strong><br /> \n  I was gonna say it's nice that they still are open to because I have a local brewery that's right beside me as well. And I'm like really happy that it is open and I can still buy beer there. So I'm and it's really good. So it's a win win.\n  \n  </p>\n  <p><strong>Brad Frost</strong><br />\n  Yeah, I actually I literally have a brewery in my backyard. And and so it walks over as they're sort of breathing the air and stuff at a height. Don't Don't tell them but I don't prefer them\n  \n  to go outside they're really lovely neighbors and I like talking to them but I their beers apartment\n  \n  </p>\n  <p><strong>Ryan Burgess</strong><br /> \n  anyways, brother. That's funny because in my backyard I literally faces or the brewery as well and I'll smell the hops and everything. Luckily I do. I do really like their beer so it works out. There we go. All right, well, let's give introduction of today's panelists. Mars, you want to kick it off?\n  \n  </p>\n  <p><strong>Mars Jullian</strong><br /> \n  Sure. I'm Mars Julian. I'm a front end software engineer in the Bay Area and all thoughts of my own.\n  \n  </p>\n  <p><strong>Stacy London</strong><br /> \n  I'm Stacy Linden. I'm a senior front end engineer at Atlassian and all my thoughts are Mars's\n  \n  </p>\n  <p><strong>Augustus Yuan</strong><br /> \n  there? Yeah, there you go. Yeah. My name is Hugo soon. I'm a software engineer at Twitch. And I just have thoughts.\n  \n  </p>\n  <p><strong>Ryan Burgess</strong><br /> \n  And I'm Ryan Burgess. I'm a software engineering manager at Netflix. I don't have too many thoughts on this whole thing. Yeah. I mean, I just thought questions you all respond right? That is not that big. All right in each episode of the front end happier podcast, we'd like to choose a keyword that if it's mentioned at all in the episode, we all take a drink. What did we decide today's keyword is atomic, atomic. So if we say the word atomic at all, in this episode, we will all take a drink. And the reason we chose atomic is if you have not read atomic design by Brad frost, I highly recommend it. It is a lot of what we're going to be talking about in this episode. But it paints a really good picture of how to really build out your CSS in larger applications. First time I met Brad actually was at Netflix, we had him come and help us think through how we were going to scale our CSS or how to build a mobile first and this is many years ago, which is crazy. It doesn't feel like that long ago, but it was I highly recommended. It's a really quick read to but just very insightful. I'll also say that if\n  \n  </p>\n  <p><strong>Brad Frost</strong><br />\n  If you buy it, it's $10 right now, and actually, since this whole pandemic kicked off, I'm donating 100% of the proceeds to food banks and helping keep people fed during all this. So, so that's been pretty cool. I've it's been like, a little bit of wholesale resurgence with the book isn't exactly hot off the presses, but at the same time, it's, it's, it's great to see a lot of people saying, Yeah, sure. I like helping feed people. So awe

1some.\n  \n  </p>\n  <p><strong>Ryan Burgess</strong><br /> \n  It's adding atomic help to people. Cheers. All right. To get started, I thought a really good way to start this episode was I feel like we've all come at CSS likely at different points, starting our careers. And I'm interested to hear each of your history with CSS and how it's evolved over time.\n  \n  </p>\n  <p><strong>Mars Jullian</strong><br /> \n  I mean, I think my experience with CSS like has largely followed like the the way that the industry has been tracking, just because like going from company to company, they also tend to track the, the way that the industry is moving. So obviously it started out as like an intern working with jQuery and terrible inline styles in some places and you know, CSS style sheets and kind of just like a mess of class names and then moving to like, post processors like sass and less and now more more experimenting with like CSS and JS frameworks, like CSS modules, and, you know, reactive styles and that kind of thing. So it sort of just like been like, you know, ebbing and flowing between things that are less CSS and things that are more CSS two, I don't think we've ever really settled on like a middle ground yet was my experience, but sort of just been tracking that way.\n  \n  </p>\n  <p><strong>Stacy London</strong><br /> \n  similar sort of experiences while Yeah, from kind of early days of not thinking of CSS is something that could have architecture or patterns, to moving towards that kind of And like, you know, reading Jonathan snicks book about scalable modular CSS architecture that like, changed how I thought about things when writing CSS and then starting to think about it even more programmatically with say, like, less and preprocessors. And that's sort of a part of that evolution. And then fast forward. Now I'm, like, you know, in the CSS and JS thing I've been, you know, working with style components, or emotion or some of these libraries that let you write CSS and JavaScript. And so it's, it's been quite a journey to see how its how its evolved and then kind of almost seeing it fall back. So like even recently on a team ima or was on they are considering ripping out the CSS and JS because it has performance problems and going back to maybe vanilla CSS, or maybe less, you know, so it's kind of like full circle kind of things happening which is always which which, if you're in the industry long enough, you You kind of see everything go in a big circle.\n  \n  </p>\n  <p><strong>Ryan Burgess</strong><br /> \n  It always brings me back to like, I love that you said that because like I remember the back when I first started probably doing some JavaScript, it was like, you were putting like on click handlers in your HTML, and it was just like, really gross. And, and then I remember being at the presentation when Facebook introduced the act and, and showing JSX. And I was like, nope, don't like that. That's really, really ugly. And then you start writing react, you're like, Ooh, I like this, like, but it's like, wait, I hated it. Like when it was in line. So it's really funny how we move around like\n  \n  </p>\n  <p><strong>Augustus Yuan</strong><br /> \n  that. I love how you called that out, because, yeah, there's like the first react presentation. There's this like, pivotal slide where they showed, and this is how we envision CSS would work with react. And I I remember a bunch of us I forgot, like on our team, just like close the close the video right there. We were like, well, this is a\n  \n  </p>\n  <p><strong>Ryan Burgess</strong><br /> \n  terrible idea. Don't\n  \n  </p>\n  <p><strong>Augustus Yuan</strong><br /> \n  never work, you know, prove me wrong a little. So I guess I'll go I feel I learned a lot of my CSS from Ryan. When I joined Evernote. I started. Like, well, for context, like my first web development job was at college, I was a senior web dev for the College of Engineering and colleges. I would say the tech is probably not as modernized, so there's still a lot of writing manual CSS, and then coming to ever know learning about SAS, like my mind was like, blown. I was like, Oh, my God, like even just like mistake was like, just like blew my mind. But yeah, it's crazy to see how like, CSS has evolved.\n  \n  </p>\n  <p><strong>Brad Frost</strong><br />\n  Yeah, really has. So I'm not sure I won't count my geo cities experience who, but that's, that's, I mean, that's is that was sort of straddling the line between like, just straight up like font at HTML attributes and and like starting Like nascent CSS sort of stuff, like, largely for like background, you the old tiled background for Dragonball Z Fan Fan with fan websites. And But yeah, I got into CSS, I had a class at my university learned a bit of that, at that time, it was still largely like flash days. So like, a lot of that stuff was like, super expressive and just easy, you know, you're just like, I'm gonna make my interface a bunch of bouncing balls, and like, I could do that. And it's like, how does this work in the browser doesn't matter. You know? It's just like a box. You know, it's like a box that shows up eventually in the browser. But yeah, my story is a bit like, a couple of weeks before I graduated, a couple alumni came in. They worked at AOL, which was, you know, at the time was was, you know, pretty hot job a couple weeks before they came in, they were like, you know, if you're in Interested in all this web development stuff, I'd recommend buying this book designing with web standards by Jeffrey zeldman. I graduated, sat unemployed in my sister's apartment in Pittsburgh and read that and it was like, oh, okay, so like everything I just learned as part of my degrees wrong. And then sort of quickly after that, read Eric Myers, to Eric Meyer books on CSS, and sort of that began my, my path of sort of solid standards based HTML, CSS separation concerns, good stuff. And then sort of like you all, you know, sounds like a similar trajectory and through the jQuery days, and then through the, you know, preprocessor days and then like, you know, getting into these sort of more modern frameworks and, you know, sort of, but but we'll say largely sticking With and I'm sure we'll get into it, but like, largely extolling the virtues of native CSS as not some antiquated thing, but as one third of the important technology stack of the front end web. So sort of really trying to help advocate for Continuing from, I think, where I started, which is the standards based approach to web development, and the tools come and go and things like that. But it's like, you know, how do you actually craft this stuff in a way that that scales that's modular, that's portable, that will stand the test of time. And I think that that as time goes on, and a lot of my work as I sort of duck my head into all of the different organizations have of similar size and shape of the places that you all work and stuff, and to sort of see this sort of graveyard or do you just sort of see like the timelines you see this like sort of things frozen and Amber's Jurassic Park style and it's like, it's really, it gives you an interesting perspective on sort of what last and what doesn't what's solid and what does it what's flavor of the month and what's actually like, it's like, okay, that's a pattern we're gonna want to hang on to for a while. And it's, it's very, very interesting to sort of see how that evolves and the implementation sort of kind of matters, but really n

1ot too much in the grand scheme of things. So it's like, my, my big thing is about like the what's, what's the rendered output? And like, how, how is that going to hold up over time? And I feel like 778 ish years into I don't want to say I've cracked the code, but I feel like I've established and a lot of the projects that I've worked on in a lot of places have gone. And we've established like similar things and done some pretty pretty, you know, we'll say ambitious things. And it's like, some of these patterns hold up pretty well over time, which, which actually makes me makes me happy.\n  \n  You know, do you all have that like where you're like, yeah, this is, this is a trick I've been doing for a while. And like this, it, I'm doing it for a while, not because I'm like an old, you know, old dog and can't learn new tricks. It's like, no, this thing freaking works. And that's, that's a sort of another thing. I'm rambling here, but it's like, stable software, predictable patterns, things that you could really hang your hat on. Give me that all day. So\n  \n  </p>\n  <p><strong>Ryan Burgess</strong><br /> \n  yeah, at that point, it doesn't matter so much about the technology or approach that you're doing but is writing vanilla CSS or writing sass less. It's like those types of tooling come and go. But I think that's why I still think things like atomic design Hold up, because it doesn't really have\n  \n  </p>\n  <p><strong>Stacy London</strong><br /> \n  Cheers.\n  \n  </p>\n  <p><strong>Ryan Burgess</strong><br /> \n  Cheers. But yeah, I think really setting those patterns, it shouldn't really matter about necessarily what the tools are when you set a good pattern. It should work on all that for me. Yeah, I sounds very similar to Brad mentioning flash. I'm like, yep, that's definitely where I started CSS. Really? You just like centered the flash?\n  \n  </p>\n  <p><strong>Brad Frost</strong><br />\n  Yeah, the flash object. Yeah,\n  \n  </p>\n  <p><strong>Ryan Burgess</strong><br /> \n  the flash object was there and that that's all that matters. You're like, boom, done.\n  \n  </p>\n  <p><strong>Brad Frost</strong><br />\n  And then if if you really wanted to be like ambitious, you would sort of have like, a background image that you carved out in Photoshop that like sort of created like a gradient so that the flash object would like seamlessly blend into the body\n  \n  </p>\n  <p><strong>Ryan Burgess</strong><br /> \n  background, except it never worked. I mean, it works. But you always have that person who had didn't stall and so it's just a big gray box like and they're like installed but so afterwards seamless, great. See, I started there writing a lot of just vanilla CSS, I remember even at times where we would try and reduce the sounds funny to say, but we would try and reduce the size of the actual file that was getting sent to the client. And we weren't using great build tools to do that. We were just actually writing our CSS all in like large line ad and like, that would happen.\n  \n  </p>\n  <p><strong>Brad Frost</strong><br />\n  We did that. Yeah, absolutely. \n  \n  </p>\n  <p><strong>Ryan Burgess</strong><br /> \n  It sounds so bizarre to even say it. But that literally happened. Maybe it was that every class had its own line. It wasn't like all like one massive line. But even then, why am I putting all these properties in a single line. And then I remember moving to, I can't remember which preprocessor I moved to first I think it was less and then sass, and I've jumped around on those and played around CSS and JavaScript. But I remember being pretty adverse or just not wanting to do or using a pre processor. I remember being like, that seems like a bad idea. My fear was was just thinking that you didn't really know what the end state was at the CSS. But I think once you really understood how to write less or sass, you could be pretty confident what the end state was. But I do remember first hearing about I'm like, that sounds like a terrible idea. I want to write my my CSS line by line. You know, I got to see it. But I think it comes back to his patterns is the key thing, though. That's tend to just stay, they really stay the long term. Doesn't matter which technology are you using for CSS? I'm interested to hear are there layouts that you still find hard to achieve? Even with Flexbox or grid?\n  \n  </p>\n  <p><strong>Brad Frost</strong><br />\n  Yeah.\n  \n  All of them. I think now, I think I think here's the big conundrum right now, the big conundrum is not necessarily in the How do you implement this in the browser because you actually can get that the biggest problem is the disconnect. between how a designer views layout and how it actually plays out in the browser. And what I mean by that is, designers put the little like pink lines over top of their designs and you're like, which are next to worthless? A lot of times they're like, never even lined up in the first. It's like, why are you doing that at all? I don't know. You're just like, Look, and we have a grid and check. The problem with that, though, is that that isn't at present, how things work in the browser, right? And so there's a big sort of educational aspect of this and actually for project I'm working right now, we had that very conversation just yesterday, where I was like, gather around everyone. Let me show you how layout works on the web, at present. And for a lot of designers. It's like, Oh, okay. And there's a couple things here. One is this whole the the little Pink lines with the 12 column grid and the gaps in between them and stuff like that. We have 

1CSS Grid. That's not what CSS Grid is, for one, like so. So there's like a big disconnect there. It's I guess CSS Grid is here. So we get like the little like pink lines in in CSS. Now, we don't. Not presently, there's sub with the introduction of sub grid, which is only available right now at present. in Firefox, you have the ability to declare a grid, and then sort of snap children and their importantly, their sub children there. They're sort of like elements. So if you just let's take a product D product category page for an e commerce site, right, you just have grid of products, three across or something like that, right? What you want to have is you want to have a master grid, and then you want to sort of snap the cards to those grids, right? So it was like 12 column grid. It's like okay, got, you know, three and three and three in the gap in between and makes a nice little thing. Or maybe four across, I don't know, I have my math wrong. So the whole idea there is that you would have to declare that grid a, a, you know, display grid, and then sort of add your sort of like grid template columns and stuff like do that there. You can't have like a page level higher up, I'm just going to like, here's the master grid for the whole body. And then like, I'm going to snap these things in the header to the grid. And this way, I'm going to snap these cards to the master grid in this way. Can't do that right now. So it's all these like direct children kind of things, right? And so that's like a big like, oh, and sub grid solves that. And that's like a really tough stuff to solve. And there's a reason why it didn't make it into the original spec and stuff like that. So anyways, that's the problem. The problem isn't like I can't make the Holy Grail. layout or I can't make a three column layout or you know, this thing going from one columns to two to three or whatever, like, you could do that. And what we tend to do is we'll sort of define these patterns that that are like, here's a side by side, or here's what we'll call like a two up, or a three up or a four up, and it basically goes from one to two to three to four, right? And like or not, and then you have variants of that, which is a one to two to four. And so it's like, Okay, that's good for like marketing homepages where you say, like have four talents. But you don't want a little orphan right on this on the line, like at a certain thing. So we'll have these sort of like general sort of like grid like layout patterns. And then we'll have some overarching sort of page layouts and generally like, they'll end up being the same shape as those sketch files or figma files or whatever. But like, how they're implemented is just fundamentally different than like how people think about grids. So that that's the big thing. And sure there's masonry stuff and like actually, Rachel Andrew just had a really good post on that this week where she's like, starting to like kick the tires about that and, and whatever. And that's one of those like, is that just like a passing fad? Or is this like a, something like that we want to hang on to like long term and in who knows about that. But I'll say like, the big thing is like the just the mental model for how we even think about layout is still radically different between these different disciplines.\n  \n  </p>\n  <p><strong>Ryan Burgess</strong><br /> \n  Well put, I always think of that, too, is that there's always this translation I think about is like you have this really beautiful design. You sit down, you build it, and you sit down with a designer, they're like, it's not exactly the way I designed it. And it a lot of it comes down to that grid. It is not easy to just translate. And I think that's the thing for me that I've always struggled with it. I do actually think we've gotten better over the years where the browser's have gotten a lot better. I think back to the vertical lines floats all the things that were just so, so difficult. There's times when I was just like, hey, it works. How does it work? I don't know. It just works. Like I figured it out. It works. And you just feel so good about that in that moment. But again,\n  \n  </p>\n  <p><strong>Brad Frost</strong><br />\n  that like one, like, you know, even pre pre media queries and stuff, it's like you had the same pattern. This three across, I want to display these things in three columns. God, we've been doing that for literally like deck. It's like, half float\n  \n  </p>\n  <p><strong>Ryan Burgess</strong><br /> \n  left and float. Right. Yeah. Done. \n  \n  </p>\n  <p><strong>Brad Frost</strong><br />\n  Exactly. What's that? What's some like weird margins and stuff in between there. And then, like, Ethan came out with responsive design. And he's like, and here's this mathematical formula for calculating these things so that they're flexible. And it's like, you know, my margin right is 2.125%. And you're, I'm just like, nah. Well, yeah, we've we've come a long way between How to obviously see all of CSS Grid, all of Flexbox. Cow is huge, just like the notion of like gap like just burying things. In this. I'm going to control the spacing in between things. And we actually have a freaking convention for that that isn't a hack is is wonderful. But yeah, like these paradigm shifts and like these, these mental models are, you know, so much of my work over the last six, seven years has been around design systems and bringing a lot of these different worlds together. And I sort of am like the person typically who is like that Ambassador for front end technology. And it's like, here's, it is very much an educational thing. I'll say, the whole like, here's layout patterns and how it works. And then the other giant paradigm thing or thing that just isn't even a thought in designer's head is this concept of source order. And whenever you have the sort of static design tools pages, move things around free space

1s on mobile, it's good to put it down here and we're gonna put it up there. And then like the problem is, is that developers are just such like schlubs and don't push back on anything. They end up like doing these like massive backflips like these like Cirque du solei backflips like just these technical solutions to if you just said, If you move it from here to here, I could do this in two hours. But the way you have it is take me two weeks to do it's just it's incredible. So I love seeing that stuff. So it's like layout patterns and source order are like for me like the two biggest like disconnects between the worlds of design and front end development and I personally love playing that. playing that game and and helping educate people there. I think you touched on something that is so good anytime For engineers, specifically is just taking the time to question but also educate. Because sometimes a designer is just like, Oh, I just thought it was easy. Versus like, let's help someone understand that order and how that happens. You can't just throw JavaScript at everything and just say, like, Oh, I'm just going to reorder everything you can. But that comes at a large, large cost to the end user. And so I think a lot of the advice I always say is just having those conversations and helping educate that you don't want to just take what the design is or the spec, and just completely take it and build it. It's it's a conversation that has to happen between design and engineering. So I think that's really good advice. Those conversations don't happen. And and that's, that's so much of my, that's the drum that I beat and and basically like talking about front end developers, and I'll say like, specifically the front of the front end Now that front end developers a worthless term and it's like, you know, he\n  \n  you need the people that really understand how CSS works to be an equal in the design process, not coming in after not sort of treated as just like here implement this is like, what people whose skill set is fundamentally understanding CSS is these are the people that understand the medium of the web better than better than any other person in the team. And that's not to sort of say like, yeah, like, like, let's pat ourselves on the back here. What it is saying is, too often our processes are built around, you know, these designers are going to come up with the solutions, and then we're going to pass it off as in the form of requirements and some stupid zeplin link to these sort of grunts who are just going to sort of turn it into code. It's like, feed them requires And they spit out code on the other end. And that's just fundamentally like, it's disrespectful across the board. But it's also it's just wasteful, it causes all sorts of problems. And I'll also say, you know, we're sort of, not to not to bring a react up into this, but it's like, with react, you can conditionally render different things. And I'd say, Oh, crap, like, that's not like, that's not like, it's not specific to react. But this general notion of like, you know, if breakpoint is is mobile, then like, rendered in accordion else, render tabs, and it's like, that's maybe not a good thing. Like the fact that we can do this from a technical perspective means that like, those engineers will actually just go Okay, well, I need to add an FL statement here. Rather than going hang on this is fundamentally a bad idea. And we should actually, this is a better way and like, here's how we can accomplish this. You CSS Grid and like, let me just like walk you through that, right? So it's like, it's almost a shame that the technology has gotten better to actually create, essentially an M dot site. In the same code base, it's like, it's like cuz then these people are just sort of crapping out these really brittle and just just, it's just not good. And, and there is something to be said for optimizing, you know, a layout. But there's also something to be said for, let's actually like use work with the grain of the web, rather than like just sort of hacking around it with like FL\n  \n  </p>\n  <p><strong>Ryan Burgess</strong><br /> \n  statements. I know it came up earlier to I think a few people, even Mars, you'd said, talking about the ways that you've come along CSS. We mentioned a few things about how we felt about CSS being in JavaScript, but I'm curious, like, what do you all think about CSS now being in y

1our JavaScript? I\n  \n  </p>\n  <p><strong>Mars Jullian</strong><br /> \n  have lots of thoughts around this only because at work we've been we have like a web styling working group. So we've been reevaluate. We do CSS and JavaScript now. And we've been really evaluating the framework that we use for it, I have to say, I really liked the ergonomics of it. And I like some of the problems that it solves in terms of like the cascade and like, we can now have locally scoped selectors, so that we can make sure that we have these like really, atomic. \n  \n  </p>\n  <p><strong>All</strong><br />  \n  Cheers, cheers.\n  \n  </p>\n  <p><strong>Brad Frost</strong><br />\n  Cheers. This is a terrible keyword.\n  \n  </p>\n  <p><strong>Mars Jullian</strong><br /> \n  Really, like really small components that we can then like, you know, sort of like compose together and build the larger parts of the UI without having to worry about, you know, some of that styling, bleeding into other places and changing names in the maintainability of that. So I think there is there are some positives to CSS and JavaScript, but we really lose out on some of the performance benefits, too. I think we're like bending over backwards for the developer ergonomics, but now it feels like we're also bending over backwards in the other direction to, like extract CSS from our react with styles. So we maintain CSS and JavaScript to statically compile it to something else. So it's been really interesting to like research all of the available frameworks out there for like their different performance benefits, developer ergonomics, and just sort of, it's just kind of boggles my mind how much work has gone into it when we have CSS. We have less. But as developers, like, I think, also, we're a little bit stubborn, because, you know, writing CSS and our JavaScript has been really nice. But it also presents a lot of problems. And people don't. It's almost like these frameworks have for you know, developers who don't have like the mental the, like mental patterns. Well thought out, they just kind of like a blanket solution. And we no longer have to architect our CSS because it's back in our JavaScript. So it's a really hard thing to convince our front end community to like think about CSS architecturally again, when it kind of was the solutions like don't do that anymore. I don't know that's not very eloquent. But that's me.\n  \n  </p>\n  <p><strong>Brad Frost</strong><br />\n  That is extraordinarily elegant. Let me just tell you that I was like wonderfully said,\n  \n  </p>\n  <p><strong>Stacy London</strong><br /> \n  Yeah, it was. It's funny Mars, because you mentioned like, Oh, you know, we have this thing where we can like have our cssp, right in New York components and blah, blah, blah. But what's funny is you'll find teams that even that are doing CSS and j s, there'll be like, we define our styled components in the separate file from the component, and then we reference it and import it as like, import star from button dot styles. And then we have the style in there. So you're treating it in very similar way to the way that you kind of separated your concerns before. They're like, Oh, but the ergonomics, it's closer to the component. I'm like, well, you're doing it the same.\n  \n  </p>\n  <p><strong>Brad Frost</strong><br />\n  You could do the same thing with a freaking SASS file.\n  \n  Well, whatever dead code elimination, alright, I delete the folder. We don't use a carousel anymore and we're going to deprecate that. All right, you delete that folder and there goes the CSS for your hair. So So, so many others. The things that the benefits that get bulleted out in the in the slides that I see, like, How bad is your? How bad is your process where if you're just like totally omitting, again, a third of the front end stack of the web from like if you're if you're removing something, and that's not to say that like big long, like single files or CSS files that you can't find anything and all these sort of gobbledygook selectors is is a good experience. But it's like, you're talking about partial. So you're talking Chucky, I'm gonna write my carousel component styles in this file. And if the carousel goes away, it goes away. Like there's nothing about Java, that JavaScript shouldn't even enter that c

1onversation and my in my opinion, if you're talking about that as like a benefit, I think\n  \n  </p>\n  <p><strong>Ryan Burgess</strong><br /> \n  that's even solved more even on like a bill level. You could Building a tool that does any could be written in JavaScript, I don't care. But like it's more on the build level tool is it doesn't need to be at runtime, it doesn't need to be this coordination tax is that you could build man line tool that's like build new component A and it builds a CSS file or a sass or less, you know, it's just automatically creates out alongside the JavaScript file, like there's, and then you can have a cleanup command that cleans that all up, like I agree with you is like, okay, that is an argument that it's together and you just throw it away, and that's fine. But there are other ways to solve that problem, too. So I I don't think it's a great argument.\n  \n  </p>\n  <p><strong>Brad Frost</strong><br />\n  I think what you're bringing up is a really important point is the fact that like, tooling, and linting, and like all of that stuff is all has all grown up in the same timeframe. where it's like, if you were to say that same sentence that you just said seven years ago, it'd be like, it would be nice to have some like cleanup tools and builds and Whatever. And now it's like actually just like trivial. So it's, it's important to recognize that like, as we like, zoom out, it's like, yeah, we we've come a long way maybe. Okay, with respect to the the tooling and just like sort of the guardrails around like so many things, irrespective of the technologies are the specific, like implementations. It's like, you do have these sort of, like, extra constructs that just didn't exist before. It used to just be. Yeah, we have our single file for all of our CSS and like we, we only append to it we never dare go back into further up the file because there be dragons. Right. And we don't know where that is. It's like those days are gone, and largely because of a lot of this sort of tolling stuff. So, so yeah, and that that doesn't, that's not CSS specific. That's just like we have better conventions and constructs and pools around sort of like shaking out things that are dead or whatever. So that's, I think, I think that's that's really powerful and really fun.\n  \n  </p>\n  <p><strong>Mars Jullian</strong><br /> \n  I think like thinking about the evolution of CSS and like going all the way towards CSS and j. s. I like still not as like, much as I have my gripes around preprocessors and CSS and js. I don't think that I could imagine a world developing without them. So because they do give us like a lot of nice things especially like practical stuff beyond the developer ergonomics, like it allows us to style our websites more inclusively. So we can have like auto vendor prefixing. So that we have styles that work across browsers, or we also have stuff that can do automatically. RTL flipping for, you know, various CSS properties that need it like text align, right versus text align left, depending on on the locale of your browser and that kind of thing. And I've even seen more like more and more stuff come out these days around just like injecting like more accessible styling. into like, less than sass and all that kind of stuff. But we couldn't get with with native CSS, or just pure CSS. It's really interesting to see that\n  \n  </p>\n  <p><strong>Brad Frost</strong><br />\n  it's a weird thing. Again, it's like, what I see that a lot is like JavaScript developers being like, again, the bulleted list for like, here's why CSS in j. s. And whenever I read those like bulleted lists, or the slides or look at those conference talks, or evaluate this stuff, I'm like, these, these simply aren't problems. It's like there are there are ways to address it. And it's like, don't get me wrong. It's like yeah, like, nobody is that no, I'll just be clear. Nobody is advocating creating style dot CSS anymore. And like writing all of your styles there and having no access to variables are no access to like nothing. Nobody is saying and it Also nobody's really advocating even things like, like, we should write all of our styles like globally that like sort of cascade in there. It's like there's some like really, actually really smart things you could do with a cascade, but it's like a delicate touch. It's like some like, really like lightweight, like base level stuff or whatever that that trickles down. And it's actually really, really nice when you have that your handle around it. So it's like, it's not to say that like, these, these solutions are these frameworks or tools or whatever, just the concept of CSS and j. s is like, was born of anything like wrong, but like what what I think frustrates me is that it seems to ignore a lot of the hard 

1work that that had already sort of come out before to address exactly that. Just Just to use the the crudest example that we talked about earlier is like you have carousel dot SCSS. That's like okay, there. You go, you know what I mean? Like, it's what was what was wrong with that? Exactly. And it's, it's a carousel. So\n  \n  </p>\n  <p><strong>Ryan Burgess</strong><br /> \n  there's something wrong with it. But\n  \n  </p>\n  <p><strong>Brad Frost</strong><br />\n  absolutely, yeah. And that's, that's a fun. I brought that up earlier as an example, because I was saying that we were removing it. So it's like, that's always my go to it's like, you have to do your design system. And let's say your AB test shows that carousels suck and you shouldn't use them. That's a good candidate to remove that component from your from your library eventually, right. So but yeah, so carousel, maybe maybe a bad example. But like the notion, the notion of of partial is, is there. And the notion of sort of scoping components and stuff like that is also like a, I think a big one that gets sort of like extolled around a lot. If I may. I think the big thing is for me, hands down, hands down. The biggest argument against CSS and j. s is portability. And I would venture to guess that every single one of us on our call, if we were to add up the different tech stacks at our various companies and organizations, would probably be a couple dozen. We probably between us have a couple of dozen tech stacks in play. Some of those might be react. Some of those might be Angular, some of those might be Django or WordPress, or Drupal or whatever. SharePoint, I don't care. The whole idea and this happens, every single client this week was no exception than last week. And I'm not not making this up. It's these buttons look this way. Because this was built in Angular. Angular is a JavaScript framework. I'm sure you all know that better than I do. Angular should have no bearing on the presentation of these buttons, styles, but yet here we are. These Look like this because this was built in this framework. These things look like this because they were built in this framework. There is the problem. Fundamentally, if I want to get the new design language, our new you know, three Dotto design language, whatever, like the designers are cooking up with 

1new purple buttons. And all of this just went through this with like a big airline and stuff. If in order to get those purple buttons into our entire enterprise means you have to refactor your entire application to use react. Forget about it, forget about it, you're done. So here you have this notion of it's like, what if we can have our our design system and have our partials as like a SAS file? And what that does is that kicks out a design system name dot, min dot CSS file or whatever that we Chuck on disk. CDN so that our SharePoint consumers and our WordPress site or whatever, all they have to do is match the class names and they get the purple buttons. And the React app gets the fancy CSS modules version of that or like, whatever, it doesn't matter. I don't, who cares how that actually sort of plays out? There you go. So so so for me, the portability thing of it's like, let's suck everything into this sort of CSS in JSX is like, it's, it's so like, I'm putting on my horse blinders. I don't care about what any other team across our companies doing, or what tech stacks they're doing. If they're writing PHP, then like, have fun in the 90s or whatever it's like and you could like, try to like belittle that stuff, but it's like, that's just the reality of a lot of a lot of places, not just even the software that your company owns, vendors, you're working with all this stuff. So bringing this back is like working What we're talking about, ultimately, is making a freaking button purple. Why in the world are we wrapping this sort of like, you know, universe brain kind of thinking around it?\n  \n  And grant and grant?\n  \n  </p>\n  <p><strong>Ryan Burgess</strong><br /> \n  Yeah, you've hit it really well, in the sense, a lot of things that we do. You know, I like what you said, the front end of the of the front end. It's like front end is now even obstructed more and more. But we've separated concerns on the back end, where you know, you're not trying to come combine your back end language with your HTML and putting all the CSS together. It's like, you can now say that your CSS is separate. You can migrate from Angular one to Angular two or to react if you want, or view whatever framework you want. You could rewrite the CSS completely. Sometimes you might want to do all of it at once, but you could say I'm cheating is going to migrate, react, I'm just going to migrate, you know, the the JavaScript framework language, the HTML output, as long as the classes are the same, you're still going to look the same to the user, the end state user, you can rewrite that CSS to down the line, you know, rewrite the class and everything. But you can change the underlying technology and your CSS is still left pretty\n  \n  </p>\n  <p><strong>Brad Frost</strong><br />\n  good. Here's the big trick to it all the class names NPM. Library, class names, it just builds an object, it just builds a string, and you basically go button, and then you say, button, dash dash large equals size equals large. So you just map like the API to your react component or whatever to a class name. And what it does is just depends that if that thing returns true, then it just tracks that it just as that on. So the ergonomics of it, in my opinion are just like trivial. It's like You can do the equivalent of like inline styling everything and having a bunch of FL statements in the middle of your of your JavaScript. Or in the middle of your CSS file. It's like having a bunch of like logic. Or you could like have what I feel is like a really trivial abstraction of that, which basically just sort of dynamically builds a class name based on whatever conditions you want to check at and that just sort of for me to get like it's just a no brainer it's like you do like a lit like the tiniest bit of like extra legwork and like, yeah, maybe add a couple more characters. Yeah, you still have to like consider class names, I guess in general. But to be able to sort of like in order to do that, you just automatically get this like maximum portability across the board. It's like sure, sign me up.\n  \n  </p>\n  <p><strong>Stacy London</strong><br /> \n  Well, in even if you have an organization where you are you have the luxury of like everything is the Same stack. So like even if your org is like, we have a bunch of apps, they're all react. And we're going to build our design system in react. And we're going to use stock components as an example. Even that can cause problems where, like, let's say, you want to, like upgrade the version of SOC components, or maybe switch out and do it use a different framework. If you don't coordinate, you have to coordinate that then because your design system is inside of every product. So every product and every damn the design system at the same time has to upgrade and make sure that it's all like all working together nicely because I think like subcomponents three and four don't play nice together on the same page, it breaks the whole site or something, oh, there's, oh, there's stuff like that, that can really cause problems and then you end up having to coordinate. So there's overhead to that even if you are on the same, same stack. Yeah.\n  \n  </p>\n  <p><strong>Brad Frost</strong><br />\n  And it's also with standing This is one of my favorite exercises to play with every client that I just say. So what happens two years from now, when everyone is migrating to view? What are you going to do? And it's an it's a hypothetical obviously, it's like I can't predict the future but also it's like okay views hot like everybody like loves view, it's like seems it'd be nice to work with and like, whatever. And I'm sure react is like the the hotness and has been the hotness for a while. But like, at the time jQuery was and at the time, WordPress was and whatever. And it's like, we are a fickle bunch us developer, folks. And so the, the sands of time change things. And so it's just fun to play that game of it's like, what happens when we migrate away from this thing? And and you can either sort of say, we're never going to do that and then you look like a fool. Or you go, Okay, so how would we approach architecture? This thing in such a way that sort of anticipates a future that might involve a new library that hasn't even been conceived yet, or that's being written right this moment in time. So it's like that. That's the sort of thing. I love how you said that where you're like, even if you are standardized, it's not like a short battle. Like, even if you win that argument and like, get real PHP, people like you shouldn't be doing this. Even if you win those arguments, you're still you're still in maybe not like the best place. So before we get into pics, I would love to leave our listeners with a, you know, one piece of advice that you've all thought about when writing CSS,\n  \n  </p>\n  <p><strong>Stacy London</strong><br />

1 \n  I would say, try to always bet on the web platform. So if you're thinking about implementing something, I think this goes to what Brad was talking about before, like having those conversations with designers like, try and always think about the easiest way that you could accomplish something using native as native as possible, so like, Oh, we need this thing to like, hide at this breakpoint, oh, media queries don't work, because it's more of like a component spacing thing. Like, can you do it with a media query, then do that don't do, you know, some JavaScript calculation, because there's cost and overhead to it. And there's always like a trade off of performance. And so it's like, yeah, make sure to have those conversations and and that'll you'll come up with a better a better thing for your, your end users.\n  \n  </p>\n  <p><strong>Ryan Burgess</strong><br /> \n  Yeah, please don't use JavaScript to to reorder things.\n  \n  </p>\n  <p><strong>Brad Frost</strong><br />\n  Sometimes there's no getting around it. But it's like you want those things to be few and far between.\n  \n  </p>\n  <p><strong>Mars Jullian</strong><br /> \n  I really like what Stacey was saying about sort of like thinking more about the your CSS as opposed to JavaScript. And something I've been trying to do more of recently is to just sort of like understand how CSS is working, but understand it better, as well. Language is a really is like a very powerful language to think about, like what you were saying Ryan earlier, sort of like you pick something and he gets it layout you want it to be, you have no idea how you got there. I'll say I'm still very guilty of doing that. So sometimes it takes a lot to be like, Okay, let me step back and think holistically about, like either this one component or the layout of the page and sort of like scrap it and start from scratch and think like top down from larger elements to smaller elements. And sort of just understanding like, how that cascade is happening, what the layout is doing and how it's, you know, sort of flowing down to the smaller elements and just understand the language better. I think someone told me about margin collapsing the other day and I had no idea that that was a thing and I was like, what there is just like so much so technical. It's so much more technical than I was expecting for like this one line of CSS that I had written had this like in effect on you know, the layout as a whole and I was like, I couldn't even I was like, Really good moment, though to like, you know, just take a step back. And sometimes if you're like, too far down the rabbit hole, think about the layout holistically.\n  \n  </p>\n  <p><strong>Augustus Yuan</strong><br /> \n  Yeah, I want to piggyback off of that, because that was essentially what I was gonna try to say. But I didn't know how to say it. But Mars is, I guess, really, really good with words. And I think Brad alluded to this to how, you know, I think for design the real challenge of the mental model of understanding how the browser like renders things I feel if everyone just took some time to understand it. Like, I think it's like crazy how many people don't know like, what the formatting context is or like, or even like the CSS box model like that's like that's those are like very fundamental things of how CSS renders elements, like block level elements versus inline elements like understanding those things I feel like will just make will make the design process it's like a leap forward of magnitudes easier when communicating with engineers wholeheartedly\n  \n  </p>\n  <p><strong>Brad Frost</strong><br />\n  agree I'll, I'll spare you the rant of how there's hundreds of millions of dollars of venture capital and a lot of money preventing that understanding from happening. Because there's a whole swath of tools that are that make their their money and sort of keeping that pretty rudimentary knowledge that I could teach my nieces in an afternoon. Away from away from professional designers who've, who've done this for years and years, but like, haven't ever had to confront the box model, which is like, how the shit that they're designed. Absolutely, like comes to life. It's amazing. absolutely incredible. But yeah, that's a that's the that's the thing. Here's my piece of advice, because defy your standards. Figure out how you're going to do something And get it down and get everyone on the same page, whoever is going to contribute to the thing. The last thing you want to do is have, you know, cuz with CSS or technology in general, it's like there's 100,000 ways you can slice this reacts another great examples. Were on opinionated. So it's like, from component to component. You see, like different c

1onventions in play, you see people going, and it's like, why why personal preferences, this, your personal preference doesn't matter, especially whenever you're talking about, you know, creating stuff with other people. So, you have to do things like, okay,\n  \n  let's say we're using sass and we're going to net some things. Okay, nesting is good to an extent, but we actually want to be really careful about it because you could end up being in a really bad spot, and even just also from an ergonomics thing. from a standpoint, it can end up sort of biting you whenever things get sufficient. Long. So sweating those details and going, here's how we do things. Here's when we nest things. So, and again, I'm fresh on this just with start spinning up a new project, we're like almost a month into the project, working with a client and all of that stuff. We've barely written any code, because we're all getting on the same page and going, we're looking through things we have like, there's bam, there's modified bem, there is some like CSS and j. s stuff, and all of that, and we're going Cool. All right. Let's pretend we're all going to write code together. And I should be able to go anywhere in this code base and not know who wrote that. Right? That is the goal. Right? The goal is for us to write as a team and to sort of all sort of agree to the same to the same conventions, and to really spend the time to do that. And and sort of spend the time to go all right. We're going to nest things. We're going to nest things like media queries, we're going to nest things like hover, we're not going to nest things like elements. And we're not going to nest things like, you know, descendants, right? We're going to sort of kick that on to its own line. And here's how we're going to comment things. And here's one we comment and here's one we don't. And here's the exact convention we're going to do. And it makes you feel like this, like pedantic jerk at first, but by way of just like getting all of this down, as sort of trialing it out a little bit like that. That's what I'm doing this sprint right now, me and my team and a client's team are all sort of like doing a couple components. And we're going to really like just sweat the details of this and just like really sort of make sure that we're all on the same page. Once we do that. We're off to the races the next the next the remainder of the project is us going to be like sort of full full speed ahead. But you don't want to have this full speed ahead. Everybody's going in 17 different directions that ends up, you end up with a rat's nest. So like having that stuff. And again, like the tooling and all of that stuff, you can sort of like, help sort of, like, nudge people in the right direction, or sort of help them do the right thing and like yell at them, if they're sort of breaking standards. It's getting there. It's not perfect. But like that, as far as writing, like, sort of stuff that's going to stand the test of time that like, you know, you fast forward two years, and you're like, Oh, God, what a mess. Well, the reason I was a mess is that you didn't like establish your conventions and stick to them. So and that's, and that's CSS, but that's everything, right? It's like what we're talking about is just writing writing code as a team. spending the time doing that work is is far and away. I think the biggest thing because I would use emotion. I would use style components. I don't I don't care all that much. I mean, like I do, like you know we can we already covered it. But like, at the end of the day, if I was coming into a project or like I got hired to sort of help the team and they're doing things a certain way, guess what I'm not going to do I'm not going to go You know what, I don't like that library, we should burn it down and like replatform over here, I'm going to work with the grain. I'm gonna work with conventions that have already been established, right and sort of help to try to get those to jail even more. So. So yeah, so that's the that's the big thing is like, just whatever you do, like get it down on paper, get it out in like a code guidelines or like README file or whatever and be like, hey, summer intern, here's your here's the first thing you read, before you touch anything. You get in here, understand how this stuff works. And you'll be you'll be just fine.\n  \n  </p>\n  <p><strong>Ryan Burgess</strong><br /> \n  All right. I think that was really great advice, too. To lead us into pics. Let's jump into pics. In each episode, we'd like to share things that we will Want to share with our listeners that are we found interesting, Augustus you want to start it off?\n  \n  </p>\n  <p><strong>Augustus Yuan</strong><br /> \n  Sure.\n  \n  Yeah. So I actually only have one pig, but it's a big pig. I personally feel it's a big pick. And it's a tool called Dino. You can check it out at Dino dot land. So for those of you who aren't familiar, Ryan Dahl, the creator of Node JS, he, he launched this talk a few months ago. And sure that could be my second pick, I guess. There's this YouTube talk of mistakes. I regret in making node j. s. He made a lot of mistakes when making node j. s. And he's been working on this project that today. Well, I don't know 

1when this episode comes out, but he launched something called Dino, which is a secure runtime environment for that supports JavaScript and TypeScript natively outside of the browser. It's built on trust and uses VA and it's honestly like a pretty big deal. It's I think it's Checking out. If you haven't heard about it already. It could be a big deal.\n  \n  </p>\n  <p><strong>Stacy London</strong><br /> \n  All right, I've got three picks. The first one is something Brad wrote, called, this is responsive. And I know you've kind of created that quite some time ago, but I still point people to it quite a lot, because I still feel like even now, we're still having conversations about how, like, Hey, you should make that thing responsive and make it work in different size viewports and screens and and it's, it's still I wouldn't say a problem but I still think that there are a lot of places that are not still not doing it and not understanding the importance of it. So I still find this resource to be really great to share with fellow you know, engineers about like, how do you how do you do it? How do you think about it? Thank you.\n  \n  </p>\n  <p><strong>Brad Frost</strong><br />\n  Good again, it's like the patterns largely hold up like I'd probably revisit like the implementation details and like modernize things to like I think I'm still using the floats, stuff and a lot of that stuff. But it's like that, you know, we talked about it earlier. It's like a three up patterns like, Boy Boy, that's, that's stood the test of time. So,\n  \n  </p>\n  <p><strong>Stacy London</strong><br /> \n  huh.\n  \n  And then the second pick is bread. You actually you mentioned it earlier was the article from Rachel Andrew that just came out about, you know, does masonry belong in CSS Grid, and it's just a good article discussing like current, the current CSS standards process and what what belongs in there and what's the future for for grids should this be a part of it or not? So it's a good one to read. And the final pick is a music pick. It's a it's called a retrospective mix from 1893 to 2019, by a group called the effects their Canadian duo, kind of techno ambient industrial, it's a little harder. So, if you if you enjoy some of my poppier techno picks, this one will be a little bit opposite of that. Pretty, pretty hard, but it's a, it's a, it's a cool, it's a cool selection of all their stuff from for many years and that's on Bandcamp. And I know a lot of artists in this kind of pandemic time. You know, it's nice to support them directly through things like purchasing their their work on Bandcamp.\n  \n  </p>\n  <p><strong>Mars Jullian</strong><br /> \n  I have two picks, as usual, not tech related. The first is called the online town and it's like virtual space where you can have like, multiple conversations between a group of people and you kind of like walk in and out of rooms like you would in real life, I guess. So I thought that was kind of interesting, sort of, like you can gather people but you don't have to like all be awkwardly staring at each other in a zoom call. And the second one is a project here in San Francisco called paper void, which is basically turning all of our boarded up Like cafes and restaurants into murals, and basically taking what is like the void space and turning it into a creative space. So I actually didn't realize this, but what's really cool is they have a map of where all of the artists that have been sort of commissioned to do this, like where are there murals all around the city. Also, because I've been walking around and seeing them and I sometimes can't catch the tags, I don't know who it is, and I want to like go back and figure out so it's kind of nice to see it all plotted on a map and just to see all the different styles of street art that are covering about this\n  \n  </p>\n  <p><strong>Ryan Burgess</strong><br /> \n  rod, what do you have for our listeners picks you'd like to share?\n  \n  </p>\n  <p><strong>Brad Frost</strong><br />\n  I've got a few. I've got a few one industry related. I really like relevant to our discussion, modern CSS dot Dev, modern CSS solution for old CSS problems, as by Stephanie ackles. And like one the design of it is free. Awesome there's like these parallelograms and stuff and like rainbow gradient borders. So just like the design of it is really awesome. But then it's like, just to sort of like read off like some of the stuff is like button styling icon. Butlin style button styling solutions to replace the 12 column grid, CSS only acessible drop down navigation menu, totally custom list styles, pure CSS smooth scroll back to top. It's like it's freaking gray. There was there was like an old site called solve by Flexbox. Which is another one that I like still occasionally referenced, which is like, here's like, these hard things that we we really labored over in the pre Flexbox days and like, here's how to do that stuff effortlessly with Flexbox. So I like I love the spirit of the site. It's like, Hey, here's stuff that we've all labored over and like, here's modern ways of doing that. So, and the design is just really, really cool. We'll say one, it's seals singing seal cast from a rose. And it's the hardest. I've laughed in a really, really, really long time. It's like actual seal sounds, including one that's like, Ah, it's like, like Pitch Perfect. Like the actual, the actual song and like, it made me lose my mind. So and then the last one I have is a site called radio and there's five O's in that and it's called a musical Time Machine. And my favorite thing about it, well, it's a map. So you can click and you could say like, what was like the number one hit in like 1972 in Madagascar? It is like one of the coolest ways I've seen to like browse music, like you're navigating on multiple axes that aren't traditional axes of music, which is like, geography, and time. And so it's like Time Machine plus geography plus music is really really cool. Admittedly, I I've only like poked around on it a little bit, but I should probably just like, have it up permanently and like painted as a tab and just like sort of do all of my music listening through it. But I like for me, it's like, it's one. It's like, the perfect user experience of it's like, here's taking some existing paradigms and things that people are all used to like a Google Maps kind of thing. And mixing that with, with something that's that's quite novel. So I really love that. Hi,\n  \n  </p>\n  <p><strong>Ryan Burgess</strong><br />

1 \n  it's right on. I have two picks. They're both related to our topic today. Both books one, I'm going to just give the plug for atomic design. We can Cheers to that because it's a is a very good book, highly recommend reading it. And then another one that still I would say stands up really well to CSS architecting is smacks. I think that one has always stood out to me just how to write modular CSS and really be strategic about your components. Great. I think both of those books you read both of those, I think you'll rethink how you write CSS. So I highly recommend those both. Brad, before we end the episode. I want to thank you for joining us. It was a pleasure having you. Where can people get in touch with you? I'm sure people have great questions about CSS and your love for atomic design,\n  \n  </p>\n  <p><strong>Brad Frost</strong><br />\n  huh? Yeah, so my site is Brad frost.com. I blog there occasionally, I would like you to be more frequent than it currently is. But But yeah,\n  \n  </p>\n  <p><strong>Ryan Burgess</strong><br /> \n  I have a blog there. And then I am, Brad underscore frost on Twitter. All right, well, and thank you all for listening today's episode. You can find us  <a href=\"https://frontendhappyhour.com\">FrontEndHappyHour.com</a> you can really subscribe to us on whatever you like to listen to podcasts on. Maybe rate us on the podcast catcher that you like. And you can also follow us on Twitter at <a href=\"https://twitter.com/FrontEndHH\">@FrontEndHH</a>. Any last words atomic, atomic\n  </p>\n  <p><strong>All</strong><br />\n  Cheers. Cheers.\n  </p>\n  \n\n  "}}}]);
2//# sourceMappingURL=1845.709311f6.chunk.js.map