555: React Documentary, Front of the Front End, Fast Fallacy, and Best Practices
Reacting to the React.js documentary, is there still jobs for front of the front end anymore? The fast fallacy in frameworks, best practices, dealing with too much or too little isolation, and AI test generation.
Guests
Chris Coyier and Dave Rupert
Time Jump Links
Transcript
[Banjo music]
MANTRA: Just Build Websites!
Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show. I'm Dave--moving the mic a little bit closer to my mouth--Rupert. With me is Chris--in the booth--Coyier. Hey, Chris. How are you?
Chris Coyier: I'm doing great.
Dave: Yeah?
Chris: I am in the booth today. Good job, me, getting off my butt and moving into the booth.
Dave: Moving to the booth.
I technically have a booth. It's just a 12 by 16 booth. [Laughter] It's just a little bit larger in the shed.
Chris: Yeah. Very large. You've probably got a fridge in there, yeah?
Dave: I do have a tiny fridge.
Chris: [Laughter]
Dave: And you may be able to hear it because I'm just noticing it's open. One second.
[Laughter]
Chris: Yeah? Take a little break. We just started.
Dave: We're back. We're back.
Chris: Keep the Monsters in there.
Dave: Well, yeah, that would be awesome. I do need the G FUEL rack. I still want to be sponsored by G FUEL. So, if G FUEL wants to sponsor Dave Rupert....
Chris: That's your dream one?
Dave: Oh, God. Coding and caffeine goes together, right? Natural.
Chris: It does. Mm-hmm.
Dave: Let's sponsor. Let's get on it, G FUEL. Coder FUEL. There. Free name. I just gave it to you. Let's go.
Chris: Easy.
Dave: Let's go. Let's do it.
Chris: Yeah, I'm still on the barbeque sauce train. Nobody has ever hooked it up.
I was watching. This just made me think of you in Texas and stuff. I just opened my YouTube, and sometimes I like to just let it wash over me, you know? What do you got, YouTube? Algorithm me. You know?
Dave: Yeah. Yeah.
Chris: People like that more than they think they do, by the way. TikTok lovers, you love the algorithm and you know it.
But anyway, one of the first videos was this... I think it was outside of Austin somewhere, if not Houston or something. It's in that corridor.
Dave: Sure. Sure.
Chris: It was one of these barbeque spots that you're so lucky to have so many of them in Texas. You're spoiled with them. I'd like to think I'd go every day.
Dave: I had barbeque on a taco for lunch just ten minutes ago, so yeah. [Laughter]
Chris: Okay. Well, there you go. But this was one that there's rankings, right? Even if you're in the top 50, it's great for business. You know?
Dave: Yeah.
Chris: This was regionally or something, maybe even hit a number one kind of thing. There was this little hole in the wall. Nothing. Just a shack on the outside. You get that weather thing going for you in Texas like, "It's hot all the time, so you probably don't need--" I don't know. Whatever. It looked like a barbeque hut, like spray-painted crap on the outside. "Open. Open Friday, Saturday Sunday," I think was their hours, which is probably not terribly uncommon. The ones that are open every day are almost like, "Are you really doing it right?"
Dave: Yeah. right.
Chris: [Laughter] Because the documentary was 30 minutes long, and it was a beautiful expose of the process that it takes them to get ready to be open for the weekend.
Dave: Mm-hmm.
Chris: They are not doing nothing those days. There's no laziness involved. There's an incredible amount of work to get ready, and it was a beautifully done algorithm.
I'm sitting there watching that. Pretty good. Then it shows me next is the React documentary. That was all the news this week.
Dave: Oh... oh, you watched a React documentary.
Chris: I watched every minute of it, start to finish.
Dave: I love a trainwreck.
[Laughter]
Dave: No, I knew it was being spoken of in the circles around town, and I very much wanted to watch it. I don't know.
Chris: Yeah.
Dave: I watched one of them, like the GraphQL one, and it was fine. It was good. It was good.
Chris: Oh, I liked that one.
Dave: Yeah.
Chris: Yeah. I can't say I've seen all of them. I know they did a Vue one. It's Honeypot, right, this company that makes them.
Dave: Honeypot, yeah.
Chris: Yeah, and I'm sure this was a big one because they know React is a big deal. There was an interesting story to be told there that you probably know less of. You probably know some stuff about Evan You.
Dave: Yeah.
Chris: Because he's just out there talking all the time. This Jordan Walke dude, he's totally disappeared. He doesn't talk about React ever, and he was kind of the original creator. But, you know, told the story that it was very much a team effort and showcased a lot of people's efforts to make this thing happen.
Some of the pushback I've heard is that not only the beginning, but really the whole thing -- and I found in my experience -- was very much this underdog tale of, "Will this ever succeed?"
Dave: Mm-hmm.
Chris: "We are changing too much," because there's nothing technical in the whole thing. It's like an hour and a half of trying to find drama of it all. Where it finds it is in, like, "When we release this thing at JS Conf," all the negativity around it and, "Are we doing the right thing or not?" and all that type of stuff.
It's not an underdog tale. You're all rich. You work at the richest company in the world. It doesn't matter what the world thinks of this thing. Whatever.
Dave: I was this underdog at this billion dollar company. Going to survive. [Laughter]
Chris: Yeah. Yeah. Then it kind of ends at... Yeah. You know Dan Abramov is in it at the way end. He was kind of like Gen 2, Gen 3 of the people working on it. and now it's just a very, very different place.
Dave: Mm-hmm.
Chris: It doesn't go very far in the future because we are at this spot where one of the refrains around React is, "You want a job, you better get React," or there are all these beginners that are out in the world that don't know how to make a website without React.
Dave: Hmm...
Chris: That's how far it's come.
Dave: Yeah.
Chris: That's wild to have watched this underdog tale of React go from that to just total dominance.
Dave: It's the entry point to website making. Yeah.
Chris: Hmm...
Dave: It's weird. And not to skip too far ahead, but we did have a question come in. Let me dig that up. [Laughter] I should have had this question up.
Chris: Yeah.
Dave: There was a question that came in: Is there a place for a front-of-the-front-end person getting a job? I think they were looking for their first job.
Martin de Lima wrote in: "Is there still any value in specializing in the front of the front-end dev, or is it just irrelevant now? I've been job hunting for over six months and, an overwhelming majority of my time, they expect back of the front-end expertise."
It kind of goes on, but it's just like HTML, CSS, accessibility, Web performance, design knowledge. Had luck landing jobs doing that, so not zero experience, but then coming back to the job market, everything is about like CRUD, routing, dev, GraphQL, APIs, DevOps, and I assume React and stuff is in there too.
Chris: Yeah. Yeah. Yeah. What a powerful experience; six months of job hunting, interviews, and all that stuff, and none of them just say, "We need you for your accessibility, HTML, and CSS." All of them are that kind of the other side of the divide, as my article put it, with all that kind of JavaScript generally focused stuff.
Dave: Mm-hmm.
Chris: And that's the world. Remember that? It made another round again recently that I saw that the Spotify CEO (I think) or CEO, maybe, that did the, you know, "there should be no such thing as a front-end developer outside of very junior context" kind of thing.
Dave: Yeah. Yeah. It was Shopify CEO, I think.
Chris: But Martin... Oh, it was Shopify, not Spotify. God, that's a real easy mistake to make.
Dave: Which is even more ironic because I know quite a few CSS people that work at Shopify. [Laughter] Anyway--
Chris: Yeah, I'm sure they don't love that.
There's reality. There's what we would want. There's this answer that says, "Ah, it's still really important stuff. Of course, those are important skills that everybody needs." Then this brick wall of reality that Martin is running into that says, "Yeah, but I need to get paid here, so what can I learn?"
Dave: Hmm. It's hard. I don't know. We were just talking about the React documentary. Maybe you can learn React. I don't know.
But I do want to call out this is the worst six months to find a job. The economic fear of whatever bad quarter is rampant. A lot of people are pulling back on hiring and stuff like that.
I can tell you -- and this is maybe hard if you're looking for work -- I know dozens of qualified people out of work right now who are very good at their job and very good at code and looking for work. I just want to say A) you're not alone and B) I would not judge yourself based on the current job climate because it's weird right now.
Chris: Yeah, well, it's a good time to mention that. Hopefully, you really are internalizing that, everyone. It was a huge news thing. You couldn't read tech news articles for a couple months there that wasn't like, "Who is laying off who and how much?" It really seems like it's still going.
Dave: I think it's still rolling, which is unfortunate. But I'm kind of the mind - towards the middle or end of Q2 -- people will realize their roadmap is not going to happen, so they're going to have to start hiring again. Maybe there'll be a frenzy.
Chris: Yeah, maybe.
Dave: But I would also... I don't know. I think it's also one of those things where maybe you have to either... Not to say adjust expectations, but I think there are two ways, like, sneaking into a big company where they just need hands, warm bodies, you know, or sneaking into a very small company where you'll probably have to work a lot but they just need somebody who can do stuff, and you show up and say, "I can do stuff."
Chris: Yeah.
Dave: But beyond that, I don't know. I think it's hard because I think most companies are frozen or the hiring is very slim pickings right now.
Chris: Yeah. What else is on your mind, Dave?
Dave: Well, I want to know more about the React documentary. [Laughter]
Chris: Oh, yeah.
Dave: I think it's hard to tell a story because you set out to be like, "Let's tell the story of React."
Chris: Mm-hmm.
Dave: But then you get that on film, and then you realize, "Well, that was a pretty boring story." [Laughter] "That was eight people paid to make a thing," or whatever.
Chris: Fortunately, there was some pretty... The people that were in it liked to talk, so I think they probably had some good material there.
Dave: Okay.
Chris: And probably relish the chance to have the story told, hopefully in a way that they wanted it to be told - in a way.
You know there were some interesting moments. The one that I clued in on... I mean not this this is unique. The whole industry clued in on that, but it was that first slide at that first JS Conf. I think this was actually Jordan Walke who did this. This was probably why he decided, "Screw the industry. I'll do whatever I'm going to do."
Dave: Oh, no.
Chris: Was that first slide where the world saw JSX, and it was literally angle brackets in JavaScript for the first time, and people were like, "What is that?!"
Dave: Mm-hmm.
Chris: Because it did... There was stuff in the documentary that, at the time, the separations of concerns concept in which the concerns were HTML, CSS, and JavaScript, that was strongly advocated. I'm sure I hopped on that bandwagon in a big way, especially because we were all into jQuery at the time. jQuery had this very much, like, write your semantic HTML over here and keep your JavaScript over here. "Never the two shall meet" kind of thing, which I don't know that it's talked about all that much, but that is still a way that you can approach JavaScript that isn't wrong.
Dave: Yep.
Chris: But isn't the only way to separate concerns, which is also not wrong. But that JSX thing, man, people hated that. [Laughter] I'm sure there are still some people that hate JSX.
But funnily enough, what it was of was a div with an on-click handler on it, which is funny because not funny. It's not funny. It's bad. Don't do that. There was no focus management done or anything on that. At that time in the history, we probably should have known better already.
Dave: Mm-hmm.
Chris: Because it's like, jQuery didn't... advocated for you to not do that. You could do that, but you shouldn't do that.
Dave: Right.
Chris: We already knew that as an industry. Then to have that show up at the doorway of React, and it hung on. I think that inaccessible attitude hangs on really to this day in React.
Dave: Ooh, brother. I'm telling you. It's really bad out there, brother.
[Laughter]
Dave: I'm making a crawler for Luro. We've talked about it on the show before. I am finding a shocking number of websites that don't have links on them. They just have divs, magic buttons--
Chris: Wow.
Dave: --that open pages or delete your account, which who knows until you click on it. Surprise! You know?
Chris: Yeah.
Dave: It's not like mystery meat navigation is an old term for when your nav wasn't very clear. But it's mystery meat what this element does. You know? I don't know. There are some bad ones.
I'm going to actually throw Angular under the bus. I think most React sites are doing okay. But it's the old Angular sites that are going to get you, man.
Chris: Yeah? Wow. Yeah.
Dave: I think Google, because Google biffed that up, too. It's like Gmail. It's just divs. You know?
Chris: Mm-hmm. Yeah.
Dave: So, I think there's some cultural... It's funny how the cultural, like what's at that epicenter of its genesis just then is that's what keeps going.
You look at 11ty, right? They had that Speedlify thing where everyone gets a rank every week on how fast their website is. A little show-off-y, but that's fine because the Accessibility Project does really well every week.
But I just saw that Astro was like, "We value performance, so we're actually going to fork this 11ty thing and do it for just Astro sites."
Chris: Hmm...
Dave: I was like, "That's cool. If you value it, then you put it front and center."
Chris: That changes the culture. That changes how people that work there think about it, how the public sees it. Yeah, that cultural stuff is a big deal.
Dave: I mean if you were like, "Hey, CodePen is for pictures of butts," and CodePen is about butts, that would change the culture of CodePen.
Chris: It would.
Dave: Instead...
Chris: In the best possible way.
Dave: Don't look at my profile header. Yeah.
[Laughter]
Dave: But instead, you guys do the Sparks. I listened to your podcast about the competitions, the monthly competitions and stuff like that.
Chris: Mm-hmm. CodePen Challenges, yeah.
Dave: Challenges, man. They are awesome. They're an awesome way to participate, and you sort of set the line.
It's not even Dribbble-y, right? Dribbble was very much like, "Hey, we're all making fancy icons," for like ten years. Right? But CodePen, there's still a bunch of variations in the challenges. Unless you're seeing... I don't know. Is it all the same CodePen? Is everyone just making the same CodePen, or is everyone kind of doing something a little different?
Chris: Yeah. It's amazing how much work Marie puts into that and thinking the ideas and encouraging people and putting together the weekly emails that go around it and measuring it, too, which informs all of it, which is interesting.
Dave: Yeah.
Chris: Most people don't see that, but she's very into... And it's not just one statistic. She's got this whole suite of things that are very interesting to look at around how they do. For example, one is just how many people made one. Of course, right? That's what you would want to measure, like how popular was that challenge?
Dave: Yeah.
Chris: But you can also look at how many times it was forked later.
Dave: Hmm... Neat.
Chris: To see were the results of this challenge something that produced interesting things that other people wanted to play with.
Dave: Yeah.
Chris: That's just one of them. There are a bunch of them that are interesting in that regard, like the lasting impact of a challenge. Pretty cool.
Dave: Yeah. Anyway, see, I think it's interesting. I don't know. That's me just talking about culture baked in, in the beginning.
Chris: Oh, right. Yeah, the culture thing that got into it. Yeah, I did finally follow up on that "fast" idea that we were talking about on the show.
Dave: Yeah.
Chris: Just put some reasons of things that could be fast in there. I want to use Astro as another example just to mention them one more time, but only to--
I'm still sorting out my feelings on this because I'm just a big fan of them, so I feel like I can be critical and not be accused of not being a fan. But the idea that it's like, "If you use this framework, then the website that you produce is fast," is a little bit of a fallacy that isn't my favorite.
Dave: Right.
Chris: Because there are so many ways to make a slow, bad website that are so easy and that the framework has nothing to do with that it's like, "Don't tell me that." It's a little bit -- to be even ruder, I guess -- "Take this pill and you'll be beautiful."
Dave: Mm-hmm.
Chris: It's not the case. It's just not true. You know? [Laughter]
Dave: Right.
Chris: It does give you a good baseline, and it does give you good tools to stay where you want to stay. They're doing a good job in all of that way. But I just don't want anybody to have in their head that "If this framework, then fast website," because it's just not the way it work.
Dave: True. No, I think that's very... In the age of blazingly fast, it doesn't mean it.
I use Turbo Repo. You think that would blast out a fast website.
Chris: Oh... Do you really?
Dave: Well, yeah.
Chris: I really want to know more about it. We tried to get him on and it didn't work out for some reason. Maybe we should. Him meaning... I think there is kind of a one... It's probably multi-people work on it now, but I think it was the brainchild of one dude, wasn't it?
Dave: Yes.
Chris: I can't remember. But I have a mono repo of Next.js sites with React components in it and unit tests and stuff. I feel like I'm the perfect person in the world for it to help, and I don't get it. But it's just an education problem, so I want you to help. How does it help you? Maybe that will help me.
Dave: I mean I think it's like any kind of workspace tool, like Yarn workspace or PNPM, I think, can do this to some degree or something.
Chris: Does that mean you don't need Yarn workspaces then? Because we do use those.
Dave: We don't use Yarn workspaces.
Chris: Oh...
Dave: We use regular old NPM, but it's basically just a tool that sits. You can have different apps. You can have different packages. Then my apps can import my packages locally.
Chris: Yeah.
Dave: I say import helpers from Luro helpers.
Chris: Yeah. Yeah, yeah, yeah. That's the way to go. So, you have your own internal packages that live in that mono repo, but you import them with that, probably like, @luro or something.
Dave: Yeah. They get, I think, bundled into the app, like installed on the target, but it's like the package.json says Luro helpers version star, :star. You know?
Chris: Yeah, exactly. We use 1.0.0 on all of them.
Dave: Okay.
Chris: Just for fun, you know?
Dave: Yeah, it's kind of... I was like, "Ooh, star." But you know. You could version it if you wanted to, like I guess that's totally... If you're on design system one and design system two is coming out - or something like that. I don't know. You could version it.
Chris: You could, but that's "can of worms" I think. But sure.
Dave: That would probably be a niche case. [Laughter] I don't know. Because kind of the whole point of mono repo is just roll it out. You know? [Laughter]
Chris: Yeah.
Dave: If you were working on it.
Chris: How would you do...? You'd have to get tag old releases; then how do you update them? I don't know.
Anyway, so you have mono repo running. That's cool. It's an alternative to Yarn workspaces, because we depend on that, but I don't love Yarn. [Laughter]
Dave: Right. Well, I think you will love Yarn because one thing Yarn does solve that we don't have is because when I NPM installed Turbo on my Mac, NPM puts a reference in my package.json to the binary bindings, like ARM 64 or whatever it is on Mac.
Chris: Oh... So, everybody better have that same machine.
Dave: Yeah, and guess what doesn't have that machine? Your server in the cloud is not an ARM Mac.
Chris: Yeah. Why does it do that? That's terrible.
Dave: Well, that's NPM's fault, and so to get around that, you use Yarn or PNPM or something like that.
Chris: Hmm...
Dave: So, you'll probably still have Yarn, but it's just neat. It just starts things up. Luro is now, I think, five applications total.
Chris: Mm-hmm.
Dave: We did that partly because we were on a big monolith, but we were just having observability problems where if one part of the app fell down, all of it fell down. Logging helps that, but if one part of the app falls down, now you have 7,000 other errors, and it's hard to find that needle in the haystack.
Now we have very isolated services, I guess you'd call them, that subscribe. They don't even hit the main application. Services are all invoked through a RabbitMQ messaging, ticketing system, job queue system.
Chris: Fancy.
Dave: We're a big application. [Laughter] Not really.
Chris: Yeah.
Dave: It's been a lot of work. Kyle Zinter, who I work with, has done most of this stuff. But it was kind of a big, like, refactor.
We're in like our third architecture, and I feel like this one is good, though, because we can now scale, and then we can horizontally scale our instances and load balance those if we need to. We can vertically scale and get a bigger box.
Chris: Yeah.
Dave: That's like--
Chris: Yeah, that's all important stuff.
Dave: Yeah, and it's just - you know. But I think it is this very, "Whoa!" [Laughter] Like, "What on Earth?" You know?
But now it's a lot. I feel like my whole life is going in between... Is doing the horse-size duck problem. It's like do you want 100 duck-size horses or one horse-sized duck? Which would you rather fight?
Chris: [Laughter]
Dave: Because it's either you have a big thing or you have a lot of little things. Then you're either fighting a big thing and it's painful or you're fighting a small thing and it's fine but you're just getting your ass kicked constantly.
Chris: Yeah. Yeah, yeah. Just to totally ruin the metaphor too, sometimes it's like, "All right. I'm going to take a cow-sized horse and then 30 ducks."
[Laughter]
Chris: We're definitely up against this thing now where it's like, "Yeah, but some stuff really should be small and separate." But you're like, "We did all this work to get to the mono repo."
Dave: Yeah.
Chris: Then you're desperate to hang onto it, but you're like, "No!"
Dave: That's like the "draw the rest of the horse" meme, but then you just start drawing ducks. Right?
[Laughter]
Dave: It's like half a horse and then just all ducks.
Chris: Just tons of ducks, yeah. The horse is exactly cut off at the legs. Oh, that's great.
Dave: [Laughter] No, that's what it feels like. I mean it's just that over and over. But I feel like we're finally in a good spot because we don't have--
Chris: Mm-hmm.
Dave: It's mostly isolation. I'm calling it observability and availability. A) The services stay up. But then observability; when it goes down, we know what went down and why and how and where to start the fix because that's the other trick. If the app server goes down, it's a mystery every time. But if whatever, the most recent call to service one goes down, you know it was the most recent call to service one. [Laughter] That's... you know.
Chris: Yeah. Yeah, yeah.
[Banjo music starts]
Chris: This episode of ShopTalk Show is brought to you by Frontend Masters. There are so many courses on here, the highest possible quality courses, almost focused on maybe you're already a front-end developer and you need to learn a new technology or really level up. You definitely can be a beginner too, so think of that.
I think a lot of people that listen to this show are kind of in that intermediate zone. This is the place for leveling up and learning new technology. We've got courses on here about Next.js with Scott Moss. We've got Ben Yong on here, Brian Hull, Kent C. Dodds. Sarah Drasner is on here. Nobody I'd trust more than Jen Kramer to teach intermediate HTML and CSS. Just amazing. The best of the best, and Dave!
[Laughter]
Dave: Hey! I've got a Web components course out there. I don't know how I slipped in, but I did. Let me tell you; it's going to teach you Web components. Yeah, if you're interested in that, I feel like they're a hot topic this year, so people should go sign up and watch it.
Chris: Yeah, Dave. You're early to the game, as usual. You know what's going to be big.
Dave: I used my code smeller, [laughter] and I smelled out the next big one, baby.
Chris: Yeah, Dave. Web components are not going anywhere, and you might as well learn them now. Check it out at frontendmasters.com.
[Banjo music stops]
Chris: Lots of other stuff we could talk about. I know you have some other things on your mind now.
Dave: Well, I don't know. It kind of goes into that React stuff, right? Did the documentary get into Twitter personas amplifying React at all?
Chris: No, Twitter was never mentioned once.
Dave: Really? Interesting.
Chris: It's too early for that. I think it ended too early.
You know I could be wrong about that, but it showed plenty of screenshots of tweets, but they were mostly historical, and they were mostly to show off, like, "Look at the community hated this at first."
Dave: Oh, okay. Okay.
Chris: And, "Look. Now the community doesn't hate it as much." You know?
There was an old Ben Alman tweet. Remember? Is Ben Alman still around, @cowboy?"
Dave: Oh, yeah. Yeah.
Chris: Yeah. [Laughter] He was the one who they showed his tweet a bunch of times. It was like "Facebook: Rethinking best practices TM." And they showed it that his intention early was a jab at, like, best practices are best practices, so rethinking them is stupid.
But then they kind of embraced it. They're like, "Yeah, we are thinking best practices," a little bit like Tailwind does now. You know? That "Best practices don't work" article - or whatever.
Dave: Ooh...
Chris: Which has the hilarious title. That's like, "Well, if they don't work, then it's not a best practice," kind of thing. I feel like we need to go back to English school or something.
Um, okay. There was that, but there were some things that were relatively new. One thing was that JSX or using angle brackets in JavaScript is now... everybody does that now.
Dave: Mm-hmm.
Chris: It's not even always just JSX. Interesting. But they were doing it before, too, that they really dwelled on the fact that they already had this framework called Bolt - or something - internally that was not that different--
Dave: Oh, yeah. Okay.
Chris: --then React even is now - or whatever. I'm sure it is (to their mind). But this goes into some of the struggles of, like, "We can't have two frameworks, so got to pick one," and the amazingness that they picked the new, experimental one rather than the one that was already in production all over the place.
Dave: That's interesting. That's actually relevant. I wonder how many good ideas are on that threshing floor.
Chris: Yeah.
Dave: The, like, "We went with the old one because of time." You know?
Chris: It reminds me of some things, like what would it have been like if we just used the dang functional components syntax the whole time? It's amazing that that didn't kill React. Isn't it? It's kind of a testament to have that big of a change in the architecture of how you're supposed to write React and have it still be as popular as it is, is amazing to me.
Dave: Yeah, that's true.
Chris: In our codebase, this just happened on Monday. I think Alex noticed one little thing of an async hook that wasn't being called with a wait. We were like, "Oh, that's weird. That's actually a little bug. We should fix that." And we were all under the assumption that we had the ESLint rules for hooks on, because we have in the past.
Dave: Mm-hmm.
Chris: Somehow, they were just off. It was just not in the config pile properly. So, we were like, "We should turn those on again. Oh, sweet Jesus." You know?
[Laughter]
Dave: Beep-beep-beep-beep-beep.
Chris: A year of React work, that was quite a few little changes to make. I'm sure React people can relate. The most common one in our codebase was if you use "use effect," one of the classic hooks in React.
Dave: Mm-hmm.
Chris: You have to put the dependencies. Any dependency that you use inside of the "use effect" needs to be in this array as an extra parameter at the end of it, and it's so fricken' easy to forget or mis-put exactly what it needs in there. It's such a pain in the butt.
Dave: Yeah. Yeah, tooples will get you every time, man.
Chris: [Laughter]
Dave: Yeah. That's... man. We've actually had that, too. Even just moving, because we use Vetuer, V-e-t-u-e-r.
Chris: Yeah?
Dave: Which is the--
Chris: What is that?
Dave: --Nuxt 2 syntax for Vue. It's the old syntax library.
Chris: Is it a linter?
Dave: Yeah, linter and formatter and auto-completer kind of rollup.
Chris: Oh, interesting.
Dave: The new one is Volar, V-o-l-a-r. And I've tried to switch to that new one, and it is very mad at me.
[Laughter]
Dave: It is months of work mad at me. It's like, "Your components are named wrong," and I'm like, "Uh-oh," because Vue is now, I think, for Web component purposes, trying to enforce a double capital name, so you can't have just button. It needs to be My Button.
Chris: Capital B, Button.
Dave: Yeah.
Chris: Oh, even that. Oh, my gosh.
Dave: Yeah, so--
Chris: Yeah. And it's just the worst work, isn't it? It makes you feel productive for a minute, but you're like, "The best case scenario at the end of this is that I make this tool happy that's supposed to be helping me, but I'm helping it instead." Then I don't introduce any bugs as I refactor hundreds, if not thousands, of fricken' lines of code.
Dave: Yeah.
Chris: That's awful. That's awful. [Laughter]
Dave: I've been on a bit of a terror. Poor Kyle is subject to this. When we change something, oftentimes, right now, that change, like changing one thing is a change, actually, in like five different files. Like, "Okay, I renamed a component," or I added a prop or something. "Okay, now I've got to go through five different files and add this prop to fix that thing." You know?
It's giving me a code smell of, like... Why is it every time we make a change, we edit 5 files, and our PRs are always 20, 40 files? I'm just like, "What? I thought the whole point of components was I don't do this?"
I think it is, but there's something, a smell coming. It's just like, is it too much isolation or is it too little isolation? Does that make sense? Do we have too many components, so when we change a component, API, or something, we have to roll it out 50 places? Or is it too little isolation, and now we have to roll it out in 50 places? We have to copy/paste the code back into the 50 different places.
I don't know. I'm sort of stuck, and I don't have a year of brain space to sit around and really ponder it, so I don't know. I don't know if CodePen has it all dialed in perfectly or what, but you guys pay down the technical debt, though.
Chris: Yeah, but you can't only do that. You know? Ah... It's tricky. Those are unanswerable questions because even if you think you have it right, the next week you'll be like, "Update everybody. I didn't have it right." [Laughter]
Dave: Oh, it's the 100 ducks again.
Chris: Yeah.
Dave: It's, do I want a bunch of tiny little components or do I want one big component? Do I want one component that - whatever - renders 50 different modals or do I just want 5 different modal types? Anyway, it just gets you, man. It just gets you.
I feel like I'm close to understanding what's going on but, yeah, it'll take a lot of 40-file PRs to get there. You know?
Chris: Right. Yeah. You've just got to do it sometimes.
Dave: Sometimes.
Chris: Yeah, and those are the few PRs that should be that way, probably. Every other PR is like... I reviewed one today that was one file, and I was like, "This is the best PR I've ever seen in my life."
[Laughter]
Dave: The current PR I'm reviewing, I'm just saying, "I love that red. Love that red."
Chris: Yeah. [Laughter]
Dave: The red is going away. But some of the red is going to a different file, so the next time we work on it, we'll have to go edit that other file just to fix the thing in the file.
Chris: I could see a future that I can't quite envision, but I can tell what it would feel like. Sometimes you pick up a little function, and I was just looking at some of these because some of them are like, "Oh, the answer was just to move the function inside the use effect - or whatever crap." It looks like a lot of red and a lot of green, but it's the same function.
Dave: Mm-hmm.
Chris: I kind of want to see a dif tool that instead of just red and green, maybe there's some other way to express that, like, "This function was unchanged. It just moved. But you should really pay attention to this line that's actually new," which happens a lot when you alphabetize a set of keys or something.
Dave: Mm-hmm.
Chris: I had one where I added one and I alphabetized them at the same time. I was like, "Which one did I add, dear reader?"
Dave: Guess. Yeah.
Chris: Time to use a lot of cognitive function to figure it out.
Dave: Yeah. Oh, that would be really... Yeah, I mean that would be cool if a tool could just be like, "Oh, we use blue for renaming." That would be awesome. [Laughter]
Chris: What gives me hope is that I sometimes see the same dif in different context. I wish I could remember a good example of this, but I've seen it look different, the same dif.
Dave: Hmm...
Chris: It's like there are, I guess, obviously, tools and libraries and stuff that do this diffing work and have their own opinions on how it should be output that presumably can iterate and get better over time.
Dave: It's amazing what the "hide whitespace" button will do, too. You know?
Chris: Hmm...
Dave: You click "hide whitespace," and all of a sudden, you're looking at three files. You know?
Chris: Yeah. Great idea. Wonderful.
Dave: Nuxt is pretty particular about your indentation or Vue is, the formatter. If we wrap an element or something like that, boom, suddenly 90 lines change. But it's actually 2 lines have changed but 70 got indented.
Chris: Right. Right. It feels unquestionable to me. Nobody should be looking at red across all 70 of those.
Dave: Right.
Chris: Unchanged lines, that's stupid.
Dave: But it would be... I love that idea of, like, this just got moved. They do it with file renaming, which is cool. But yeah, just like, "This was moved to a different file."
Chris: Yeah.
Dave: It'd be cool to know that. Then it would be neat to, like, how many PRs is just moving furniture around? That would be an uh-oh because even if you hopped in to review a PR, you could be like, "Oh, this one deletes a lot. Oh, this one adds a lot. Or this one just moves stuff around a lot." That would be good to know.
Chris: Yeah. I was thinking about test generation a little bit, too. This is a little bit related. Not entirely, but it's about tooling getting better.
I was working on tests that somebody else wrote here at CodePen. It was a pretty clear processing event, right? Like, send in some data and then check everything that you get out of it, like a whole little mini file system of output should equal this.
We keep the expectation kind of on disk. You know what I mean?
Dave: Mm-hmm. Okay. Okay.
Chris: You can even do it as source and dist. Why not? Because that's how developers do it, so the source is the input of the test. Then it does the processing work, and it should compare it to a dist folder that's sitting on disk. That's kind of nice.
Dave: Sort of like a snapshot of multiple files kind of thing.
Chris: A snapshot, that's exactly where I'm going with this.
Dave: Okay.
Chris: But one cool thing the test runner does is it doesn't make the dist folder. In this one case, it's not something that you should blow away. You used to be able to blow away your dist folder. Who cares? It'll just get rebuilt, right?
Not in the test case. The test case is actually comparing against that, so the test runner actually makes a dist_temp - or something - folder like that instead. So, at any time, you can look at three things. If a test fails, you can look at the source code that went in. You can look at the test itself, of course. You can look at what it was compared against because that's that dist folder. Then you can look at what it actually made, the dist.temp folder. You can kind of dif between the dist and the dist_temp and be like, "Okay, what's not right here? Is it just some white space or what?"
What's kind of cool about it is that it is a snapshot. So, if you want that test to pass, one way to do it is blow out the dist folder, rename dist_temp dist, and now the test will pass because the output is the same because it is a snapshot.
It's a little manual for us, but I think that's how a lot of these snapshot-based test runners work is that you can just write a test, run it once, save the output for it, and say, "That's the correct output. I want you to do that."
What's cool about that is it doesn't come from your brain then. You don't have to write an assertation that says, "Did users.firstname equal Dave?" because that's what a lot of people write. Then you're like, "Yep, it is, so it's good." It's like, "Hell no. I want you to test all 100 lines of that object. And if any of the 100 of them changed, I want you to flag something." It's a way more robust test.
Then if it fails, you could look at it real quick and be like, "Oh, I see." The URL has a different subdomain or something. That's not actually a problem. We just changed that.
You just say, "Update snapshot," the test passes again, and off you go. That's awesome. You know?
Dave: Yeah.
Chris: I was reading this post the other day, "What if writing tests was a joyful experience?" on the Jane Street blog, and it was all about this, too. That kind of snapshot-driven testing is just a really nice way to do it. It goes into even down to how you write the test.
Dave: I have some troubles with snapshots. Can I explain?
Chris: Yeah. Yeah. Sure.
Dave: Okay. I feel like they're kind of like the photo on your driver's license. It's kind of like, "Hey, is this the guy?" It's like, doesn't look at him at all but, "Yep, that's the guy." You know? It's like a photo you took 16 years ago, and it's just somehow you're trying to match your stuff to this photo, the current you.
I feel like sometimes when you're working on components or something like that, like matching it to a snapshot is, I guess, fine. But it just seems very - I don't know - brittle or it's just like you're going to hit update snapshot so much that you're desensitized to it. You know?
Chris: Hmm... Right. Well, if that's the case, that is a problem.
Dave: Well, I like it for your thing where you're like, "Okay. I'm putting this Sass in. I expect this Sass exactly out." Right? That's probably a test you have in CodePen.
Chris: [Indiscernible]
Dave: Yeah, so I think that's perfect. Then here's that test but minified. Here's that test but - whatever - expanded.
I think that's rad. Then you all do that whole, like, when you download, it stitches up. You'd want definitely to install that. Right?
Chris: Well, they need to be deterministic. Then there are interesting things like -oh, I don't know - this PostCSS plugin changed from this version to this version - or something. Or somebody is using preset-env, and browser versions have marched on a little bit, so the output of them has changed a little bit. So, all of a sudden, what used to have a MOZ and a WebKit prefix in CSS now just has WebKit only, or something like that. That test is still fine. I don't give a shit.
Dave: Yeah.
Chris: That output change, it's not a big deal to me. I can just be like, "Okay, that's an update snapshot situation."
But you could also look at... But you really need to know. Changed output in people's stuff is a big deal. There's more to this story because, honestly, we shouldn't be changing what version of anything that anybody uses. We should be worried that if there's any output change to a Pen. This is historical CodePen when we used to just change under your feet. [Laughter]
Dave: [Laughter] Old CodePen. Yeah, we just change it.
Chris: It was just a miracle that we... Yeah, we just changed it, indeed. It won't be the case going forward, but anyway, interesting stuff.
Then testing stayed in the news a little bit more. Tabnine, long ago they might have sponsored a couple episodes of this show, but it's been a while. They were kind of a pre-GitHub Copilot.
Dave: Mm-hmm. Mm-hmm.
Chris: I remember talking to them at the early versioning of GitHub Copilot. They were like, "Oh, this is not a problem. They're so different." [Laughter] It was like, "No, they're not."
[Laughter]
Dave: Uh...
Chris: They're literally the same thing. But they're still around and probably trying to pivot to find other ways to help do stuff for you, which I don't blame them because it was kind of a good product at the time. It's just that GitHub Copilot is great, so--
Dave: Yeah.
Chris: There's that. Now pricing is a part of it, too, because Copilot is $100, isn't it?
Dave: $100, so you could undercut them, you know, and be the discount Copilot. That would be a good move.
Chris: Right. Tabnine did always say that they were trained on your stuff more so than the entire world. And so, is that good or bad? I don't know.
Dave: That might be... I don't know. That might be a good security thing. Even just that code now should match your own coding style guide or something.
Chris: Yeah, exactly. I always thought that was clever. Maybe the combination of both would be good, kind of weighing my stuff more.
But this blog post is about AI-powered unit test generation.
Dave: Mm-hmm.
Chris: It looks at some class and then is like, "I'll just make a bunch of unit tests for this thing." That's great. You should totally do that. [Laughter]
Dave: Yeah. I use Copilot for a lot of unit tests, and it's pretty good. I mean it's never... You know sometimes it's way off. It suggests keys or properties I don't have in my component.
You know. Usually, I can write a comment or start typing, like, "Expect whatever error to show error," or something like that, and it'll figure out how to do that. And so, that's actually been a boon to my test writing because I don't like it and never have. But now I kind of am okay. If I'm in the mindset, me and Copilot are just going to power through it and bloop-bloop-bloop, spit out some tests.
What is it? AI is good at bullshitting. That's the thing people say now. I mean that's sort of what testing is sometimes is just like, "I'm just going to write some bullshit code."
Chris: My guess is that it's seen so many of them that are so similar that it's just better at guessing those things than it is for your deep, in-application code that's probably a little bespoke.
Dave: Right, and then I have to... I think the trouble I come up with is drumming up what I'm supposed to test or what would be worth my while to test.
Chris: Right. Right. Right. That should be kind of like - I don't know - work smell or something. If I think I need to do some work and I can't even think of why I'm supposed to do it, there might be a moment there where maybe you don't need to be doing it.
Dave: Or we should have done it. We should bake it or move it left or move right in the process or whatever. Move it left.
Chris: Yeah.
Dave: Then make sure all the tests happen before, because a lot of the time you're like, "Oh, man. Yeah. We did add that weird feature. Let's write a test for it because it's broken now." You know? Hate to say it, but that happens.
Chris: Indeed.
Dave: Well, Chris. Should we wrap this up? I feel like we've talked a lot about a lot. We've got some blog posts, I think, to write from this episode here.
[Laughter]
Chris: Yeah. Yeah, at least one I've got cooked in. That's how content projection works, though. You've got to repurpose those ideas across the spectrum.
Dave: I would be a billionaire if I wrote down all the mouth blogs I did on this podcast.
[Laughter]
Dave: I'd be so blog rich. It'd be amazing.
Chris: Yeah. The written word is usually worth a little more.
Dave: A little more legs than a 47 of a one-hour podcast. [Laughter]
Chris: [Laughter]
Dave: Oh... All right. Well, we'll wrap it up. Thank you, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show.
Follow us on Mastodon, @[email protected]. And join us over in the D-d-d-d-discord, patreon.com/shoptalkshow. It's fun.
Chris, do you got anything else you'd like to say?
Chris: Hmm... ShopTalkShow.com.