Kate: Hello, welcome to PodRocket. With me today is Noel Minchow, our engineer. Welcome back, Noel. Noel : Hello. Yeah, thanks. Kate: And Adam Argyle, Developer Advocate at Google focusing on CSS. Did I butcher that? Adam Argyle: You nailed it. No, it was awesome. Kate: Okay, cool. Thanks for joining us, Adam. Can you start? Yeah. Just tell us a little about yourself and kind of what you're working on. Adam Argyle: Yeah. I am on the Chrome team. I listen to developers and their struggles building front ends in UI. And I relay that back to the developers that work on Chrome, specifically in the PMs. And I also am on the CSS working group where I relay that information there as well. So, I try to be a liaison between where are your pain points and how can CSS remedy them? And I work with sort of both sides of the teams to find these new things. Kate: Wow. Yeah, no small feat for sure. I just have a question right off the rip. So we just talked to Josh Comeau 00:01:17 a couple weeks ago. Maybe it was last week and he was on a podcast. He was talking about how on Twitter, there's kind of a constant drumbeat of CSS sucks. And how do you kind of feel about that? How does that fit? Does that fit into your feedback loop? That sort of stuff. Adam Argyle: Absolutely. So yeah, when I started, I knew that walking into it, I was like... and I've known this for my whole career that people are like, "Ooh, you like CSS. You must not be very good at code. Do you even know what node.js Is?" I'm like, "Seriously. Okay, whatever fools". And I don't know what the community reasoning is. I think that there's just like this general consensus that HTML and CSS aren't programming languages, which to me is ridiculous. You show them to your mom, your mom doesn't know. She says, "That's code. You programmed that, right?" How is that not obvious enough? But then furthermore, I have a show called the CSS Podcast with Una Kravets and we talk about CSS is typed. It's been typed since day one. And it's just a really resilient typed language, which you're not used to writing. Adam Argyle: So maybe you think it's not a language or whatever, but it's full of functions and types, pure functions, all the nine. All these computer science concepts are there in CSS. So recapping, going back to the original question. I like that people struggle with CSS. What's weird is I think it's just okay for everyone to be really vocal about it. No one tells anyone else that TypeScript is hard. Everyone goes, "Oh, TypeScript. I just love it. Everything it's doing for me in my workflow is so good". And meanwhile, they're in the background going, "Oh crap, why are my types working? I extended that thing and now it's all doing weird stuff and I have to go hack TypeScript to know my TypeScript". And anyway, so they're struggling in all these other languages, like Rust. Rust is hard and everyone's like, "I love the struggle". Adam Argyle: But for some reason, the struggle with boxes just really... just people hate it. They're just like, "I just want the box over there. And I've spent five minutes on it and I super frustrated". And I'm like, "You just spend eight hours on Rust in TypeScript. Why is five minutes in CSS such a big deal?" But anyway, a lot of it is valid. Things are hard. Centering is hard. There's a lot of different ways to center. This drives people nuts. They're like, "I just want Center". And you're like, "Sorry, what kind of centering do you want? Do you want vertical and horizon? Do you want it dynamic? Sorry, this is not an easy one. I know it sounds easy, but..." So anyway, I like that people struggle with it. It also makes me think that I'm somehow doing something extra difficult. Adam Argyle: Like, "Wow, you're good at CSS. That really is something. I'm like, "It's not, but whatever. It's like just being good at any language". So from my perspective, I'm like people dink around and they tinker and they bump their head against every language they ever write all day. And for some reason everyone's just cool with saying CSS is stupid or whatever. And they're just like, "It's hard". And look at me, the cascade, I hate it. And you're like, "Okay, well, you like inheritance patterns, right, in JavaScript? Why don't you... Whatever". So anyway, I just think it's a little misdirected, but it's okay. And I like to hear the feedback, because it can inform the language to become a better language at the end of the day and everyone has their right to their own opinions. So I'm happy that folks feel very free to voice their mind about it. But yeah, those are my little two cents on it, I guess. Noel : Totally, totally. Yeah. I feel like people have a tendency maybe to not kind of fully grasp the inherent complexity in just making things look nice. And that might lead to a lot of that frustration out of the gate. I don't know. I've talked to a lot of devs who would probably say that CSS is kind a necessary evil. Maybe they just want to build their thing and then like, "Oh, I've got to make it look decent too". And I feel like that might be where some of that frustration comes from. Do you kind of get that vibe as well? Or do you think- Adam Argyle: Yeah, it's that people want... Okay. So programming for a server is so much different where you're the consumer of your code and the validator of your code, the thing that says you did the right thing, your function is good. A server is so obvious and blunt and straightforward, right? And it's just like... You're just like, "Hey, I requested this thing from you," and it goes, "Hey, I give it back to you". And you're like, "If I ask you in the right way, it comes right back the same way every time". That predictability, that reliability, that is awesome stuff. But when you go to the front end, who consumes your work? A person. And people are subjective and people might not like what you did. And that's frustrating to someone that just spent four hours making a good piece of UI, whereas the server never complains. Adam Argyle: The server is like, "I returned it to you again exactly as you requested it". And it's just a simpler... it's a simpler consumer. And so as a front-end person, you're sitting between a human that needs to use it and a computer that needs to read it and understand it and draw it. You have more things to think about. And design is hard and people don't like that. And they think because you... Anyway, whatever I have a whole... I could riff on that. But yeah, I attribute it to this, that a person is much harder to build for than a computer. And most people are building for computers all day and when they have to go build for a person, it's frustrating. And I understand that, so I don't know. Kate: I was going to say, do you feel like the pressure to have everything... I was looking at the CSS Podcast site before this and I was like, "Oh my gosh, it looks so pretty. It looks so nice". Do you feel like the pressure to have everything you do be super well designed kind of because of your thoughts around this? Adam Argyle: Right. Yeah. And I'm like, I'm the CSS DevRel of Chrome. You better be super dope at CSS or else what the heck are you doing?" Yeah, I totally feel that. But at the same time, I'm super humble about how hard it all is. Or I just think it's more relatable. I have zero interest in appearing to be the turbo master of CSS. It's more interesting to me to be like, "Hi, this stuff is hard and I can help you work around it and debug it. And I'll help you get to the solution, but I bump my way around it just like I do in any other language I write code". So yeah, back to this circling, back to like, "I don't write JavaScript perfectly. Do you sit down and write perfect React?" Kudos to you. I'm actually not jealous". Adam Argyle: I think that's a little weird. I think that normal people struggle, even if they're good at something. And an advanced programmer is really just a collection of failures in so much that they fail less now than they used to. And so yeah, I'm totally willing to fail publicly, but yeah, at the same time my tweets make it look like I'm a super wizard because I'll be like, "Look at the super sick design thing in one line of CSS". And it's not very realistic because yeah, production is never ideal, right? So anyway, and that's the other thing. Yeah, we have this differentiation between ideal code where it looked simple and then you get to reality and production and production's always packed with all these edge cases and stuff like that. I don't know. So anyway. Noel : I guess, yeah. When I think about wrangling that and the complexities of production, I guess... I mean, early days of CSS, it's better now I think, than it used to be a long time ago, but I always felt like it was an exercise in edge case wrangling in a very frustrating way. I'm struggling to think of examples. So I'd just be like, oh, this works for 90% of the time. And then this one thing breaks and I fix that and it breaks something else. And when I'm coding, it was always like, oh, I can write a test and get all the... these easily done, easily covered so I can understand everything that's happening. And I felt like with CSS, a lot of the rules I was writing would end up breaking other cases. Noel : And again, I think it's better now, but do you think there's anything, any merit to that argument that it is just inherently more frustrating sometimes because there's so many of those little... there's so many possibilities. The canvas is so large, right? There's so many dimensions and accessibility options and all this stuff that can go haywire. Adam Argyle: Oh, yeah, the task that CSS is tasked with is enormous. It's much more complex than just a JavaScript function. But even JavaScript functions get wiggly too, right, where you're like you're talking about Whack-A-Mole, where you're like, "Bug over here", and then you hit it. And another one pops up over there. You're like, "Hey, what the? I just solved that". And then it's like it happens forever. CSS definitely feels like it has that a lot because of this global nature of things. And even with components, even... really, this comes down to inheritance polymorphism, just the way that we sort create and share work. It's really hard to predict how all the threads of a shared property of maybe it's a display property or maybe it's a color to see the trickling effects of everything. Whereas yeah, JavaScript or a typed environment we try to... This is actually why TypeScript is so important to people. It's like a refactor concept is you can trace this usage through all the different components and functions that need it. Adam Argyle: And then you can know the impact of your adjustment. And CSS, it's harder to know that stuff. We have custom properties and maybe you have visual regression testing and stuff like that, but it is much harder to track down the impacts of a change of code than it is in JavaScript. And that's because of the multiple view ports that something has to be shown within. Right? You have a small view port like a phone, a large view port like a desktop, a screen reader experience, a keyboard experience, of all these different contexts, dark mode, light mode, reduced motion. The matrix that you're expected to handle with some CSS is so much more vast than JavaScript. And it naturally comes with complexity and more moles to whack, I guess. Yeah. Noel : Yeah, exactly. Exactly. Yeah, the balancing, I think of the isolation I think is just... it's a hard thing to do. And this is probably not how we approach a lot of problems when we come into these things, thinking about all the edge cases first, like, "No, I just want to put this thing in the middle page". Right. And then it kind of all, like you said, kind of gets derailed from there sometimes. So yeah, I totally empathize with that. Adam Argyle: Yeah, that transition from ideal solution to production is it's always frustrating, but that's okay. Yeah, your JavaScript does the same thing. You had a function that you didn't even have to do the return brackets in your JavaScript function. You're like, "It's just a one liner. Bam, look at that simplicity. You can share this function". And then all of a sudden, someone shows up, "Hey, the user did this thing," and you're like, "Well, why'd they do that? They shouldn't do that thing". Now you have to go write an if statement in there and you're like, "I had this stupid little if in here, now I have to write a test for the if statement, otherwise the line of code isn't tested". And then another one comes in and you're like, "My function's ugly. And it was so pretty". Noel : Yeah. Right, right. Yeah, [inaudible 00:12:08]. No, yeah. I apologize for derailing us slightly. It just these kind of, I don't know, philosophical, ideological discussions are always like- Adam Argyle: Feels related to me. Yeah. Noel : It's good. It's good. Kate: I'm curious. I feel like I always hear this, do you think designers should know CSS? Where do you think design kind of fits in this space? Do you consider yourself a designer? I guess kind of, where does all that fit in? Adam Argyle: Nice. This is a good, big philosophical question as well. My answer is I have lots to say on- Kate: [crosstalk 00:12:41] philosophical questions with PodRocket. Yeah. Adam Argyle: I think that some designers... Okay. Oh man, how do I start this? Let's start with phases. I like to think about people and projects in phases. In early phases, a designer should not code. In early phases, a designer is optimal expressing ideally. And I want them to live in a world that's unfettered, that is free to express the right way without the limitations of any code. And that's the phase that we're in. We're in an expression phase and the code can be in a similar way. Maybe it's sloppy and loose and doesn't have a framework or whatever. But as you get a V1 and it turns out that people like it and something steady, you start to harden your ideas and you harden your concepts and then you make a design system. Adam Argyle: And now you have a new role as a designer, or you hire a new designer to manage the design system. And you can leave the expressive designer, which is let's just call them graphic designers right now. You can leave the graphic designer to continue graphic designing. That is a valuable thing still in your organization, that someone knows zero code, but is very good at making something pretty because they are very different. But then you have the systems designer that is going to go in and make things pretty and a system, which the system naturally starts to hinder the expressiveness of something. Now you see the tension that I'm getting in the phases that we're working through? Eventually, you get into a space where your app is so hardened and you're on v2, v3. And now you've got all these CI/CD workflows, and you've got visual regression testing. Adam Argyle: You're building up all this infra around own your core experience. You're less in an expressive workflow. And you're now into this tighter workflow where a designer who wants to get anything done, needs to write code or be conscious of the tokens, or they are too detached from reality. And so you get into this new phase where the delta between the expressive art board reality and then the reality in your app is just too great that the art boards could chase this forever. And they'd never be as high fidelity as the actual app. So a new designer needs to show up or you hire someone new that can work more directly on the code. Maybe this is a UX engineer. It's pretty much where I think I am, where I sit very much between a designer mentality and a developer mentality. And I try to find the harmonies and I make sure the user experience is benefiting. I'll stop there. Kate: No. Yeah, yeah. Yeah, no, totally. I mean, I feel like it would be hard. I'm neither a designer nor an engineer, but I feel like it would be hard. This is what I know how to do and then this is what it needs to look like. But all of a sudden it's kind of like I do what's kind of in the middle and it's like the two had a baby and that's what I... that's what the outcome is. Adam Argyle: Yeah. You're too concerned with implementation details that it's hindering your expressiveness because you're trying to design for what's with... what's going to be code able versus what it should look like. And yeah, so I like having designers around that don't know code because they push the code into better cooler, more unique things. They just naturally are thinking outside of your box and that's awesome. And you need those folks around. And you might also need a different type of designer around that knows more code. So, I don't think that there is one that is better than the other, I think depending on the phase that you're in and depending on the size of your team, you should have both and all of them in the same team. Kate: I'm curious, kind of what is your team working on or what's kind of the... what's the push for CSS in the future? Adam Argyle: Nice. Yeah, we have a... so we have the CSS Podcast is still going. We've got 40 something episodes or something where we cover really core concepts and we go into them in very computer science mentality. I think it's a healthy study for beginners and non-beginners. I think you'll find something in there, so that's continuing to go out. I have a show called Gooey Challenges on YouTube. That's through the Chrome developers where I build a piece of UI. I'm like, "Hey, let's just get down to it. Let's build". I built split buttons a couple months ago. I built a 3D game menu last month. I have a toast episode coming out in a few weeks. And my whole thing of it is I'm like, "I'm going to build something that is dark and light theme appropriate, is motion respecting, so if someone has reduced motion needs, I'm not going to make them sick". Adam Argyle: I'm going to make sure it's screen reader accessible. And I usually make it so that it's internationally accessible also. So right to left works and maybe even Japanese or Chinese top to bottom, right to left type of thing. And then I'm just like, "Hey, here's how I built it". I pretty much give you all the code. And I'm like, "Who wants to turn this into a component in their favorite framework, or who wants to show me their way to build this thing?" And so by the community coming together, we can grow together by seeing all the different expressive ways that we can get that done. And then we all also... so as a team, we have a Learn CSS that's coming out, or we've already released a bunch of modules on web.dev. So you can go web.dev/learns and you'll find modules that match. Adam Argyle: So it's articles and visual demos that match the podcast episodes. So you can listen to the podcast and follow along with a demo, an article set, or just go through the article. And I don't know. Anyways, we have those coming out. There's more modules coming out there. We have learned responsive design just came out, so we're trying to help designers understand their capabilities that they can use on the web. So even come... it's down to like, how do you do responsive images? Images are super hard to serve these days. If you're using the picture element, you can swap sources, you can swap source sets. The list goes on. And so there's art direction that happens at the code level. And how do we give designers that knowledge? So we're working on that. We've also got lots of stuff coming out of this dev tools. Adam Argyle: So the dev tools, we have a little SWAT team internally that works on design dev tools and how to make designers more integrated in the dev tools. So six months ago, we launched an angle tool. Anytime you see an angle in the dev tools, you can now click a little widget that pops up a gooey. So a nice little sundial or a clock shows up and you can just rotate the angle right there live. You don't have to know CSS. It could be in radiance, it could be in degrees or whatever. The designer can pop it open and just rotate it and be like, "This is the rotation it needs to be". And we just did the same thing with lengths. So if you see pixel values in your dev tools now, you can now drag a length value, just like if you're in Photoshop. And it's really powerful for just going in and trying things out, being expressive and making adjustments, and then you can also change the unit. Adam Argyle: So we've added a unit switcher in there as well. So you can hover over the unit, swap to characters versus REMS and try out how those different things work and also just explore what your units are. So we have dev tools that we're working on. Seriously, we have more stuff. Our team has been really busy and we have an exciting thing coming out next month also. And I have a little side project that's coming out next month. There's a lot of stuff coming out of our team. It turns out CSS is kind of on fire right now. I don't know if you're feeling it, but there's new stuff shipping like crazy. Have you seen what's in Safari with the color stuff? I do a lot of color work. The color stuff is so cool. We have CSS nesting hit a first working public draft. So official nesting is... anyway, we have developers are going to start prototyping that in chromium soon. Oh, the list goes on. Yeah, it's really exciting times. There's tons coming out. Thanks for asking. Noel : I mean, I think that might kind of segue nicely into... We have some notes on how CSS is growing really fast, kind of like you said there's so much happening right now. If you're new and coming in, how do you not as instantly become overwhelmed? What would you recommend to someone, I guess who is totally new, they're might not necessarily be interested in the cutting edge, but they would want to use it if that's what they should be doing for whatever reason? How do you tell them where to start? Adam Argyle: Yeah, just really quick too. The quick answer is learn CSS is kind of our answer to that where we're trying to make something that can let someone build up from nothing into something. But this reminds me of my favorite thing about CSS is developers... Okay, CSS is the easiest to get started with, right? Color red, boom. I'm a pro. The hardest to master... I've been writing CSS for, I don't know, 20 years, it's embarrassing to say, but whatever. And still, I struggle with stuff all time. But my favorite thing about this phase of CSS developers is you start out really timid. You're like, "Oh, okay. I'll just try a few things". And then after a week or two, or maybe it's a month, someone finishes their first project. And they literally are like, "I am a CSS master". Adam Argyle: They feel so good about the things that they built. And then all of a sudden, it recrushes their entire soul again. It's like, you don't know crap, and it's going to be really hard to build advanced stuff. And they're like, "Oh no". And then they regress. But it's so funny. I'll see on Twitter, someone's like, "Just finish my first month on CSS. Feeling like a super rad awesome programmer right now". And I'm like, "That's going to suck next week when they get really struggle". But yeah, Learn CSS is our hope to do that, where you go in, you start from scratch. Here's the Box model. Here's how text lays out. And here's some demos that show you just these really basic things so that you can get the foundation as you go, because a lot of people, I don't think start with the foundation. Adam Argyle: I think they assume front end is easy. And I think they assume CSS is child's play. And so they attack it with a bunch of passion and a bunch of arrogance and then they get crushed and it... and then they're like, "Oh snap, I can't even put two boxes next to each other or I can't center something". And they're like, "This was supposed to be easy". And so yeah, I don't think our industry has done a favor of making CSS sound easy or making it... yeah, it's quite difficult. And when it's done right, it's beautiful. It's like if you get in a car and the steering wheel's off a little bit, you don't care what the engine is. You just don't. The steering wheel's off, whatever. And so it turns out, it's really hard to make a good steering wheel, right? And it's really easy to mess up a steering wheel. Adam Argyle: I like the stairs analogy too. Stairs are so easy to mess up. I know you've walked upstairs. You're like, "Who made these stairs?" Someone made these stairs and they didn't try them first because they're terrible. Right. They're either too wide or they're too steep. And you're like, "I guess you need a UX engineer to come in and make your stairs because they sounded easy. They look easy. They're easy to walk on, but dang, are they hard to build?" Yeah. And CSS has that phase of yeah, it seemed easy and then it creeps up on you. It's a creeper. Noel : Yeah, for sure. Yeah, I guess that kind of the call out of you can tell when something's off or unintuitive. It reminds me of a book by Donald Norman, The Design of Everyday Things, how intuitive things should just work and be easy. And I guess I'm curious, do you think with all these new... all the new work in CSS that's being... all the new things you can do with CSS, do you think there's developers maybe will be pulled more towards doing things flashy and adding animations and kind of going over the top on making the webpage kind of too... I don't know, too much too vibrant, too difficult to interact with maybe just for the sake of using the cool new stuff? Adam Argyle: I think that's a natural problem. We have that in JavaScript too, right? Look at our Babel configs. They're out of control, right? We're just like, "I got to use the new question mark dot. I'll spend four hours making my web pack config work for all the browsers so I can type question mark dot", which I do love the existential operator. It's awesome. Or the Elvis operator, it looks like Elvis, hu-ha-hu. Noel : Yeah. Saves you a line. It's great. Yeah. Adam Argyle: Saves you a line. Right? But yeah, let's see the question originally. Let's try to rope back to it. Oh, snap. It's just floating out of my... I'm sure it's [crosstalk 00:24:38]. Noel : No, it's okay. I mean, do you think... Again, as CSS becomes more powerful and this is again, kind of an ideological question again. Is there a fear or is this... do you think about should the web be this flashy and interactive and animated and all this stuff? First, is just kind of doing the... serving information well. Are those odds with each other or do you think there's interplay? Adam Argyle: Nice. Okay. This is a fun question. I'm going to answer it a little bit even higher level, which is, I think the reason the web succeeds is because it's weird. I think the web would be toast if it wasn't weird, if it was normal like native apps. And native apps have the opposite problem, which is they're normal by default and you have to make them weird. And so what people do in a native app scenario is they go, "Sweet, look at all my rad components. I'm going to go strip them all down". And they go, "I'm going to take that out and that out. I'm going to do this weird thing in there. I'm going to do this weird thing". And you're like, Well, okay". And then you go on the web and web's like, I'm basically weird from the start. I give you primitive, old school ape tools and you better figure out how to make something cool at these like a wheel. It doesn't even give you wheels. You better bring your own wheel. Adam Argyle: And so it's sort of like it's weird by default and native is sort of normal by default. And I think that weird by default has a long tail and it has an excitement and it has yes, sometimes people go overboard. You definitely have gone to a site and you're like, "Wow. Wow. That's neat-ish". You're like, "Well, I don't know what you're trying to tell me, but you sure did some stuff". Yeah. And other times you're like, "I came here for a paragraph and I can't get it, it's covered in ads. It's covered in crap. It's cover in whatever". So yeah, I think that's par for the course of weirdness and I'm here for the chaos. I think the chaos and the weirdness is as super power, not a detriment. Adam Argyle: And then just real quick, a little lower level. Things like CSS nesting is a super power and it will allow people to also write really, really terrible CSS that is slow possibly because they can nest themselves into oblivion and yeah, to create issues. So sometimes you make an offering of a feature, which JavaScript has done this too, that can be abused. And it's hard to know. And that's what these working groups really try to do is they try to look at the holistic landscape. What are we introducing? What are the potential foot guns? How do we prevent the foot guns? How do we give them all the sugar without the belly ache, I guess? Yeah. And it's hard work trying to do that, but I think it's nice that I think the web is better off weird by default, honestly. Noel : Yeah, sure. Yeah. I guess that kind of brings me to another question I had on the working group specifically. Are there opinions kind... Is there any strife, I guess in the working group kind of among people who are... CSS has a specific role, it shouldn't be doing more than it is right now maybe versus like, oh, CSS should be powerful. We should have variables and reactivity and all the school stuff should be happening in CSS. Is there headbutting that occurs kind of at that level? Adam Argyle: Definitely. And it's not consistent. So it's not the same people are always defensive or other people are always introducing rad newness. Although I'd say I pretty much exclusively pitch rad newness. That's also just yeah. But you need the folks there that are also doing defense. And so that's what's nice is I think that you have all these different people from different perspectives with different skill sets, all trying to... For example, there is international typography experts. That's what they special in is how to represent documents that are in Japanese. And they're sitting there in those calls and sometimes they'll be like, "Oh, hi, I want to make a comment about that thing you just introduced. It'd be really bad in this one, Chinese character use case". And you're like, "I'm so glad you're here. Wow. We would've shipped this and totally clobbered that, and that would've been terrible". And so having someone there being defensive that way is great. Adam Argyle: We also have web platform tests. So just like you have unit tests for your app, the web has tests for every single feature and browsers need to pass them. They don't pass all of them. They pass them mostly most of the time, but those are also there. It's like a good defense. So you have structural defense so that things don't get introduced and totally annihilate other features. And then you have people that are in there trying to keep it well rounded. And yeah, I think it's a healthy tension. There's times where it can get really heavy, where folks are like really passionate against something and you're like, "Wow, why would you really be..." And then they express it and I think it's got to really good open vibe to it though. Noel : Yeah, good. Yeah, cool. And again yeah, I was just going to... reading, going and looking at some issues and some discussion and it all did seem like very cordial, everyone was friendly and it seemed very open, but I was just curious, if it ever got emotional or people had really strong feelings that were- Adam Argyle: It does, especially in the threads. I think the GitHub issues is where you'll see some of the anger the most, which really is because trolls show up and they're like, "Hi, I didn't actually read any of the other threads, but I'm going to express my opinion right now. And here it is". Someone goes, "Oh, God, just another crappy opinion that didn't even read the stuff". They don't want to deal with them. Sometimes people get booted, but I've seen a couple calls where the moderator, so there's always a moderator who's part of the working group is just like, "All right, thank you everyone for your very passionate discussion. I'm going to pause this right now. And we're going to put it in the parking lot". And whatever. Kate: I'm curious where you think adding to the complexity where CSS -in-JS stuff comes into play and how you see that going in the future? Adam Argyle: Yeah. CSS-in-JS is just a tool. I mean, you have to know CSS still. It's almost like another layer, a pre-processor. you're just sort of, instead of expressing your CSS that way, express it this way. And you're like, "Great. I still have to know what I need to express". And while it can help with a lot of things like scoping, naming, right, and do people don't like naming their classes. Robot class names have been really great for CSS, CSS modules. There sometimes introduces more complexity than was there before. I think sometimes now you have to trace some objects, getting extended that got extended by another object that now you're sort of like, "How do I get my variant into this extended object?" And you're just like, "Oh, this is a problem. This is a lot deeper than it used to be. My variance used to be in a media query and now they're in a funky string in a nested object in an extended object. Oh God, what did I do?" Adam Argyle: But at the same time, I don't think these things necessary really stop people from succeeding or make them succeed. I feel the same way with frameworks. I'm like frameworks, people make it sound like, how could you have ever built that warehouse without a framework when they're standing next to 10 warehouses that were built without a framework. You're like, "People do it and they're fine. And they're successful businesses". You don't have to use Framework X or CSS and JS to have successful front ends. I think sometimes we... here's an opinion. I think sometimes we over project success on our tools and we underestimate and undervalue the humans that actually made the tools do something. Adam Argyle: The tools just sit there in the corner like, okay, you've got a super garage. You npm installed a ton of gadgets and look at your garage, it's rad. And then like, okay, what does your garage do if there's no people there? Nothing. It does nothing. People had to turn that into something cool. Can we give people more credit? That's basically what I'm here to say. It's like, can we get people more credit here? It's not React's fault that that succeeded. It's not next that... or Gatsby that made you succeed. It's not emotion that made you a good front end CSS writer. It's not styled components. It's not those things. Adam Argyle: You were there. You sat down, you cared. You cared. You cared. And I thank you for that. And I don't care where you cared, y'all. If you cared about your CSS in JS, I'm happy you cared about it. You gave a good UX. That's the goal. I think what we need to focus more on is that end user experience and less about our developer experience. I talked about with Shawn Wang, Swyx about this exact thing, DX versus UX and that's a whole other topic. Hopefully, that podcast episode comes out soon, but yeah. Noel : Nice. Yeah. I might have to check that one out. I haven't really thought about those two ever being at odds with each other. Are there any examples, I guess that are easy to kind conjure? Adam Argyle: Yeah. Here's my vibe on it is DX, first off is, is so much more than delivering UX. So it's kind of underselling developer experience by saying the only way that DX is valuable is if you're outputting good UX. And so it always gets put in this comparison chart. Good DX makes good UX and I'm like, "Good DX, y'all does way more than good UX. Why are you even making this like it's one contingent moment of success? DX has so much more success to do with team enablement and team empowerment than it does the user experience. Quit making it sound like your DX is failing if it's not in impacting UX. I don't think those need to be directly tied". Second point is that good DX that makes good UX only works if someone put time and effort into articulate the good UX. It's not like good DX by itself magically poofs UX into existence. Adam Argyle: Someone had to go program the DX, right? So there was a human that cared. Again, here comes down to humans caring about UX. A human cared about UX in so much they made it a system and a program and they built it into Linters and they built it into the types and they built all this good UX. A human still was there. The DX didn't make that. So basically, UX... good UX existed first. Someone hardened it into DX and now it's maybe trickling and feeding into other people's good UX because the guidance and the intelligence and the goodness was built into the DX originally. So anyway, those are the two points. I'm like, "You're underselling DX". DX success isn't based on good UX and good UX is also way more than developer experience. It's just way more. So you're underselling both of these things by comparing. I'm like why? And yeah, and a good DX only comes if good UX existed first. So I'm like I don't know why that cycle isn't expressed more, but those are a couple of the thoughts in a nutshell. Noel : Yeah, crazy. I'm like, I never even really...maybe I'm just not in that space enough, but I haven't even really thought of those two being at odds in that way, so yeah. Adam Argyle: Oh, there are Twitter threads that are heated. Oh, they are so heated. Noel : I'm sure. Kate: Well, we'll have to link to that episode. Yeah. Adam Argyle: Yeah, if it comes out, that'd be a good one. Yeah. It's mostly designers that are just like... they fight for good UX all day and some of it never makes it into the app. And then there's other people that are like, "Good DX made our UX improve". And you're like, they... and people get really upset. They're like all day they fight for UX and it might not make it in the app. And then there's other people saying that the good DX is all you need. And you're like, that's fire. That's some fiery chat. Anyway, yeah. Kate: Awesome. Well Adam, thank you so much for coming on. Is there anything you would like to let our listeners know or want to shout out someone who... Brian always asks this question. Brian's one of other host. He always asks, is there anyone that you want our listeners to go look at their Twitter or look at their stuff? Adam Argyle: Nice. Yeah. Check out Una Kravets's work. She's killer. She's on my team as well. Lots of great CSS sharing going on there. She's got really great articles about 10 CSS layouts that are in one line of CSS. Just cool little tips and tricks. And she's a really great advocate for all the stuff our team is making. So yeah, check out Una Kravets on Twitter. I think I did most of my shout outs just naturally in the middle of this. There was a little spurt where I had four minutes of just shout outs. But yeah, I think the Gooey Challenges are really valuable. I'd love to see your contributions. If you are an opinionated front end developer and you've built a split button, you've built a stories component, you've built... I mean, I'm, I know you've built these things, go share your style with other people. Show them how you built it because it's only going to level up everybody around, so. Kate: Awesome. Well Adam, thank you so much for coming on and joining us and yeah, we'll see you around. Adam Argyle: Of course, see you. Brian: Thanks for listening to PodRocket. Find us at podrocketpod on Twitter, or you could always email me even though that's not a popular option. It's brian@logrocket.