Whiskey Web and Whatnot

A whiskey fueled fireside chat with your favorite web developers.


119: Cracking the Podcasting Code with Andrew Lisowski and Justin Bennett

Show Notes

Podcasts are a popular way to share knowledge, stories, and ideas in the tech space and the medium continues to evolve rapidly. But what does it truly take to create a successful podcast that captivates an audience?

Andrew Lisowski, Senior Software Engineer at Descript, and Justin Bennett, Engineer at Oxide, are seasoned podcasters and hosts of the Devtools FM podcast where they talk to industry leaders about developer tools. They shared insights on the evolving landscape of podcasting, highlighting the importance of having a sustainable workflow and maintaining consistency. Andrew and Justin believe a major key to podcasting is understanding your audience, their preferences, and how to keep them engaged. Throughout the episode, the conversation covers an array of topics, including the influence of developer tools, the resurgence of HTML-first web development, and the role of WebAssembly (Wasm) in shaping the future of the web.

In this episode, Andrew and Justin talk to Robbie and Chuck about developer tools, the future of tech, and the world of podcasting in the tech space.

Key Takeaways

  • [00:55] - Introduction to Andrew and Justin.
  • [03:17] - A whiskey review: Great Jones Straight Bourbon Whiskey.
  • [14:13] - Tech hot takes.
  • [37:57] - Andrew and Justin give tips and tricks for podcasting.
  • [47:45] - Careers that Andrew and Justin would choose if they weren’t in tech.
  • [48:58] - Andrew and Justin take over Whiskey Web and Whatnot.


[20:32] - “I don’t actually think Git is good. It is a utility, and it is good enough for most cases.” ~ Justin Bennett

[33:22] - “If there is a future for Webpack, it’s Rspack.” ~ Andrew Lisowski

[36:46] - “The best frameworks, in my opinion, learn from what other folks are doing.” ~ Justin Bennett


Connect with our hosts

Subscribe and stay in touch


Top-Tier, Full-Stack Software Consultants

This show is brought to you by Ship Shape. Ship Shape’s software consultants solve complex software and app development problems with top-tier coding expertise, superior service, and speed. In a sea of choices, our senior-level development crew rises above the rest by delivering the best solutions for fintech, cybersecurity, and other fast-growing industries. Check us out at shipshape.io.

--- Send in a voice message: https://podcasters.spotify.com/pod/show/whiskey-web-and-whatnot/message


[00:00:00] Robbie: What's going on everybody? Welcome to Whiskey Web and Whatnot with your hosts Robbie the Wagner and Charles William Carpenter the third With our guests today Andrew and Justin from the DevTools FM podcast. What's going on guys?

[00:00:20] Justin: Hey, hey,

[00:00:21] Andrew: Nothing much, uh, good day today. We had a nice 8am recording to start off.

[00:00:26] Robbie: Ooh

[00:00:26] Chuck: Oh, perfect.

[00:00:28] Robbie: Gotta do what you gotta do Um,

[00:00:30] Justin: easier for me being on the east coast, so it's more like lunchtime.

[00:00:34] Robbie: I See, yeah, okay. Yeah, that's not too bad then

[00:00:38] Chuck: I almost have like the opposite thing because I'm on the west coast time, I'm in Arizona, and so, we try to do about 5 o'clock Robbie's time, which means I start drinking around 2 this time of year.

Maybe I was gonna do that anyway, so.

[00:00:54] Robbie: Yeah. Who knows? So, yeah. Um, if anyone has not heard of you guys or your podcast, do you want to give quick intros into who you are and what you do?

[00:01:03] Andrew: yeah, so we host DevTools. fm. DevTools. fm is a podcast about developer tools and the people who make them. we try to interview people who, like a range of people from like small DevTools people, just like random npm packages you might find around, to like people that are like, Just at the edges of computing in their respective fields and trying to, like, break things down.

So, like, we've talked to people like Jared Sumner from Bun, uh, but we've also talked to people like Anthony Fu, who is just, like, a prolific open source maintainer. So, like, we try to talk to a lot of people that are, like, the foundation of modern computing and don't usually get into the limelight.

[00:01:38] Robbie: Nice.

[00:01:39] Justin: Yeah. It's also fun just to talk to folks who are pretty early in the journey or working on something that's like relatively niche. So we kind of use it for an outlet sometimes too, to just like, Hey, this person's working on something cool. We should talk to them. So an example of this is we talked to, uh, one of our early episodes was with Paul Shen and he works on this thing called nato.

dev, which is a sort of, Nodal programming environments where you can like have these little code blocks and connect them, uh, with lines or whatever. I don't know. It's a really cool project, but it's not something you typically think of like, Oh, this is a standard dev tool, you know, but it's fun to sort of do those crossovers too.

[00:02:16] Chuck: And it's a way for you to get, like, a live intro into some of these tools, too. You're like, what is... whatever. And, uh, just have them on, they'll tell you.

[00:02:24] Andrew: Yeah.

it's definitely been a forcing function for me to just like learn about a lot of new things because it's like, it's hard to go into some of these podcasts without knowing anything about it. of the episodes that has stuck with me the longest is our conversation with Roonar of Unison.

And Unison is like, It's a crazy programming language, like, they, uh, bill it as the programming language from the future and that means, like, it has, like, six different concepts that are all kind of, like, mind breaking and just trying to wrap your head around those, it, it, during the episode, very hard, so I have to do, like, a lot of preparation to be, like, okay, like, what is this thing we're talking about, like, why, why would I want, uh, content addressable code, like, things like that.

[00:03:05] Chuck: Hmm, interesting. Why would I want content addressable code? Not that we need to go down that, but, uh,

[00:03:11] Robbie: yeah, I

[00:03:11] Chuck: Here I thought ZIG was gonna be... Yeah, I think, uh, I thought ZIG was gonna be the language of the future. Now you have me wondering. alright, well, speaking of whiskey, we'll go down that path. Get started with that.

[00:03:21] Whiskey

[00:03:21] Chuck: Today we're having the great Jones. Straight bourbon whiskey from New York. I know it said like, uh, the ingredients are grown in New York, so that's kind of cool. Uh, four year age statement, 86 proof, so not super hot. Uh, don't get to know the mash bill breakdown, but we know it has corn because it has to to be called bourbon.

at least 51 percent and then barley and rye. yeah, so we'll see. It's the first I heard of this one.

[00:03:46] Robbie: Yeah. It was an interesting shipping journey because. Clearly it's made in New York. The company we ordered it from also in New York, but I think like couldn't get it like it took them a while to get it shipped there somehow I don't understand, but yeah

[00:04:01] Chuck: It has a very medicinal look to the bottle for me. Reminds me of like, the look of ones that were still produced during Prohibition. Cause they were whiskey for medicinal purposes. There's like only so

many that were able to do that. Yeah, it's got that deco look on the label, so I like that. It's kinda cool. let's see here. Batch number one. Whoa. Bottle 79, 000 something. Wow,


[00:04:25] Robbie: like cherries to me

[00:04:29] Chuck: Mmm.

[00:04:30] Andrew: I do not have, uh, such a refined nose.

[00:04:35] Chuck: You know, you know, you've bought it. I love it because we are completely full of shit. We also don't know what we're talking about. But if you use words, descriptive words, people tend to be like, Oh yes. Uh huh. I'm getting some notes of a Wrigley's chewing gum. Um, you know, I don't know.

[00:04:53] Andrew: Yeah, I went to a fancy dinner with my now fiance and we got the wine pairings and the thing that stuck with me the most from that dinner is he described one of the wines as tasting like a barnyard haystack and just every time I get a wine that's how I describe it now.

[00:05:13] Chuck: Hopefully a clean haystack. I don't know. You know

[00:05:16] Justin: The open question here is, was it

[00:05:18] Andrew: Uh, it definitely tasted like K. Uh, I'm not much of an alcohol drinker, so it might've been good.

[00:05:25] Justin: Hmm.

[00:05:26] Chuck: right. Well, that's fair. Um, yeah, I get a lot of cinnamon on this one, actually. I smelled a little fruity. it smelled like nutmeg to me, but now that I'm tasting it, it definitely has a, like, cinnamony forwardness to it. Yeah, yeah. So, an earthiness in there. Maybe even a little, like, Baker's chocolate. You know, that bitterness that is in, like, Baker's chocolate. Yeah, because I smelled, like, some sweetness there, but I think now that I taste it, it actually has a little more bitter. Not that I'm saying it's bad, but it's definitely punching above its weight in terms of, like, the burn, too, because I would think under 90 proof normally has a softer kind of, uh, feel in the mouth and not so much burn, but this is actually, I think it might be the ride giving me some burn. you can make up words and sound good. I tell you, I'm telling you, whatever it tastes like to you is, is right.

[00:06:24] Justin: I always love listening to connoisseurs just, or people who just like are into something, talk about the aspects that they see. And, you know, it's funny because any refined taste, like in any hobby or any like pursuit, you find the same sort of thing. So it's like, some folks can talk about tech in a way that's like very granular and very detailed and like, you know, color a perspective in a way that you're like.

Okay, but that's just like a framework. I don't see all these things that you're talking about or, you know, food or coffee or whiskey or whatever. You know, it is interesting just to, I don't know. I think the passion always spills out and that's always fun.

[00:07:02] Chuck: Yeah. Yeah. No, I dig that. Yeah. A lot of, there's plenty of coffee drinkers that can pull a bunch of those similar like flavor notes and nuances out whiskey drinkers. And then Andrew, you were mentioning doing like a food pairing there. You can do food and whiskey pairings and stuff too. Just like, uh, Oh yeah.

There's whole like sites and blogs around that of like good things to pair. Different whiskeys with, like, little, uh, hors d'oeuvres, or whatever.

[00:07:28] Justin: So here's a question for you. How do you develop good taste?

[00:07:33] Chuck: Ha ha.

[00:07:35] Robbie: Well,

good is relative, right?

[00:07:37] Chuck: yeah, good is relative, right? Exactly. So, I mean, I know what I like, I don't know what you like, right? I do know different things that, like, tend, like, in the whiskey world. I'm sure you're, like, being specific to that. And I know ones that tend to like anybody who's at least interested in alcohol or interested in whiskey, I can make recommendations of like, well, everybody tends to kind of like a, B or C and that's okay.

And that's a direction you can kind of connect, explore, but then things deeper beyond that. I mean, obviously one facet of it is try a lot of different things. This podcast has given us a vehicle to do that, but I, yeah, it would just be like years of drinking and trying different things and getting into, uh, what you like and what you don't like.

And then also going and do like distillery experiences. I think that kind of helps like drive knowledge a little more being around folks that have been in it for a little longer too. And they start to give you more of a vocabulary to speak about. And then you can use that when you go to like the liquor store.

I want to try a different rye and I liked this one and it had notes like this for me and then they can kind of lead you to. So really just, just like with engineering, right? The more exposure you have, um, the more experience you have, you know the things that you like to work with and don't like to work with and, and what you're looking for in tooling.

I mean, I would say it's just like that. Um,

[00:08:59] Robbie: yeah, yeah. I would say it's, it's very similar to like becoming a senior engineer. You don't just like. Oh, let me do these five things and I'll be a senior engineer. You have to kind of like feel it and know like, Oh yeah, okay. I understand what I'm doing now. Um, the same with whiskey. Like, you know, it'll just hit you eventually.

And you'd be like, wait, I know like this and that about whiskey and like what I like and what I don't like and how to pick ones that I would like now. Like, I didn't feel like I learned that, but somehow I know that. So.

[00:09:27] Chuck: no. So now we're going to introduce you to the highly, complicated and nuanced scale of whiskey that, uh, we use on the show. It's a zero through eight tentacles. Zero being, this is horrible, I don't want it anymore. Four being, yeah, this is fine, you know, it's not great, it's not bad. And then eight being like, this is amazing, I'm never going to drink anything else again, get rid of water. probably not that strongly. We tend to, like, categorize them together by a whiskey type, but it can really just be, like, out of alcohol that I've had, this is how I feel about it. So, and Robbie's gonna go first and show you how it's done.

[00:10:06] Robbie: yeah, I don't love this one. I don't know exactly why. There's like, some kind of bitterness, maybe like the baker's chocolate you were talking about, that's like, hits me at the end. So I don't like that finish. Like, the flavors until the finish are pretty good, but because that finish is harsh, I'm gonna give it a four.

[00:10:22] Chuck: Justin, Andrew, do either of you feel confidence around your own personal rating here?

[00:10:28] Andrew: I think I agree with a four. It's, it's nothing to write home about and they're like, didn't knock, knock my stock socks off. I don't, I don't think I'm a whiskey convert, but I, I wouldn't just throw it down the toilet.

[00:10:37] Chuck: That's fair. You could at least use this in a cocktail or something fun.

[00:10:40] Justin: I've had some other whiskeys, uh, I'm no, by no means a whiskey connoisseur, and I've definitely had whiskeys that I've liked less than this, that either the, flavor profile just wasn't right for me, or they like were a little too strong, but I feel like this strikes a decent for my palate, so, again, not my favorite alcohol, maybe, but I would say maybe a five.

[00:11:02] Chuck: Yeah, I think that's fair. Yeah, so, in the bourbon range of things, I think flavor wise, like, I was expecting some things out of the package. I was like, this is all kinda hitting well for me, visually. But, uh, it's not... blowing me away in any way. And then there are certain flavors that I'm like, eh, I'm not loving it.

and then I don't recall what this one costs. I kind of take cost into account too. Like if you're going to charge me 50, 60, 70 for a bottle of whiskey, like. It better be a lot better than the 25 Buffalo Trace or, Maker's Mark that you can go to the grocery store and get or whatever. So, to me, those are more like baselines to look against.

So, it probably is a 4 for me. It's like, yeah, it's not bad. It's not my favorite. And for 25 I can get better stuff. So, 4 is probably as fair as I can get.

[00:11:59] Andrew: What is your favorite whiskey? Like what, what would be like the best thing for me to try and like, kind of set a stage for my whiskey palette.

[00:12:07] Chuck: Well, as a senior engineer, I'll tell you, it depends.

[00:12:12] Andrew: Of course.

[00:12:13] Chuck: So, well, what, okay, you like wine, I guess, at

[00:12:17] Andrew: Uh, I'm more of a pop man myself. Uh, but

I doubt I dabble in, uh, things I can drink too.

[00:12:24] Chuck: Yeah, yeah, wow, so, fair enough, kind of different, the same, but different. Um, but I was just trying to, like, see if you are gonna have, like, go have a cocktail or go have a drink, what do you, what do you choose normally?

[00:12:40] Andrew: since I'm not like an alcohol person, I just read the description and the description that speaks to me. I, I guess I kind of like tequila y things, uh, but

[00:12:49] Chuck: Okay.

[00:12:49] Andrew: very few opinions.

[00:12:52] Chuck: Right, right. I don't know. I feel like then maybe some of the, like Maker's Mark is an easier, whiskey to choose because it's weeded, which means it not only has corn in there to add sweetness, but then the wheat will kind of mellow out any rye or whatever else that's in the mash bill. So it's, it's kind of a good, easy to get reasonably priced one that I would suggest to many people.

And then you can make. A simple cocktail out of that, because my guess is drinking straight liquor, also not high on your

[00:13:21] Andrew: Yeah, I had to, had to order this glass off of Amazon cause we didn't have any, anything like this.

[00:13:27] Chuck: Yeah, yeah. So like, you know, something like that and then making, you know, even like a whiskey sour or something like that to balance the notes out a little for you. Again, not to have like too much alcohol burn. You probably would want some sugar or some kind of sweet flavor there. And that's a pretty simple one to make the ingredients yourself too. Makers Mark. Go Makers. And if you find yourself in Loretto, Kentucky, which I'm going to guess may or may not happen. Anyway, it's a very beautiful property. it's like out in the hills of Kentucky. It's like this old farmhouse kind of look. And it's just like a really pretty place to go. And you can do the whole dip your own bottle thing too.

They actually have some Chihuly, art installation in the Rick House there. So, it's kind of cool. Fun facts for y'all. Alright, well we can move on from drinks.

[00:14:15] Robbie: Yeah, let's do it.

[00:14:17] Chuck: Okay, we'll probably move into hot takes. We at least gotta cover our hot takes. I


[00:14:21] Robbie: we should

[00:14:21] Chuck: I can't share

[00:14:22] Inferred types vs explicit

[00:14:22] Robbie: we should rename it. Lukewarm takes officially because they're not that hot. But let's do it either way. first one, inferred types or explicit types for TypeScript.

[00:14:33] Andrew: Senior engineer, it depends, uh, most of the time just use inferred, but if the inferred type that you get is just like garbage, just, just add a, add a strict type. I usually as it instead of doing the return type up top, cause they're so far away from each other, but yeah, inferred all the way.

[00:14:52] Chuck: typecasting for the win, I love that.

[00:14:55] Robbie: ha

[00:14:56] Justin: so I'm definitely of the view that every piece of code you write is more to maintain. And like. I try to think about the value of anything that I add. So if I'm adding an explicit type, what am I trying to communicate? Usually if I'm at an explicit type over and over for a type, I'm trying to either really make the shape of something solid and known so that it's maybe, you know, if it's like a return of a function is like, this is the thing that I expect to return.

Right. I don't want to rely on what is inferred is like, this is what I expect. And if it deviates from that, then I want to know about it. and as much as possible though, I try to lean into inferred, just because, you know, less lines of code, less things you write generally is my preference,

[00:15:44] Andrew: Yeah, the best TypeScript to me is one where you're not writing types. So like, builder pattern style APIs, like, if I can just write JavaScript and it's strictly typed, that's the API that I want. I don't want to have to more types. It should kind of be invisible in my opinion.

[00:15:59] Robbie: Yeah

[00:16:00] Chuck: Yeah

I like that.

Git rebase or git merge?

[00:16:03] Rebase vs Merge

[00:16:03] Justin: I have

[00:16:03] Andrew: yeah, you go first, Justin. Mm

[00:16:05] Robbie: ha

[00:16:05] Chuck: Perfect.

[00:16:07] Justin: I'm all for merge. there's some folks who say that it makes your history, you know, messier or whatever, but I think it's a simpler mental model overall. It's not as easy to screw up, in my opinion. I found that over time, especially working with like different levels of experienced people, it is easier for me to walk through somebody through a git merge than it is from a git rebase.

And also just like folks who care a lot about git history, it like varies organization organization. So, I mean, my, my main answer to this is like, do what the organization does. If folks are rebasing then rebase, but if it's just like, Hey, we don't really know what to do, then I'm going to say stick with merge.

[00:16:49] Chuck: I mean it does add a ton of complexity. For sure, going the Merge route, which is probably why early in my career, when I was using, uh, Switched Over to get from Subversion, like, Merge was like, just made sense in that context, but then I was in an organization where you get browbeaten enough about not, doing that, you know, and learn Rebase, read the fucking manual, you know, all that fun stuff.

It used to be more pervasive in our, in our industry. So then, I've kind of been like, I have the scars. Everybody rebases now. That's what I say. I had to fight for this. You think I'm letting go? No way.

[00:17:30] Andrew: Yeah, in my opinion, uh, if it's a few commits, I'll rebase just to like, keep it like simple. Like I like,

I tend to use git UIs that are very visual and show you like the graph. So like visually, it's just a little more pleasing to see like, oh, my commits are in this clean state, but if it ever gets to a point where I have to like resolve multiple conflicts across a rebase, merge and get on with my day.

The, the real question to me is. When you merge into your repo, do you prefer to just merge it or do you squash and merge? And when I got to my current company, we squash and merge, which I think it's the battle. Do you want a perfectly clean git history where you can visit each commit and all tests pass and the app is in a perfect state?

Or do you actually want to preserve the context of every change in your repo? And I tend to want to preserve the context, cause like, sure I can rebase back to a PR, but if I get to that PR and it's, It's the PR where I changed a thousand things, all the granularity of what I was changing is lost and then I have to sift through one huge like squash down commit and I'm much more for like, let the history be useful.

Merge commits are there for a reason.

[00:18:41] Robbie: Yeah, I think my argument to that would be you shouldn't have a PR that has a thousand things, like that's the the solution to the squash and merge

[00:18:50] Andrew: Yeah.

[00:18:51] Chuck: Right. Plus, I'm, I'll do some garbage commits that could be for various reasons. Either like, most of the time it's, alright, I just want to save where I'm at. And kind of come back to this fresh later. Here's some shit, you know, whatever. And especially if you're in organizations that have like pre commit hooks or post commit hooks or, they're looking for a conventional commit.

Style messages and we'll force things out and all kinds of crazy stuff like that, that even adds another layer of overhead where I've gotta like, be extra clean locally while my work in progress is happening, and I find that kind of

[00:19:28] Robbie: Yeah, I think you should be able to do whatever you want locally. All the things should be enforced CI side. Cause I hate when I'm like, let me commit this, and it's like, no, no, no. Like,


[00:19:39] Chuck: Is it French?

Is your machine French? Talking to you? No, no, no. I am Pepe Le Pew, your... Anyway.

[00:19:46] Andrew: Yeah, I'd never agree with the CI stuff, but like there are valid use cases for like having a lot of changes in one commit, say you're developing a long live feature branch and you have multiple people committing to that feature branch via PRs into the branch. If I merge that into main and lose all that information, like sure it might be a thousand different changes, but they could actually have a thousand different PRs attached to them.

So like. Keeping history is just always better in my mind, but yeah, I am definitely of the mind, do not enforce my commits locally. I've literally not made contributions to projects that use things like commitizen because like I'd spent 10 minutes trying to commit and it just didn't let me and I'm like, well, I guess my time is better spent elsewhere.

[00:20:27] Chuck: Exactly.

[00:20:29] Justin: That's fair. A spicier take on this. I don't actually think Git is good.

It is a utility and it is good enough for most cases, but like the UX for get is not good. And the reason why I say it's not good is because I have had to mentor many, many, many people. And I've had the same comment over and over again.

It's like, well, that's complicated. Don't worry about it right now. You'll figure it out later. And. The amount of times that I've had to pair with someone, they're like, I screwed something up. Oh God, I don't know what to do or whatever. It's like, of course there's documentation out of there, but these are not signs of a good tool and, and no shade on Git from like a holistic perspective, because like I said, it is good enough.

It does a lot. it really has brought us forward,

but I think there is space for innovation here, especially from like the UX perspective.

[00:21:27] Chuck: So what you're saying is, go register a domain name as quick as possible. Because the appetite for improved DX in developer tools has grown quite a lot in the last few years, I would say. So like, anything you want to go right and rust to make things faster for developers, there are people interested in that.

[00:21:48] Justin: Unfortunately, that's a hard one. That's a really hard

[00:21:51] Chuck: oh, for sure, for sure.

[00:21:53] Robbie: Yeah.

[00:21:55] Chuck: I'm sure someone smarter than me could figure it out, if they really... You just gotta get stuck in the right places, and then someone gets inspired. is, uh, This is another Twitter tech Twitter thing, which is saying that there's a knowledge gap when folks are learning, web development or just, you know, coding in general, that get, isn't a part of that, like get, isn't part of CS programs and get, isn't part of bootcamps really. It's always just whatever you need to learn to get through that module specifically.

So there's no learning, of that tool really.

[00:22:26] Andrew: Yeah, well, it's kind of the problem with CS degrees in general, though, is that any modern tooling, even if modern means a 26 year old tool, like, that stuff's just not taught in school. Like, I wish I had known the value of Git before I got into the professional world. just the ability to go, it was okay yesterday, it's fucked up today, what changed?

And like, know what changed? That is... A crazy, crazy great power to have, and just not doing that for so long. I got myself into so many bad situations because of that.

[00:23:01] Chuck: You basically learn Git by, like, screwing

[00:23:04] Andrew: Yep.

[00:23:04] Chuck: up. And then you have to figure out how do I

[00:23:08] Robbie: Yeah. And then when you fix it, you hopefully don't rebase, uh, rewrite a ton of history, break everything, and then force push it up.

[00:23:15] Chuck: And then force push. I was gonna say, there's the big thing. Force push. Don't. Force. Force with lease. If you ever do that. That's

[00:23:22] Justin: Learning to run on broken glass, kind of.

[00:23:25] Chuck: it. Exactly. That's a good analogy. Alright.

[00:23:28] Robbie: think subversion was better, but GitHub killed that because you got to use GitHub.

[00:23:34] Chuck: I

[00:23:35] Justin: sure I agree with that necessarily. Like Mercurial had a good start. you know, and I think the, the sort of DX for Mercurial was, was better. Their commands made a little bit more sense, but even that was still not a. Uh, problematic in, in its own unique ways. Um,

[00:23:51] Andrew: Yeah, Purrforce


[00:23:52] Justin: just honestly think, I don't know I

don't know Perforce.

I had to use Perforce when I first started, and that has its own unique problems.

[00:24:05] Chuck: See, you know what's wrong. You can make the thing that's right.

[00:24:09] Robbie: Uh, Tailwind or Vanilla CSS?

[00:24:11] Tailwind vs vanilla CSS

[00:24:11] Justin: It depends

[00:24:14] Andrew: I, I like Tailwind a lot personally,

it's really fast, like a lot of people are like, Oh, you shouldn't learn this before you learn CSS. And I kind of like disagree, like the Tailwind docs are better than the CSS docs. Like you can go to the Tailwind site and learn all about what display block is in like human readable terms.

So like to say that it's bad for learning cSS, I would say is wrong. The real question is, do you like utility CSS at all? And I, I really tend to like it. my answer isn't as simple as like never use like CSS modules or anything. I think, uh, utility CSS is great at being a utility. So what I mean by that is for the design system I built for Descript, like there's the design system and then there is also utility CSS and you use the utility CSS.

To lay out the components because like when, when you're building a design system, I think like certain things of component shouldn't care about like width and margin and how I'm placed within my parent that should all be on the parent and being able to use just like utility CSS classes like flex item center justify whatever like the DX there is just like so nice but like

I wouldn't say never use CSS because like frankly some things are a lot easier to write in CSS than they are in tailwind.

[00:25:28] Chuck: your answer kind of makes me think it's very much akin to the whole, You really shouldn't, learn React, you should learn JavaScript, and then figure out how, you know, that

[00:25:39] Robbie: Yeah. Depends on

[00:25:40] Chuck: for your, well, yeah, like, so, conversely, obviously, they both can be tools that make you more productive than Xero, right?

So, there's that positive aspect to it, so it's like, are you trying to just build a site and figure out how to build a site? Well, Tailwind will help you do that. React will help you do that. Yeah.

[00:25:59] Andrew: Yeah, a person we recently had on the podcast, uh, Aiden by, he interestingly learned react in a very backwards way. He built out his own, all his own like vanilla JavaScript stuff and then got to the point where he was like, Oh God, updating the Dom takes so long. And then he discovered the V Dom and then he discovered react.

So like he worked his way up. But like, I don't think that path is really an easy path for anybody to take. to throw a newbie dev into like what web development is and all of the hard edges of the native APIs. it is a little easier to throw them into something like react where you're like, Hey, you can go take this course and this course will teach you all you, all you need to know about learning react.

And then you can like branch out once you have something, you know, and like can put stuff on a page easily.

[00:26:44] Chuck: Definitely. There's the happy fast path, and then there's the happy know what you're doing long term path. Also, um, Aiden Bai, he's the million.

[00:26:54] Andrew: Yep.

[00:26:54] Chuck: js person. Yeah. I mean, I think he's one kind of like Jared Sumner, where like, there's some really unique engineers out there who can take some special paths,


[00:27:05] Justin: He's 18.

[00:27:06] Andrew: He just went to


[00:27:08] Chuck: uh, so, right, right, and uh, I was going to say, at 18, you know why I know so much about whiskey? It's because at 18 I was having all of it, around me, everywhere, so, um, you know, we took very different paths,

[00:27:24] Robbie: Yeah,

[00:27:26] Andrew: it's amazing how many of those people that we met through the podcast, where it's like, this guy just locked himself in a room for 100 hours every week for the past year and came out with this thing. And it's just crazy the things that come out of that. Like on Twitter, I recently saw this new Braid browser, which is a collaborative browser.

Like he said, he saw Figma and was like, why doesn't the browser just do that? So he rewrote a browser by looking at, reading all of Chromium and rewriting the browser so it could be like collaborative first. And that, yeah, you can't do that just like piddling on a side project for two, three hours every few days.

That just doesn't work.

[00:28:00] Chuck: no,

you also can't do that with two small kids, my life is

[00:28:04] Andrew: yeah.

[00:28:05] Chuck: you know, my innovation is this. Podcast,

[00:28:09] Andrew: Mhmm.

[00:28:09] Chuck: anyway, innovation speaking of, or a regression of innovations, kind of how you think about it. what do you think about builds or no builds for web apps?

[00:28:18] Builds vs no builds for web pages

[00:28:18] Justin: I think that depends on what you're doing. Uh, I mean, not to be cliche with this, but

there is a tremendous value in iteration speed. So if you're using a build. You should be cognizant of its performance and its impact on the engineers who are developing features. as someone who has introduced slow builds to an organization unintentionally, I know the pain and the cost of that.

So if you can get away with a no build set up. That meets your criteria of like performance delivers the feature sets you want. And if it matches the organization coding style that you're going for, then do it. Of course, anything that you can take out, and still move on without too much pain and is worth it.

But the real caveat here is that builds are valuable, like we do them because they give us features and functionality that we need in some way. If you ask me, do I give the users a better experience or do I give our developers a better experience? It's going to be the users every time. mean, cause at the day, if you're building a product, you like need to build a product in such a way that your users have a delightful experience.

Hopefully, you know, and if that means introducing a build, so you can eke out some more extra performance or, you know, do whatever, then it's worth it.

And then arguably sometimes for, for DX, it's like, Hey, you know, introducing TypeScript, depending on your runtime or whatever might require some building, but usually it's worth it, you know?


[00:29:52] Chuck: Yeah. And if the user gets a re you know, reduction in the number of artifacts per release cycle, blah, blah, blah. You know, there's a, there's ways to package that to have, you know, front benefit too. I don't know. We're all going to be riding rails again in the next five years.

Just, just so you know.

[00:30:08] Justin: I'm hoping for Elixir, honestly, myself,

[00:30:12] Andrew: Yeah.

[00:30:12] Justin: maybe Elixir with types, you know,

[00:30:15] Chuck: Yeah. Elixir Phoenix kind of stuff. It'd look cool.

[00:30:19] Andrew: Yeah. PE people hate their bundlers for the most part. Like a lot of people don't like webpac, but I think Webpac can do a lot of really cool things.

configuring it, yes, can be a drag and learning like how all of that fits together. But like if you learn to master that, you can do some really cool things.

Like if you look at Mod Module Federation, let's see you module federate in an app without a bundler. You really can't, like, you don't want to, and the beautiful part about module federation, I'll give a little short explainer of what it is, is say you have a big app like Lululemon and you have a whole bunch of teams, with module federation, you can split up your app into little micro apps and then module federation is a layer within Webpack that allows you to import your micro apps just like normal code.

you can have a team manage the nav bar UI, but in code. Uh, you only have to import the navbar UI, but it could be somewhere else. It could have its own deploy step. It could have its own CI, all of that. And all of it's enabled by webpack doing really cool things. Like from a DX perspective, all you have to do is configure webpack to do this thing, and now your imports can magically resolve from remote URLs.

You can change those while it's running. So like all of that stuff's not like you could build that in user land, but you would never want to build that and maintain that.

And the fact that you can use a tool and just configure it a little bit differently and get this like new capability out is, I think, really cool.

[00:31:43] Chuck: But that's a, that's a build time tool, right? That's not runtime bringing

[00:31:47] Andrew: No, it's run, it's runtime.

so module federation basically like hacks the loader. So it makes like a loader that can load from remote things. So what you could do for your like Lululemon micro app architecture that has, let's say, a hundred different apps, you could have literally a JSON file on your backend that says, okay, navbar points to version one.

this editor part of the app points to version 2. While people are running the app, uh, they get those things. Then you go, oh shit, our editor needs to roll back one version. You just change that file. The next time someone requests that module, Module Federation goes, oh, there's a new one. Let's go get that one and put it in the module graph.

Without doing any builds, you can actually redeploy different parts of your website.

That guy, Zach Jackson, has a, like, back end counterpart guy, who's, like, module federation on the back end, and that area is even, like, crazier, like, he was like, yeah, you can just have, like, one lambda, the lambda kind of runs webpack, and then you can request things of that lambda, and dynamically that lambda can go, oh, you want me to go do this thing, I'll go fetch the code for that, run it for you, have it primed for the next person, and still just be one lambda doing, An amount of things.


[00:33:00] Chuck: Yeah.

basically. Right. That's, that's very interesting. I'll have to listen to that episode of yours.

[00:33:07] Andrew: Yeah. His work is very interesting. He just left Lululemon actually to go work at ByteDance, because ByteDance is doing like a crazy amount of cool developer tool things right now, and it like, I can't blame him. Like RSPack, I honestly think if there's a future for Webpack it's RSPack.

[00:33:24] Chuck: So you're saying, BUN isn't going to replace it all?

[00:33:27] Andrew: if Dino hasn't replaced it all yet, then bun's not going to do it very quickly. Uh,

[00:33:32] Chuck: Right.

[00:33:33] Andrew: I, I, we talk about bun a lot and I like how bun is like pushing the field forward and kind of like lighting a fire under other people to be like, Hey, we could have really cool DX. We could have really fast tools and it's making other people go.

Yeah, we probably could. And then, like, looking at things and making them better. Like, I just saw a PR land in PMPM where the guy was like, Oh, I noticed that Bun was doing this thing to make things fast, so I did it too. as, as Justin likes to say, he said on a bunch of episode, episodes, uh, a rising tide lifts all ships.

So, like, someone doing better is going to make other people do better, and it's only good. But do I think Bun will take over? It's a long shot. They want to do a lot of things.

[00:34:15] Chuck: They do want to do a lot of things. it's VC backed though, so there's, you know, they've got some engine behind that. And I know their intentions are to get into hardware. So.

[00:34:25] Justin: Yeah, the VC back things of blessing and a curse though, because it's like platform, we actually had in the episode recorded today, we had this conversation platforms themselves are hard to monetize, like code platforms, like, you know, like node or Dino or bun is like those products by themselves for a lot of development effort and they're hard to monetize.

Usually it's the services around those that are monetizable You know, there are VC pressures that exist that after a certain point, especially in this sort of macroeconomic environment, after a certain point, people are like, you got to make money. You got to show us you're on the path to profitability or whatever.

I don't know if you, if you take, if it takes tens of thousands of man hours to sort of produce this reliable, robust runtime, then you can really eat into your funding or whatever. And, you know, that's not to say that Bon or Dino or anybody else can't do it. Um, they definitely can, but it's just, I don't think as a given at any point.

[00:35:21] Chuck: Yeah, no, I definitely don't think it's a given for sure. And, you know, to your point, Andrew, things like Bun and Dino have pushed Node forward a bunch too, right? And Node is what we trust and runs all over the place and there's been things that we've asked for there and now we're getting them. And then some.


[00:35:45] Andrew: Yeah.


The interesting part about Bun is we haven't seen the product yet, like Bun is like the tech. They're still building the tech for their product. Like I think that the most illuminating, uh, bit of our interview with Jared was where he was talking about the future and like this work is to enable cool things.

He was like, what are the cool things we could enable if we had just like A lightning fast JavaScript thing. Like, how could we build our applications differently? And I think that's where the value, like the actual product of bun will come. There's, there's going to be a platform. It's going to be doing something special that enables JavaScript to be run in some new, interesting way.

We just haven't really seen it yet.

[00:36:22] Justin: In the meantime, the value add is pushing folks forward. So like the NPM compatibility and Dino. Was really motivated by bun, like bun coming out and they were like, okay, no, we can do this too.


[00:36:34] Chuck: Why didn't we do this before? Oh my

[00:36:36] Justin: yeah, that just the ecosystem of everybody pushing every everybody else to be forward.

We seen this in like the framework wars, right? It's just like, oh, well, we can do all these things. And the best frameworks, in my opinion, learn from what other folks are doing. So I was involved in the early days of you. And I got to see like Evan would take ideas that came out. It's like, Oh, reacted this virtual Dom thing.

We can do that too. I was felt did like this incremental compilation, like only deliver what you need. It's like, we can do that too. the best tools over time take what the other folks are innovating on. They use those ideas and they continue to iterate and improve on them. And I mean. That is human innovation, right?

That's, that's how we are at our best. It's still good to see a lot of folks, you know, iterating in that space it's also just hard because. There are things like specs that are important and, and node takes those very seriously and it, and it slows no down, but you can rely on the fact that like, if node implements a feature that's across the browser or node, then it's going to work consistently how you would expect if you read the spec, whereas like bond, maybe they don't care.

They're like, Nope, this is our behavior. This is what we'll do. We'll make it possible to run ESM and. common JS in the same file. And like, we don't care that that doesn't really meet the spec. and you'll just run into different bugs and like different issues. And, you know, for folks on that platform, maybe that's fine.

[00:37:56] Chuck: Well, I think we might be a little remiss if we did, if we were only technical. And I know you guys want to have a shot at, doing your format and your kind of thing. But I mean, we're all podcasters here, right? said, uh, you've been doing yours two years now?

I think we're coming

[00:38:10] Andrew: Two and a half years. Yeah.

[00:38:11] Chuck: Nice. So for other folks in the tech, in the tech podcast space who, don't get paid by Sentry, what, what are some tips and tricks you would, you would give them?

[00:38:21] Andrew: I've learned a lot about marketing while doing a podcast. I've had to be exposed to a lot of marketing tools. I'm shocked at how much they all cost. But it's a very big market. Uh, my biggest tip would just be like market the hell out of yourself, but I, I can't say that. I always thirst for more success, so I don't know if I'm the best, uh, person to ask.

Cause I, I don't feel like we've gotten there to be honest. Uh, we've built a great podcast. We have lots of listeners, uh, but by no means are we where I want to be.

[00:38:52] Justin: we've learned some basic things. So for a while we started marketing for an episode on Monday and really, really still on fire Friday. And I don't think we put too much thought into exactly why we were doing that, but folks would continually ask us like, Oh, where's the episode? Can I listen to it?

And then we changed it. It was like released on Monday and marketed all week and like, Oh, suddenly this is so much better. So, I mean, sometimes it's like, You know, little things like that, that maybe you don't put a lot of thought into that actually is, is rather important. Beyond that, I think sustainability is, is really key in this.

So it's like, find a format that, , you can work with. , when we first started doing this, we were, we first started weekly episodes and it like was really hard,

uh, because we're doing everything ourselves. Yeah. And then we went to bi weekly. We're now back to weekly, but we have an editor that we pay


[00:39:47] Chuck: I was going to ask that. Cause I I recall Andrew saying like, I think you were putting in like four hours sometimes on

[00:39:54] Andrew: Yeah, what I would do is like basically the week a podcast would come out, I'd spend like basically two hours a day up until the podcast after work doing my things,

but now we have the editor and my role is like, I still do a lot of editing, but it's been able to free me up to do things in different order.

I schedule all my like promotional posts the Saturday before it all happens. I was doing all that the day of that nice optimization. We've been able to get out like long form clips cause I have like a little bit extra time. So I post those now too. an editor definitely helped out a lot.

I'm going to plug my own product here. I work at Descript and, , honestly the reason we started the podcast was cause I started working at Descript. I announced it on Twitter and then Justin messaged me. He was like, Hey, do you, do you want to start a podcast? And I'm like, uh, I guess.

And then I was, I was like, okay, what, what's a name we could go with? What's the only thing that I know that me and Justin share in common? Oh, DevTools, DevTools. fm idea. It was like, it's crazy how fast we went from like no idea to idea, but Descript. Has been a big part of just a starting the podcast and us like doing the podcast.

Like I use the podcast as a dog fooding exercise. So like, I, I didn't want an editor for a while. Cause I was like just starting my, my journey here at Descript. And I wanted to be like in the product and like finding bugs and like learning it. So like, just as a tool for that, it's been amazing, but it's also helped improve Descript in various ways.

[00:41:23] Robbie: Nice.

[00:41:24] Chuck: kind of going to ask that is, uh, from two years ago when you started the podcast to now, obviously Descript is also improved, probably added features, evolved. you can pimp that out a little bit, like you know, you're starting, you would recommend Descript or a tool like it because it cut out ABC thing

for you,

[00:41:43] Andrew: if, you're really low touch on your podcast, you could throw it into Descript, you could remove all the, like, white spaces, add in a few templates for your intro, your outro, and then export it and be done with that and have, like, a transcript and a nice video.

Within like 30 minutes,

but of course like there's there's levels to that. I think the earliest teacher I was proud of building here at Descript was one that like affected me instantly Uh, when I joined Descript, we had just gotten into video video workflow was just like, very lacking.

So like, we have a Riverside podcast also, so we have this like, multi file, have to switch between speakers as their on screen problem. And in Descript, before I joined, it was like, five clicks to, for one clip. To change it for the person that was on screen and when you have a timeline with lots of cuts, there'd be thousands of clips.

So I would spend an hour, two hours going through and assigning the clips to the right people that were on the screen. Then I got fed up one weekend and I was just like, I'm just going to code this.

Now it's one of the most features I'm most proud of. People are writing constantly and be like, Oh, I could cancel my subscription to this entire other service because you now do this one feature that I needed.

And it's just one click.

[00:42:57] Robbie: We

are, uh, excited for, uh, all the things you're doing, because we are going to not have editors at the end of the year and try it all ourselves. So, we will play with that and give you feedback.

[00:43:10] Andrew: Heh.


[00:43:13] Justin: Godspeed on that related note. so if anybody out there listening is thinking of starting a podcast,

we've learned some basic things. So for a while we started marketing for an episode on Monday and really, really still on fire Friday. And I don't think we put too much thought into exactly why we were doing that, but folks would continually ask us like, Oh, where's the episode? Can I listen to it?

And then we changed it. It was like released on Monday and marketed all week and like, Oh, suddenly this is so much better. So, I mean, sometimes it's like, You know, little things like that, that maybe you don't put a lot of thought into that actually is, is rather important. Beyond that, I think sustainability is, is really key in this.

understanding your capacity for, spending time on this sort of thing, and how that affects your format. You should be very honest with yourself about that. So, you know, I am infinitely grateful for the work that Andrew does because I don't have the patience to sit down and do multiple hours of editing.

And I, I tried a lot in the beginning and, you know, I'm a little bit of a perfectionist. So I would spend, you know, where it would take him a few hours. I would spend like six hours just going over the transcript or whatever. And it was hard for me to sort of let that go, and just like do less, I don't know, just how my mind works.

And as I'm looking at, I'm like looking at spending about another podcast that I'm doing solo, I'm realizing that there are certain things that I can and can't do, and, you know, leaning towards this idea of maybe more like live streaming where there's like minimal to no editing, and then it just gets out like.

Right. As you record it is probably a better workflow for the style for me to be consistent with it, you know, cause I love like meeting people and talking to people and stuff like this, but like the nuance of production is not something that I am good at or interested in or whatever. And, you know, just being honest and upfront with yourself is like, what time do you have to give to something?

Can you make this sustainable or whatever, and, you know, figuring out release cycles and everything else should really come from like, how much does this give me joy? How much capacity for production do I have? And just, you know, be really brutal and really honest with yourself about that.

Cause that's like really key to making something successful.

[00:45:25] Chuck: Yeah. I would say that's, uh, that's very sound advice. And I look forward to your Twitch channel. So.

[00:45:32] Justin: Yeah.

[00:45:33] Chuck: Live streaming.

It definitely takes a certain individual for live streaming. I feel like I need to be at least mildly edited.

[00:45:41] Robbie: Oh, yeah, we

can't let Chuck be live. It's uh, not something we


[00:45:45] Chuck: Yeah, it's, uh, it's in my contract. My ship shape contract actually says I'm, I'm not allowed to speak to other humans live where it's publicly

[00:45:53] Andrew: Yeah, there's been a few times where I'll say something and be like, oh, I want to edit that out. Heh. Heh.


[00:46:00] Chuck: Yeah.

Uh, I don't think I've said that personally, but I'm sure Robbie's been like, I got to get

that out of there. And then I don't listen to them. I mostly don't, I don't want to hear my own voice anymore. I was here. I had this conversation. I don't, I don't need to hear it. I'm sorry. You have to hear it.

But, uh, and so I don't listen later.

[00:46:20] Andrew: Yeah, I went on SyntaxFM and I felt the same way. Like, I didn't even listen to the episode. I was so nervous leading up to it and I was like, oh, that's, that's all the nerves will be. And then the episode, like, was recorded and I was like, oh my god, now I have to worry about it until it comes out. Heh.



[00:46:36] Chuck: it's

out there and like two years later, somebody's gonna be like, Oh yeah, I heard your episode

[00:46:41] Andrew: no, we've already had people come interview at Descript who are like, Oh, I heard his Syntax FM interview. It sounded like an interesting place to work.

[00:46:47] Chuck: Oh yeah, yeah, definitely. I'm sure it is.

[00:46:49] Robbie: So before we, uh... Kick it over to you guys for those, uh, questions you wanted to ask and stuff. I have one question that I was curious about. , you guys post a lot of text stuff and not a lot of whatnot on, uh, your feeds. So, um, well, I guess two questions here for you. One, how are the sales of the TypeScript Metal hoodie?

[00:47:13] Justin: Abysmal.

[00:47:14] Andrew: yeah, no, our, our merch

[00:47:15] Justin: Better than everything else, but our merch

[00:47:18] Andrew: I, off that design, I've made maybe like three or 400, but, uh, I don't really care about the money there all that much. Like I, that, that I literally made just start a quarantine. I was like, I want this. And I went on Fiverr and like contracted a guy who did metal band logos.

And I was like, this is awesome.

[00:47:37] Robbie: Nice, nice.


[00:47:39] Justin: don't market merged in the same way, so we don't like turn a lot of merch.

[00:47:44] Robbie: yeah,

that's fair. So, uh, yeah. The one other thing that we like to ask everybody is, uh, if you weren't in tech, what other career would you choose?

[00:47:51] Justin: I would be a carpenter and most of the time I think I would work on mixed electronics, woodworking projects, specifically lighting has always been something really interesting to me. So doing, uh, like wooden chandeliers or, or standing lamps or stuff like that, I think that would be my jam.

[00:48:09] Chuck: Mm

[00:48:10] Andrew: Uh, if it's a job that goes nowhere near a computer or an electronic, Lately, I've been thinking I'd want to be a butcher, like, I've entered the, like, I turned 30 recently and I entered the phase of my life where I want to buy large chunks of meat and then cut them up for my own consumption, uh, so, that just got me thinking that like, hey, maybe a butcher would be fun, you just like, you, you learn this skill, you get really good at it, and you get to eat steak all the time.

[00:48:35] Chuck: hmm. There you go.

[00:48:36] Andrew: There's no downsides.

[00:48:37] Robbie: Nice.

[00:48:37] Chuck: know where, yeah, you know how to get the best parts too.

[00:48:40] Robbie: Yeah.

Yeah, man, the primogen kind of does that. He's does tech and also has big freezers of meat. So

[00:48:47] Chuck: Right.

[00:48:48] Andrew: day. I'll have my big freezer one day, but, but for now, I just buy, uh, whatever's at the grocery store and cut it up for the next three weeks.

[00:48:57] Robbie: cool. Well, yeah, I want to

[00:48:59] Chuck: we pass the


[00:49:00] Questions for Chuck and Robbie

[00:49:00] Andrew: Okay, so, welcome to DevTools FM. No. Uh, so, uh, both of you work at the same, uh, like, agency, right? Or like, consultancy. You work at the same company?

[00:49:11] Robbie: Well, this is a complicated answer that you were maybe not ready for

[00:49:15] Andrew: Okay.

[00:49:16] Chuck: It depends.

[00:49:18] Robbie: So, yes, we had an agency for many years And uh, then agency work stopped existing. So I work for Art19 now, which is a podcast hosting company, ironically. yeah, so we, we got real jobs and um, stopped doing the agency work for now.


[00:49:35] Chuck: Right. So agency exists minimally. We both are W2s.

[00:49:42] Andrew: Oh, nice. So, uh, did that agency spin out any open source repositories and do you still maintain those?

[00:49:48] Robbie: Yeah, yeah, we still have a lot of open source. Um. So, yeah, we, the biggest one is Shepard, we also have Tether, both were acquired kind of from HubSpot, um, if you followed any of that before, they had those two, they, it, like, everything was based on Tether originally, and it was, like, Drop, Shepard, uh, I think there was maybe another one I'm forgetting, but, like, several things based on the Tether library where it's, like, where you could, you know, tie two DOM elements together, So, yeah, we, we kind of took Shepard from that and like, rewrote the whole thing because there was no test coverage.

So first wrote a bunch of tests and then like rewrote the whole thing in Svelte and, yeah, did a lot of stuff there.

[00:50:28] Chuck: Yeah. So it's the unopinionated, uh, application tour library basically. Cause it's really dumb. Okay. It does all the things you tell you, you, you tell it, and I know you like configuration.


[00:50:40] Robbie: Hmm.

[00:50:40] Andrew: You got me. so, uh, this is one we like to ask, uh, at the end of each episode now, or at least I do since, like, there's been many a spicy dev take on Twitter lately. Uh, for each of you, what is your spiciest dev take? I know Robbie's got some real spicy ones. They've gone off recently on, uh, the Twitter.

[00:50:58] Robbie: Yes. I mean, my, my spiciest one

like to be vague about it cause it makes things more spicy. Like you just, I just tweeted react as a mistake or was a mistake. And like, everyone was like, Oh my God, like losing their minds. And, uh, I was like, well, I'll explain it in each thread, but then no one reads the threads.

So they're like, this guy doesn't explain anything. And he just doesn't understand stuff and whatever. And I'm like, Well, I explained it like 15 times already if you go read it But yeah, yeah, so I think react was Originally a good idea for a little while so there was a mistake I will say I was wrong and just blanket saying that right But I think it has become a mistake is the more accurate thing is like hooks are really complicated Like JSX has never looked good in my opinion like yes, it's really powerful, but like it doesn't look good to me And I think things like Vue and Ember, and I'm less familiar with Angular these days, but like, things with their own specific, like, templating language tend to, like, look a lot better and, like, feel nicer to me.

So yeah, React being, like, it's made us all, like, really over engineer stuff. So it's like, you know, you've been like, oh, let me, how can I, like, Manually do all these things and like get every ounce of performance out of it. And like, um, this is kind of a long winded answer. Sorry. But like, bun is kind of similar where it's like, Oh, cool.

Like bun took all of this work to do. And it's like eight milliseconds faster or whatever it's like. Um, okay. Yes, it's faster, but like, does it matter? Like, I think we're at the point where we have all the tools are pretty good. And like, you should use what has the best DX in my opinion, versus What you can over engineer for two years, building your own bespoke react project.

Whereas you could just use Next. js. Like if you want to stay in the react ecosystem, use Next. js and you're done. Like if you want to, you know, use something that has not JSX, use Nuxt, use like whatever. So I think like the whole like thing that we entered into of everyone using hooks before there were any docs and then like, just over engineering the shit out of everything.

Really affected us badly, I think, as a fronting community.

And I think we need to take a step back and like use meta frameworks and tools to like have nice things in my


[00:53:15] Chuck: wait until, wait until you meet React server components.

[00:53:19] Robbie: I'm not going to meet that.

[00:53:22] Chuck: I would, I would argue that, uh, React isn't necessarily the start of over complication having written a backbone marionette app over a year plus, but, uh, I would say it obviously made it more pervasive and React became the jQuery of the DOM. In a way, and then, of course.

[00:53:41] Andrew: I think that's actually where React differs. So like a lot of this conversation has centered around web dev. The interesting thing about React is that it, it's not web. React itself is a generic library. We're talking, you're talking about React DOM, uh, React itself, the paradigms of React. Are transportable across spaces.

You can go to native, you can build a native app if you know react. , literally just the other day I saw react native apple vision os pop up on my feed. You can, you can create apple vision apps with react. So to say like react is complicated, but I don't think any other front end framework lets you take your knowledge to n platforms.

They're all based on one platform.

[00:54:26] Robbie: Yeah.

[00:54:27] Chuck: I would say just because you can doesn't mean you should. That's my spicy take

then. Is, yeah, cause that's the same argument as saying like that, great, you're a full stack engineer across any platform because you know JavaScript and React. Um,

okay, possibly. Right. Yeah, you do. but if, you know, JavaScript too, you can get down to the server side and start to write applications in that same way.

so in the example that you said, I definitely, I don't know anything about that. So I'm making a blanket statement, but that Are the implications the same as when I utilize that library in writing a web application? Versus writing something else on hardware versus, I'm in mobile or I'm in this vision thing, I don't know.

Like, are there performance implications? I can write a thing, and I guess I can bring skill to at least do a POC or something, but is it the best way to give the best user experience? I don't know. Anyway, maybe that's my spicy take. That and milk is for everyone.

[00:55:25] Robbie: Ooh, yes.

[00:55:27] Chuck: Milk is for everyone. Especially babies.

[00:55:29] Robbie: Yes. My son drinks a lot of milk many times a day.

[00:55:32] Chuck: Yeah.

[00:55:33] Andrew: Wh who's arguing about, uh, babies drinking milk?

[00:55:36] Robbie: well, not babies,

[00:55:38] Chuck: Not babies, but they, there were definitely folks arguing about milk and the signals that drinking milk

[00:55:46] Robbie: Yeah. Did you see all the people drinking milk on Twitter

[00:55:49] Andrew: I I didn't. I I missed

[00:55:51] Robbie: okay.

[00:55:51] Andrew: Twitter, apparently.

[00:55:52] Robbie: All right, well, well, yeah. So, so yeah, it was, uh, Primo told us about it. , 'cause we saw it, but we didn't really understand what happened and like. The thing is, there's a guy, uh, I forget his handle, and we can probably look it up later and throw it in show notes or whatever, but it's like, like, MilkyDev or something, so, Prime just always called him Milky, and then like, one time, just for fun, he just grabbed some milk and like, drank it on stream or something, it just snowballed from there.

Everyone would just grab a like jug of milk and drink from it. And it was this cool, fun thing for like a week where everyone was like, ah, ha ha, I'm drinking milk or whatever. And then someone like looked up the origins behind drinking milk straight from the jug. And it's like a white supremacist thing or something.

So it all got

canceled immediately.

[00:56:34] Chuck: Yeah, yeah. That's a signal for white supremacy or something. I was like, but it's milk from a cow or a nut or whatever you prefer, I guess.

[00:56:44] Robbie: Yeah.

[00:56:44] Andrew: hm. Fk f f f f f f f f f f F f f f f f f fp Kind of touched on it, but what do you both think the future of front end

[00:56:56] Chuck: I'll

go first,


[00:56:57] Robbie: you go first, because you just took like, I'm going to take your spicy take and add to it, so.

[00:57:02] Chuck: I did, yeah. I like to make your stuff interesting,


why I'm here.

[00:57:06] Robbie: okay.

[00:57:06] Chuck: Um,

that's my other spicy take. No, um, so...

I like that, holistically, we're looking at the beginnings of a more pervasive internet and the technologies that powered that and considering them. obviously, I've had a substantial amount of my career in this front end, single page application, manipulate DOM and all that, you know, offload computing power to the client.

a lot of that, you know, and I spent some time doing things like Django and WordPress and all of that, where we let servers do the heavy lifting and let business logic live there and all of that. So I'm very interested that we just take a look and say, just ask questions. And I'm not saying that I think.

Regression is the right answer, and I'm not saying that we shouldn't continue to, make the front end better and better, you know, challenge each other in these ways that you guys have brought up a few different times, but also do that across the board, like what is a web application and what's the best thing for tooling skills, my, you know, end product for the user,

that's why I made that kind of half joke around.

We're all going to write rails in five years. We might, we might be. There like it might be an incredible experience again. I don't know. Maybe it was never that bad I have no idea but

[00:58:25] Robbie: Are you


[00:58:25] Chuck: coolness.

[00:58:26] Robbie: experience right


[00:58:27] Chuck: I don't know. I've never written a Rails app. So Maybe that'll change but yeah I that for me is is a thing that I think the future could hold and that I think we're in a better place as just a web community to kind of look at that holistically and say What what can I take from before?

Can we do more with it? Is there a combination of all these say, of all these things that starts to take us to the next level?

[00:58:54] Andrew: Yeah, what what old what's old is new again often comes up on our podcast and like if you just look at serverless That's kind of like what's old is new again Like we used to have big mainframes everybody had a terminal into the mainframe. You never you didn't really have your own computer It's kind of what serverless is.

So like we have these cycles in dev where like What's old is new again, and just with a little, like, sprinkle of new technology, it seems like a whole different thing.

[00:59:18] Justin: The pendulum

[00:59:19] Robbie: Yeah. Yeah, I'm gonna, uh, piggyback off of that idea. And say, like,

basically Astro and writing everything HTML first is going to be the future. Like, I think view transitions has showed us how much the browser can magically do for you when you just write normal HTML. So I think more and more of that is going to be built into the browser.

And you won't have to like, let me write this huge spot app just to have like nice, you know, animations and whatever. It'll just work in the browser, and then it's whatever dev tooling you want to just ship your normal HTML and CSS and you're done. Like, JavaScript has always been a polyfill for what browsers could give you, and browsers are getting there now.

So I think, like, we're gonna need less and less JavaScript, and maybe we just use Rust, and we're done. I don't know. Yeah,


[01:00:12] Chuck: what's the Right, right. Rust Web framework though,

[01:00:15] Robbie: Well, I don't,

[01:00:15] Chuck: There's been a few of them.

[01:00:16] Robbie: Yeah.

[01:00:17] Chuck: What's the Django of the Rust world? You know? I guess you could say flask too, and for Python. So see, there's not one answer.

It depends,

[01:00:26] Andrew: Wasm's definitely gonna change some things. What it will change, I don't think we know, know quite yet. It's been very interesting to see that, like, the most interesting things coming out of Wasm are, like, not at all related to FrontEnd. Like Extism, I find really interesting, the stuff Fermion's doing with like, serverless wasm, also really interesting, and none of that's anywhere near the front end.

[01:00:46] Robbie: Yeah.

The front end doesn't really know how it's been official yet. Like, it's been out forever. And we're just kind of like, it's there. Like...


[01:00:56] Chuck: was it like 2014 or

[01:00:57] Robbie: Yeah, I mean, it was when EmberConf was still well attended, so... It's been a while since,


[01:01:02] Chuck: It was,

uh, that framework that Fred Schott used to work on. No, before that.

[01:01:11] Robbie: Oh.

[01:01:12] Chuck: I don't remember. Polly something. It's fine. We drink whiskey. We don't have to remember things. Mm hmm.

[01:01:18] Andrew: That's what show notes are for.

[01:01:20] Justin: I think I remember what you're talking about though. Yeah. The one that was like at Google, right?

Like the web, web components framework back in

[01:01:27] Chuck: Yeah. It was basically the


the polyfill for webcam

Polymer. There it

is. See,

I'm not

[01:01:33] Robbie: what you're talking about. I just didn't at the time. Yeah.

[01:01:36] Justin: You know, I think it's worth like just looking back and seeing how far we've came in the front end space in particular.

There's been a lot of innovation and most of it's been like rediscovering patterns that's happened in other areas of computation and learning how to imply it. And for me, the future is always that it's like we push abstractions and user land.

Which I think React is like an abstraction in user land that we've like applied old ideas and computation to user land and the front end world and like done this, like introduces new paradigm. And the really interesting thing is the platform tends to just like take little tiny steps that like make something that was previously hard, much easier.

to me today, folks could argue that web components is a thing in that. Space and I'm not a huge proponent of what components is as good as the idea is, but like, there's a lot of stuff in like the CSS world, for example, that they've introduced a lot of improvements over time. That's like really making it, like sub grid, just CSS grid, like that kind of stuff is really, really great.


You know, I think that this area is where our future is. It's really, we continue to iterate in user space and come up with these abstractions and find models that work really well. And then that pushes the platform to say, actually, we can do this and make it a little bit easier for everybody.

[01:02:57] Andrew: Yeah. Container queries and has, like, those two things, like, literally browsers told us for, like, Over a decade, like, you will never have this, we cannot do this, and now we have it. It's a very exciting time


[01:03:11] Chuck: say never

the programming language CSS, by the way, there's my other spicy take.

It's a programming language. It's instructions to the computer.

[01:03:20] Andrew: If, if you've ever followed the account AnnaTutor, she does some crazy CSS stuff. Like, to say CSS isn't a programming language, you have not seen what you can actually do. It, it gets intense.

[01:03:32] Robbie: Yeah. I think, you know, CSS is one of the harder things to learn,

honestly, because it

like. It's different than you can do logic in any programming language and like, you know, whatever it's logic based. But CSS is like another level. It's not all logic. It's like cascading. It's got like stuff clobbering

itself everywhere.

[01:03:52] Chuck: Yeah.

[01:03:52] Robbie: All right, cool. You guys got anything else? Anything you want to plug? Where can people find your podcast at?

[01:03:59] Andrew: Uh, search DevTools. fm on any platform, basically, or to go to DevTools. fm, the URL, and you can, you can find us, uh, if you're at all interested in developer tooling and how it changes the modern computing landscape, come check it, check, check us out.

[01:04:14] Justin: And plug the human aspect of that. We care a lot about people and their motivations. And we talk, you know, a lot about things like how folks who are working in open source, how they build companies and how they monetize and, you know, how they make space for themselves and take care of their mental health and everything.

So the human aspect is really important to, to what we chat about too. So.

[01:04:33] Chuck: Yeah. That's awesome.

[01:04:35] Robbie: All right. Thanks everyone for listening. If you liked it, please subscribe, leave us some ratings and reviews. We appreciate it. And we will catch you next time.