April Panel
===

Emily: . [00:00:00] Welcome back to Pod Rocket. I'm Emily producer for Pod Rocket and we're back with the launchpad, our monthly panel episode where we cover a wide range of topics trending in the world of web dev, as well as going through, , some of our guest hot takes at the very end, , and what they're fired up about right now.

But before we get into our topics, I just wanna welcome our panel. First, we have Eve Portello, , co-founder of Moon Highway, software engineer, educator, and author, focusing on JavaScript React , GraphQL, and Rust. Welcome back to the podcast Eve.

Eve: Thanks so much for having me.

Emily: Awesome. Next we have Michael Chan also returning. , he's Speaker YouTuber, creator of the Lunch Dev Discord server, host of the React Podcast.

And more welcome back to the panel Michael.

Michael: Thanks for having me. It's good to be back.

Emily: Of course. And to round out the panel of guests, we have Theo Brown coming on for the first time, founder and c e o of [00:01:00] Ping dot Gigi, educator, creator, and speaker And welcome to the show, Theo.

Theo: Welcome. Great to be here.

Emily: Awesome. And finally, we have our pod Rocket host. Paul, welcome back. As always, Paul.

Paul: Hi, Emily. Thanks for having me on.

Emily: All right, so let's get into our topics. Topic number one. It is a happy 20th to Node, , node 20 just released last week, , at the time of our recording. And we can't have a panel podcast without discussing some of the new features and speculating about the future of Node. So, To get into it. What are your overall takeaways from the initial release now that it's been out for, I believe, almost a actually a week.

Theo: I, it's an interesting release. It's a, a lot of things that have been moving for a while that finally happened and a lot of things that are just starting to move. I would argue the big [00:02:00] two things that like people will feel are the ability to build binaries, which is you can now point node at a JavaScript file and it spits out an executable rather than JavaScript files that you can run, which makes it easier to bundle a node app.

The results are giant binaries that are like 80 plus megabytes. So I'm not sure if it's for everybody, but it is a thing that exists and could be useful. The other interesting pieces are fetch is now baked into node, which is really nice and overdue. The fact that we've been bike shedding over where our fetch should come from for the last 15 years is obnoxious, and it's like that's finally over and we're finally using the web crypto standard for crypto, so you don't have to have 15 different versions of encryption depending on where you're deploying your apps.

But these feel more like bug fixes and things that people have built. Third party stuff for already. Nothing like groundbreaking in this release.

Michael: Yeah, , I feel the same way. It's really interesting, I think, to see. I guess just like how the, like a note is like a boring project now and , I don't mean that in like a bad way. I think in a lot of ways like boring is good, like [00:03:00] it's like very stable and whatnot, but it feels like it's like just.

Slowly catching up to where people are like trying to use it. And , I think we've seen a lot of movement in, , , other run times like, , Dino and a lot of JavaScript developers are defecting to rust. So there's just a lot of other things happening. 

Like this is stuff that we, , want, especially having a stable test runner, that's really cool, but , again, it's , feels like it's playing catch. , so. . Honestly, the most entertaining thing I think from this release was just seeing everyone, , tackle West Boss online after showing the binaries like the 85 megabyte binaries.

Paul: Why are those binaries so big? Michael? , could you enlighten a little bit about why they're so fat?

Michael: I think they just have to include the whole , , V8 runtime is the problem. Yeah. And I know a lot of people are like, well, can't you like tree shake some of the functions out , but I think it's written in c plus plus most of it. So you can't really like tree shake c plus plus out of it.

I don't know. I'm naive on that front, but that's my [00:04:00] understanding.

Theo: I'm nerd about this stuff. I've built a few many electron apps. There's just a lot of stuff you need to make JavaScript work on any much less, many platforms. And that base binary, if you're not relying on like system baked stuff is going to be huge. , we went through this on React native sum amount of like , where do we get our JavaScript run time from?

Where if you use the one baked into the platform, you can ship React native apps that are like less than 10 megs. But if you bake your own in like then you're gonna hit the 50 meg line quickly. And that battle of , like. The thing that runs your JavaScript and can manage all the native dependencies and all that stuff is probably a lot bigger than your JavaScript files.

Paul: Part of the new update that's coming out is an update to the V8 engine, though, and when I was going on Twitter and searching around, it also didn't seem like it was something groundbreaking per se. It was just like an a needed update. , or Theo, , if you wanna continue nerding out, I'd love to hear a little bit about like why the V8 engine is not a significant upgrade in the Node 20 release.

Cuz to me that's like a very core building block.

Theo: Well, you mean that web assembly tail calls aren't a groundbreaking [00:05:00] new feature that's gonna change how we build on the web?

Paul: I mean, that's, the running thesis, right? , that's what we wanna believe.

Theo: Yeah. It's just. V8 is also one of those, keep up with the spec projects now where there's this complex but also boring relationship between the web standards, the Chrome team, the V8 engine, the other engines web kit and all these things. And it's a matter of a feature gets proposed, it gets a certain , Prior amount of steps through the process, the Chrome team decides how eager are they to adopt this thing.

Then they go do or don't adopt it, and then the rest of the world does or doesn't follow. And there's a lot of like features that get stuck in limbo. , I think recently Firefox finally added backwards lookups to their red rejects. So you could write a Redex that works in Chrome and Firefox that is complex for the first time.

So like we're just in standards. Hell and I. I love that the V8 team is working as hard as they are to stay on top of the standards, but that's most of what I see out of the team now. It's not like groundbreaking innovations to make performance way better. It's keeping up with the standards and adding features as they are added.[00:06:00] 

Paul: One more. Was the last groundbreaking V8 update that happened in anybody's recent memory here? I like how the 

crickets speak volumes. 

Michael: I don't know if I've ever been excited about a V8 update, but.

Eve: You haven't been super weird. Okay.

Theo: I know that 2018 had a decent overhaul. I forgot what it was. It was something about the like compiler pipeline. I'm trying to find more about it right now and I'm struggling. , , I'll be honest, I'm mostly excited about these updates or, , I used most excited about these updates when big JavaScript features are being added, like optional chaining type stuff.

But now that TypeScript is so eager to adopt those things as part of their compile chain before they're officially part of the standard, I find I just wait for TypeScript to add the feature, and I'm more excited for that nowadays.

Eve: It is just funny how the word boring is kicked around with node all the time, cuz I remember the old days where Node was too dangerous to use because it was like so new. And how do we trust it and PayPal is gonna use it, so we better all get on board now and it's the [00:07:00] most exciting thing. So I think it is.

To the point of what you said, like, , the permission model piece is very like enterprisey because it's like, how do we keep our file system safe? How do we keep our applications more secure? And it feels very like Node is, we're just trusting it now and we have to move at the pace of every stakeholder involved.

So that's why it feels a little less exciting, but it is cool that it is a thing we can rely on.

Emily: I wanna go back to something that Theo mentioned, how like there are obviously like a lot of tools and things that already exist, that Node is. Catching up to, , a lot of people were saying that the permission model that just came out is very similar to Dino's, and I know Dino and BUN and all the JavaScript runtimes are getting a lot of attention and popularity.

Do you think that node in this way is too far behind the curve? Do you think that [00:08:00] things like Dino, wem, BUN are going to take off and Node will be left behind and in the broader. Aspect, like you were saying, Eve, like it's more boring now because it's more established. Do you think Node might be falling more in the way of like react to being like it's a solid foundation for things, but it may or may not be more innovative in the coming months or years?

Theo: That, that hurt me deeply. Oh God. We're gonna talk about the react part of that comment a lot. I also want to go in on that because there has been no, in more innovative framework, especially recently. It's weird that like the old dog invented a new style of trek recently,

Emily: that's my bad. Just talking to all the devs that I do. They're just like, , it's becoming like, , it's there, it's not whatever, but love to hear your thoughts.

Theo: I was actually sad to not see a React server component topic on this podcast. Cause I think it's like one of the most interesting things to have at web dev in a while. But super quick on the runtime stuff. Neither Dino nor Bunton have had anything resembling like real adoption. There's [00:09:00] interest, but even Dino's interest has gone down so far that they've caved on their package manager and fully support all node packages four years after launching because they realized the their way of doing things wasn't getting traction because adopting something that.

Huge is hard, and I'm a huge Dino fan. I use it every year. I do the advent of code programming challenges. It's my favorite way to write the TypeScript file and just run it. It is an incredible, , system. I'm close with Jared from bun. The things he's doing to performance on top of WebKit is incredible.

It's nice to have a challenger for Node that isn't based on v8, because that just changes everything, but it's nowhere near ready for adoption. I don't see people adopting it. The way I see these permissions changes is it's just another one of those small things that somebody might say, well, I'm not gonna use Node because X, and it's another one of those scratched off the list, which is nice to see.

Michael: Yeah, I think that's a good way of putting it. Like just scratching stuff off the list, , , , bun and Dino are really like the tip of the sword on this type of stuff, and , these features like this are going to , get experimented there and then trickle down into node where it just becomes more stable , and whatnot.

Emily: So [00:10:00] what are we looking for? , I know, , node 21 will probably come out in. Was it August or September? but those are never the big releases. What are you hoping for within the next year or so? What do you wanna see Node continue to evolve in? Do you see it just adopting these other things and making them better?

Theo: I just want node 20 on lamb, just so I can use the shared crypto module. Like, like I I, the thing I'm most excited about for node 22 is that Node 20 will finally be on aws.

Paul: Collective people , who , they wait for iPhone 14 to come out so they can buy the 13. Slight, slight discount. Yeah. Theo's waiting. Okay.

Michael: I mean, , having fetch in there is great, and I think that that's one of the things that'll be really nice. , when it's on a w s it'll be, it'll be awesome.

Paul: I have a question actually , in terms of the testing framework that came out. So , I'm so into using jest cuz I've done it my entire career and it's. Weird to me to think about building up what seems to me slightly boiled down test suite into this hygiene of developed over , especially the [00:11:00] past few years as I've tried to, actually test versus telling myself I will in the future.

And , do you feel like , the testing module is gonna grow into, what fetch is gonna be is just like an inbuilt replacement that we're all going to move towards using or. People like Jess and moca , and these folks gonna build on top of that and continue to have their ecosystems flourish as like supplemental test runners.

personally and selfishly, I would love to continue using like Jess and see it become empowered with like additional user land, so to speak, like features. But I don't know if that's like a healthy direction to want the language to move in.

Michael: So I saw a lot of the kinda like test evolution in the Ruby and Rails days, like, , a decade plus ago. And I think . There was just these natural barriers in between like the testing frameworks and so I think Ruby shipped with MINIT test or something like that.

And it was really great for testing certain libraries like, , small libraries and that stuff because you didn't have to install anything. And that's really one of the nicest benefits of having , an inbuilt test runner. , but it was never going to end up being some of the bigger. [00:12:00] Like testing frameworks.

And I actually like that split, , so if you're just , , making a small library, then you don't have to install all that stuff, , it's really great for that and , I would, I think maybe prefer that it always be like a little bit more lean and small and keep it fast and then , , install stuff when you need it.

Paul: Separation of concerns for if you really need heavy testing, right? Yeah.

Emily: I also like to say we just had the creator of the test runner come on. So if you wanna check that out, that episode is live. 

Michael: Is it okay if we like parlay , , into react real quick? I wanted to hear , , , your rant about react not being, innovative anymore, Theo.

Theo: , this one breaks my heart because. React has now brought us , like three different eras of innovation. The first one was components. We had component models before react, but we didn't adopt them before, just fundamentally react. Showed up and said, Hey, that VC thing you're doing in the browser, that's a mistake.

You don't need that. You can just put your template and your update layer and everything in a component and then compose those and it will be fine. Don't worry so much. And it took us years to accept [00:13:00] that. But then we did. And then they said, oh, that chaotic state that you're doing in those class components with all the weird, internal, like this bindings that aren't really isolatable and certainly not able to be yanked out and reused, that's not a good pattern either.

Functional components are great. Can we make those stateful? In doing that, they found a way to abstract state similar to how components abstracted our UIs into these reusable chunks. Hooks abstracted our state into reusable pieces where we could work with the lifecycle of our data without having to directly attach it to the render layer, and then we can choose where and when we attach it to the render layer.

Both of these things created huge waves of innovation, both like developers creating with React, but more importantly, library creators and third parties developing new integrations with React. Things like component libraries, like Material UI frameworks like Tailwind for our C s s or crazy data layers like Redux and React Query, and all these other ways to work with React using these primitives.

The primitives they gave us weren't good enough for everything we wanted to do though, [00:14:00] specifically, we started server rendering and as the team at Meta started to see more and more value in static rendering and server side rendering of React applications, and Sebastian had the big vision of how we can bridge this gap.

The third era of React started, which is the server component era, and their model for how to render things on server and then update and continue rendering on client. It doesn't have anything fully new, but neither did hooks and neither did class components. It's more a matter of they found this assembly of all these ideas that have existed from things as niche as Marco to things as like hype is felt in trying to find the balance of these technologies such that it still feels like React and feels like JavaScript, but makes us infrastructure engineers instead of.

Front end engineers and the result is so powerful and I've never had as much fun building applications for the web as I have with the new server component model. And anybody who doesn't think it's a revolution just hasn't built anything with it.

Paul: , did react. I liked that fire. In your opinion, Theo.

Theo: Absolutely.

Paul: They were like the first ones to torch. Cuz , I've worked with Astro for example, for me as a developer, that was my [00:15:00] first foray into , look at the power you could have via shipping lesson by figuring out how to leverage the serer. And to me, I was like, wow, Astro , so you're saying like astro distilled ideas from the meta team

Theo: No. So. There are a lot of ideas that the React server component model learned from Astro. But Astro was , the most bleeding edge of the last generation. React server components is the first of this new generation where the boundary isn't something that's hard to find by the framework.

It's something you get to move around. In previous models like Astro, you would have a point in your application where you convert from Astro to react or solid or whatever framework, and you choose, okay, from here down, I'm going to write this in solid instead. Cause I need it to update in the new server component model.

You choose where that boundary is. Whenever you just change it, you go put a used client on a file and now that's where that interaction boundary lives. And you can also pass server components as children or props to client components so that you can render things through the server inside of a client component.

All of these patterns are things that like pieces of have existed and other stuff like Astro, but this [00:16:00] combination where it all just feels like you're writing one framework, one syntax, and then choosing where the infrastructure boundaries live that is fully new and react.

Michael: Yeah, that's such a great way to put. It too, like the idea of, ,, like the previous general information of frameworks have decided that for you, like, , Astro decides like, hey, everything is going to be a page at first, and then you can put your, , client side code on top of it.

, but yeah, just being able to move that around and be like, okay, actually I want all of this to be a server component. I want all of this to be a client component or, , I want this to be like a mix, but I want it to start here and , have these client components and it's crazy. And , is there another place to play with it besides next 13 app directory, or is that kinda the only place that has it right now?

Theo: A bunch of developers have been making like third party server component implementations. One of the. Funny things about the new model is it makes it much easier to build your own next js, which is why Versal has chosen to throw out the vast majority of next Js and rewrite it from scratch on top of the new model because first off, most of next was bad.

I'll die on that hill. Gladly get service, had props as a mistake, [00:17:00] and we're still paying back the tech debt that we've caused from it.

But by throwing away the new model and embracing the new one, next itself is conceptually simpler internally and as a consumer externally. And I've seen like, , , Ben, Holmes from the Astro team has a project Simple R s C, where he from scratch built an R S C framework, and I know Maple Leaf from also the Astro team just rebuilt that using Dino funny enough just to see if they could, and turns out it's only like 200 lines of code to build your own server framework for server components in 

whatever runtime. 

Michael: That's cool. Yeah. If you haven't worked with, , next 13 after Victory, , it's a real treat and I agree with you. I hated Next, , really up until 13 came out and I was like, oh my gosh, this is what I wanted it to be the whole time. And it was never this, and it's super fun now.

So, I mean, it's still, beta or whatever, but , Like, it's a fun way to build sites.

Paul: We have an episode with Ben Holmes or maybe even two episodes where he is coming on. We get to pick his brain a little bit and I know you like interface with a lot of students and people like stepping into the space for the first time cuz you do a lot of [00:18:00] teaching, , like with Moon Highway 

so , like Theo said, we're becoming like infrastructure engineers more like less front end engineers, which I totally resonate with. , when I first learned Astro, it felt like a big learning experience for me. , do you think that this pushes that boundary about the learning curve that you're seeing in students who are like, what is next 13?

Now I feel like really confused. Do you see this as a problem or , is it just settling the dust and it's gonna figure itself out?

Eve: Yeah, I think it's evolving. As Theo described, all those different eras, there's different things that you had to know about React at those times. And yeah, , as the scope got larger, so did the things you had to learn. And I think GraphQL stepped in for that at that time. Like React developers, I know people are cringing, , but it's true that people were.

Having to learn backend things, , to build like an API layer alongside their React application. And where does next fit in with all of that? So now it's starting to look like we're [00:19:00] evolving toward, , , having to know a little bit more. Deeply into the stack with React, and that's scary, but it's also these tools are going to continue to get better.

I think learning resources are gonna continue to get better. I think part of why people are resistant to it is that learning curve. It's like, I already learned this, I don't wanna learn this. But as developers, unfortunately, That's what we signed up for. , we have to keep learning and we have to keep choosing the tools that make the most sense.

But yeah, , I've definitely found that, , people are like, did I pick the wrong thing using this? Do I have to learn something totally new? And yeah, we're always gonna have to learn something totally new. We're not off the hook.

Paul: For people who are maybe like stepping into the space for the first time, would you urge them to go try to. Have that initial exposure to like the client and server component model, , do you suggest doing that because that feels like a bigger complexity [00:20:00] scope than like, let's create a statically generated page.

Eve: Yeah, , I think with whenever you're setting out to learn anything, learning things incrementally is important. So, , learning react really well, the basics of react. Sometimes people get overwhelmed if they're like, , you have to learn all of these things at once. So, so yeah, I think that learning path is starting to be defined.

I think a lot of the pushback on server components. Is like, are these a thing actually? Should I actually learn them? What is my responsibility here? Can I actually use this? Should I learn something that's going to change? So, , yeah, I don't think you should hesitate cuz I think these are sticking around as other folks have mentioned already.

Michael: Yeah. One of the challenges I think , is that it really does push it more into requiring a framework. So up to this point, like you could build react components, ? Anywhere, right? Like anywhere you had a browser, you could write a React component and with these new primitives, it changes the thing where you're like, you have to have a framework and I think that it changes the [00:21:00] type of application that you're building.

Like I know , that there's this, I remember again, I'm gonna throw it back to Rails or whatever, but there was this big mindset shift that happened, like when people were building PHPs and then . M migrated to using more rails, which was this whole like application architecture.

But the thing is, is that like out of the box, like there were opinions on how to actually structure and build applications, not just like pages or like small apps or like bring your own type of framework as you're building your application. And I think that. Hopefully we'll start to see a little bit more of that.

Like the level at which we're building applications is a lot higher. We're starting a lot higher, , as opposed to , this is a component and it natively renders on a client. And if you wanna do more complex stuff like God be with you, , we can actually do a lot of that stuff right out of the gate.

But, , it does mean that there's gonna be a lot more complexity as we like, teach people earlier on , in their 

learning. 

Theo: My one big piece of pushback would be the amount that someone has to [00:22:00] learn to be productive. I would argue that in the past, . When , they added J S X to react that, that's like now you need a compiler in order to use React and that's more things that are React. So to know all of React there, there are more things on that list, but I don't think checklist learning has ever helped anybody.

You can't learn H T M L. You can't learn c s s, you can't learn React. You can learn how to use them to build things, but I don't know, react, I can't sit here and say what I, I 100% know and understand. React. I know a lot of what it does. It's weird behaviors, how to use it. I can even educate people on it and onboard teams with it.

But react isn't a thing you can learn in the sense that you can complete it. And I think a lot of people who are concerned about how learning React is changing what they're seeing is all of the things that encompass React is now a larger set of things, which means to learn, react, you have to know more things.

I don't think that mindset ever made sense. And what's exciting to me about the new React model is if you learn by building and like project focused based learning. The amount of problems you have to understand to solve a problem that you have. Like I wanna [00:23:00] build a button that when I click it, it as a user to the database, that type of problem would've been many more pieces you had to understand and many more steps you had to go through.

You would've had to, as you've brought up earlier, you probably would be learning GraphQL just to add like one button to your application, cuz the one button you're adding today happens to be one that needs. A server. Now that's a free line of code thing with the new model, and that's the difference here is that yes, there are more things that count as react, but there are less things you have to learn and think about on a given feature or thing that you're doing.

The complexity of each individual task has gone down exponentially. By the framework's complexity going up by like 10% and we love to bike shit over that 10% of additional complexity on the framework, but nobody wants to talk about the 90% that we're killing in every single thing we're building. The apps I build with the new model are so much simpler to work with, so much more performant and so much easier for teams that haven't even used reactor types group before to build in.

It's just hard for me to look at this and say anything other than I'm excited for new developers to try.

Michael: I think it's a really good, good point too about how like, react has [00:24:00] always pushed that level of discomfort that people have. The virtual dom, like at the time that it was released, everyone wanted to bike shed about exactly how it did its thing and if you could do it better by handwriting your code and like , they just .

Shifted that boundary of things that you had to care about, right? And like to continue to shift that boundary of things that you have to care about. And , I totally agree with you, Theo, like , this is an uncomfortable boundary right now, but three years in the future, it's gonna be like, oh, duh.

Yeah. Like of course it's the same, they removed a class of thing that I had to think about and that's awesome. I'm glad that I don't have to think about that anymore.

Emily: So onto our next topic. , we've been increasing our coverage on AI, obviously, because that's what everyone is talking about now. , we've touched about it in our other panel episodes, but we often focus on the fear that developers have, , that AI will replace them.

I know when we were having our, , UX UI panel conversation, a lot of developers send in, , questions being like, Are these tools going to [00:25:00] make me obsolete? , and Adam, , Argyle was like, absolutely not. And so I kind of wanted to like focus in on that. , and talk about how you are all looking at AI as hopefully a way of adopting it to make your lives better.

, we just had on the crater of this little baby app, a code converter, , Guillermo Rauch, , tweeted out about recently and how it will hopefully be the first step in using AI for code migrations. , But I also know that like last year when we were talking about web three and crypto and everything, everyone's very excited and it seemed like it was a bit of a fad.

So I wanna have a more holistic discussion of , where do we see AI being, , beneficial to developers? Do we think that right now it's more fatty than, , , a beginning of the AI Renaissance. , , maybe start off like, are you guys using AI and development right now?

How do you feel about it?

Theo: Co pilot's. Cool. Yeah, I try chat g p T for like, like if I have a sub code using an old library and I'm [00:26:00] too lazy to port it, I'll just throw it in chat. G P T be like, Hey, make this, use this library instead. And it gets it wrong most of the time, but sometimes helps a little bit with some of the syntax and 

I like AI is a, a thing to augment my own workflows, just to have something else to talk to or something else to type for me sometimes. But it's also for me, created some of the most obnoxious bugs to solve I've ever had. And I know Primo Gens talked a bunch about this after using co-pilot at work, like it writes code with such confidence that.

You just trust it and then when it does something stupid, you don't notice because the amount of processing your brain had to do to get that code out is so much lower. The amount of understanding you have of that code is also usually fundamentally lower. And people always complain about how buggy software is.

I know I've gotten crap for some of my takes. It's like, oh, this is why software always crashes. But if you think software's buggy now, wait till two years into the AI era, human made code will be a a highly valued asset and. The people who learn how to use these tools to make themselves more effective and [00:27:00] faster, those are gonna be the real winners.

The individuals who can move faster with the tools, not the creators of the tools, and not the companies that are buying these things to replace humans. , the people who use the tools to make themselves the best will always be the winners in situations like this.

Paul: I feel like , you really need to have a knowledge of ai, especially at this time, to really juice the fruit for all the juice it's got. , if you just hop in the chat, g p t and naively have it programmed for you, as we all know, it doesn't do that good of a job and.

, it's interesting to me that there's gonna be a subset of developers that, because they're initially focused on artificial intelligence, on like calculus back propagation, they've like made these models before. , they have some acumen about how to get ahead of the rest of the curve, even if they're not like a reactive developer.

It's like, well, if I could code an AI to embed all of my React files and all the documentation and have it output giant responses, , that puts me ahead of the curve. So I think that's gonna be an interesting dynamic that I'm looking forward to. Exploring. It makes me wanna study ai, right? Like, how does it actually work?

Michael: I think that the. Command you have to have [00:28:00] over language in order to really utilize some of these tools is really high. And so I think there's this idea of like, oh, well, , as soon as I can, , tell this app that I wanna make, and , it'll make it, , there's this idea that is what's gonna replace us.

, but I think, , in the same way that React removes classes of problems that we haven't wanted to deal with, I think that, , AI right now is actually pretty good at being that rubber duck for a lot of people. Like when you're beating your head against the wall of like, oh my gosh, , I'm at this problem.

Like, I really don't understand it. , , part of the value is just being able to put that in words again. And I think that that's a huge human skill that we have undervalued as programmers for a really long time. And so to have this tool that's forcing you to be able to talk about your code intelligibly, , , the right terminology and everything, which I'm usually very bad at.

So I feel like it's improved my ability to talk about code, , which is a huge value to me. ,

Paul: That's the AI revolution here. It's just teaching us how to speak [00:29:00] properly so we can communicate to each other.

Michael: Yeah, , I mean, again, back to that point of like things that you don't want to do. , atomic Habits has this idea of, , building an automated, , , streak thing, like you don't wanna have to log your streaks manually. And so building some like automation that's like,, Hey, , , every time I do this thing, just log it.

And being able to see that, , it's very motivating to see that. And I've been wanting to do one for YouTube for a long time to motivate myself to actually post. And . It's code that I don't wanna write, right? , I just wish that there was like a streak for like YouTube, like MPM thing.

And honestly chat g p t, was about as close as I could find. And I just said , Hey, I want this astro page , , that just makes a streak for me and like tells me if I, , posted for that week or not. And, , It did it like really fast and then you're like, Hey, , use tailwinds and say, have Tailwind installed and, , do this or like,, change that function name or , flip the order of this thing.

And it's really fun to think about code that you don't wanna write from , that angle, that high level view. And then dive into the higher level stuff of like, [00:30:00] I don't really like the way that, , this works. , , then you can take on from there. But first drafts suck.

They always suck. And so like chat, g p T is a great way to , have a robot do a first draft for you and be like, oh my gosh, your code sucks. Let me fix it for you. , it's a hack to get yourself motivated to work.

Theo: First drafts suck if you're not excited about the thing. But if you're excited about the thing you're gonna talk about or make or whatever, first drafts are really, really fun. And I think that's what you're touching on here. That's really powerful is. AI will never be better than a motivated engineer, but AI will always be better than an unmotivated engineer, someone who doesn't want to work on the thing.

So if you're excited about technology, excited about building, excited about learning and doing all these things, you're fine. If you were 50 50 about tech and you don't actually like, enjoy the moments where you're writing code and solving hard problems. AI is going to be more of a threat to you, but the people who are excited about engineering, people who are listening to this podcast for fun, like on their way to work because they just like technology, like learning about all these things, y'all are fine.

Eve: Do you all use copilot when you're coding at all

Michael: Little.

Eve: Ish. 

Theo: I was so [00:31:00] skeptical going in too. I did not think I'd be a co-pilot person. I have two videos on it now where I like, I did not think I'd like this and I love it. I compete in advent of code every year, which is a programming contest that, , goes from December 1st to 25th.

, I can usually break top 1000. I used to be able to break top 100 people. Gotten too smart nowadays, and there's like 300,000 people doing it now, so it's tough. I was able to break top 300 multiple times last year just because of knowing how to prompt co-pilot into writing the right thing, like naming your variable correctly so it auto completes the right code, and if the code at auto completes is wrong, going up a line, putting a comment, saying what it does, going back down and seeing it auto complete it correctly, both got convinced of co-pilot's abilities through advent of code and also that prompt engineering's a real thing.

Eve: Co-pilot's been funny as a teacher, because sometimes I'll give. Folks a lab activity to work on. And then, because all of the materials are open sourced on GitHub already, it'll just spit out like my c s s or just finish it really quickly. So , I've been [00:32:00] interested in that, that's making those little open-ended challenges have the same answer in a lot of cases.

Paul: Training data. Yeah, training data. Coming right through to the other side,

Eve: Exactly. It's . Cutting out the middleman on that.

Paul: like, , I've also used co-pilot for quite a while now, and I've actually migrated to using Chat G P T more , and it's just been a context thing really, because I know co-pilot does a bunch of magic under the hood to provide context and embed relevant things. But when you can take a library and copy and paste like 600 lines straight into a chat one, you'll be like, look at these interfaces.

Go use them. It does a really good job. , it's shocking if you give it the right context. So, , I'm really excited to see co-Pilot X come out where I can do that chat style interaction and then I can give it specifics that I know I wanted to import and use. So, , context and memory is everything, and it's exciting to see those two vectors scale up as we march along this timeline.

Michael: I wanna talk to the, like the main idea that you started this with and the idea of like an [00:33:00] optimistic versus a pessimistic view of ai. , I feel like one of my favorite representations of the interplay of human and AI is Tony Stark and Jarvis, and they do such a beautiful job of.

Showing the importance of both the human and the AI part of that, and they invent together, right? It requires that human part to be like, okay, try it from this angle. Try it from this angle.

That like pen testing, like with this work that work the, with the other thing work. , and then the. AI is really good at just like spinning up universes and coming back with a result really fast. And I really love that concept of it. And I think the more that we can think about that, the more that we will build AI that, , work that way.

, ultimately humans aren't gonna last forever. So like, why not have an AI that like outlives us and, , I don't know, but whatever, , we're all gone at some point. No species lives forever.

Eve: That's the optimistic take. We're all going to

die. 

Michael: And 

Eve: as well build something cool to live. Yeah.[00:34:00] 

Emily: Everything's fine. , . Last question. Do we think this is more of a fad right now, or do we think this is like the actual beginning? Because I know every so often, ai, , even in the broader cultures, like, oh, AI is gonna like change everything. It's been happening for 20 years, right? Do we feel like this is an inflection point or do we still have a little bit of time?

Michael: Yeah,

Paul: I was gonna ask, especially since I know you put out a lot of videos, especially recently, have. , are you using it to generate content? Do you feel like it's fundamentally changed your workflow?

Michael: , , I'll say this. , . I don't think it's changed a lot of my workflow yet. There are times where, I mean, again, like it's things that I'm not excited to do. I'll usually throw up chat G p T for that. , I think Theo made a great point about that. Like the idea that. , , , it's a thousand times better than someone who's unmade motivated to the do the job.

, so I think that's a really great place. And I think that this is like a great place to learn anything is what's the thing that I don't want to do and how can I use technology to solve that problem for me? I don't think you have to , learn ai, but queuing yourself up to ask that question more regularly.

Like, is [00:35:00] there a way that I could say I've solved this with technology? I think there's a lot of people doing some really cool stuff, , specifically with video. So if you are able to do a video, Like really easily, you enjoy making videos, you can just spin up a loom and pass it to an ai and that could be like the first draft of a blog post.

Like there's a lot of tools that are doing that. There's things that like take your video and figure out what your chapter markers should be and like kickstart , that part for you. There's some really cool stuff that's happening around stuff where you're like, I might prefer not to do that, or maybe that's a blocker for me, but it's still important to me and I want to include that.

And the more that we can solve that with robots is great.

Paul: And do you feel like we're at an inflection point where it's like those alternate methods are becoming actually tangibly useful in the real world?

Michael: Oh, for sure. I think they're just spinning up. I mean, every day we're seeing new AI services or L l M services and I think , we're just gonna see more and more. And at some point the ring will rise to the top, as they say, but we'll have some really good services , , , that generate some really good results.

Theo: My concern with this stuff is it feels like the tool. As I see [00:36:00] are majority focusing on replacing humans and roles, not augmenting us to be better. As, I think in tech we're better about this cuz like the developers building the tools know what development looks like. So they're not gonna build an AI that replaces a developer.

They're gonna build AI that helps developers. But when it comes to things like customer support or creative work, the tools I find , are less trying to augment more, trying to replace like I've yet to find. A graphics tool that actually helps me in my graphics editors do things quicker using ai.

Something as simple as like, I know Adobe has their background remover that uses some AI internally, but it's one small feature. What I'm thinking more is like smart delete sections. Smart clone, smart replace, like match the color enlighting profiles of these two images so they don't look like they were taken in different rooms.

Like things I spend my time. Hand doing in most of my editing work, like AI augmenting, as we said before, with the deaf stuff, a augmenting and, , automating the boring parts is very powerful, and I feel like we're. As an [00:37:00] industry right now, too excited to replace things and not excited enough to augment them.

And that's why I think right now we're in a hype phase because we don't know what the limits of the tech is. , when I say hype, I don't mean like this stuff's gonna burst and be useless. I mean more like the.com bubble burst where , the.com bubble didn't happen because the internet was useless and misunderstood.

It happened cause the Internet's value wasn't quite understood yet. And I think AI is in a very similar place in that regard. We're gonna fall back on a better place for it, but our current understanding of it is insanely inflated because we don't know , what its limits are.

Michael: Do we think that like prompts are the way forward in all applications . You mentioned visual, , editors. Like do you want something there where you can be like, Hey, I actually want this whole background blue and I just want me to show up, 

Theo: i, I, I hate guessing on the interface for anything this early, . And I'll just be honest, I don't care what it looks like if it makes me better as a developer. Like to go back to server components, I had a proposal for server components that looks like two thirds of how they look right [00:38:00] now. And I'm not going to brag that I predicted server components.

It's more I wrote something that would make my life easier and they wrote something that makes my life even easier than what I proposed. I'm not as interested in what I could propose and guess it'll look like as I am and how I'll actually be benefited in the future. And for me, all of this is bike shedding like in three years.

It either helps or it doesn't.

Emily: . Before we get into our hot takes, , we're gonna take a quick break and we'll be right back.

This episode was brought to you by Log Rocket. Log. Rocket offers session replay, issue tracking, and product analytics to help you quickly surface and solve impactful issues affecting your user experience. With Log Rocket, you can find and solve issues faster, improve conversion and adoption, and spend more time building a better product.

You can get it@logrocket.com today if you wanna get a free trial. All right, now we are onto our hot takes. Each of you are going to get a minute. You can rant [00:39:00] about whatever you want, as long as it's a part of the web dev world. , . , Michael, do you wanna go first?

Michael: Sure. Sure. , I think it's still way too damn hard to get a high quality video in audio for people whose profession is not getting high quality video in audio. , I just wish it was easier and I feel like everyone is capitalizing on the idea that it could be easier and you , could still get high quality stuff and it's just.

Not there yet. It's still all garbage. So, , I can't wait for that to improve, , because I think it's still ridiculous that so many people are like, Hey, what, , mirrorless or digital s l r camera, can I plug into my cam link to get like a nice high quality video? That's always gonna be one frame behind my audio because, , inputs come in at different rates, it's stupid, it's ridiculous.

Emily: With that said, Theo, do you wanna go next?

Theo: Sure. 

Emily: Go

Theo: I think our understanding of the term bleeding edge and what it means to like, Use new things is just fundamentally missing [00:40:00] so much of the important parts of the conversation. Like the amount of times I get told on my YouTube videos and such that like, oh, that's cool, but let me know when you can build this for like a real company or a real application.

Like . We haven't been using these things at companies like Amazon and Twitch for years now, and like I didn't learn the things I learned building at scale, and I'm bringing them here to talk about the new technologies, especially on the React side. The word bleeding edge is not. A good word for those because when I hear bleeding edge, what I think of as something that has a high risk of not working out or not being a reliable bet in the future, like I love Astro when I love solid js.

I'm very close to the core teams for both, but you're making a fundamentally different and fundamentally riskier bet when you use something like that versus something like React. And that's always frustrated me, that somebody looks at server components and look at solid. They're like, yeah, this is the same level of risk.

They're not. They're absolutely not. 

Emily: Eve, . You ready?

Eve: I'm ready.

Emily: Go for it.

Eve: All [00:41:00] right, so my has to do with the sentence, no one uses blank anymore. No one uses Node anymore. Everyone uses Dino. Actually, no, like lots of people use Node. No one uses React anymore. Everyone's using Felt now, literally not true. But no one uses Netlify anymore. It's all Versace. Not really.

This logic doesn't hold up at all. So, It makes me think about e-bikes. I bought an e-bike recently and it's very cool. It gets me places way faster than my regular bike. Does that mean that all of our regular pedal bikes should be melted down and not used anymore? No, they're super useful. So what I would say is that innovation is great.

Choosing the best tools is awesome learning. Is the best part of our job, but we don't have to act so early. We don't have to declare deaths so early about things when they're widely used because it sometimes makes people feel sort of sad. So don't come to our computers and tell us that no one [00:42:00] uses React anymore when you're using React on a website.

Thank you very much.

Emily: Great. Love it. All right, Paul, 

Paul: My hot take is up the same alley. , , we want to always be. Innovating and that's good. And off our topic of server components, like huge fan, like if you understand 'em, it really makes your website powerful and fast. , I'm just always concerned about the barrier of entry for people getting to web development.

And in some podcasts we like talk about, oh, well wouldn't it be great if like, we still had frameworks where you could do just plain C CSS and JavaScript. And HTML and , yeah, I'm just always concerned about the level of. Dedication it takes to get into web development. Cuz we always wanna be bringing bright minds into the space at all times and just, .

I look forward to seeing education, , continually come out like by, from you Eve and other people. Michael and your YouTube channel Theo as well. , , hopefully we can keep that barrier for entry low. 

Theo: My hot take was almost the exact opposite. I was between two and mine was that I think that we think beginners are both dumber than they are and smarter than they are where we think so much of [00:43:00] what we learned before is a necessary part of the process. And if you don't learn these specific things, you won't be able to like be successful.

And now there's more things you have to learn. But on the other side, we have all of this context already and we presume these things are necessary and that without them you won't succeed with something like server components. The amount you need to learn to make a button in the website that you can click and it works in a code sandbox is smaller than it's ever been.

You might not understand the inner workings of all those pieces, and we love to think about those cuz we've been doing this for years and it's fun for us to talk about. But a new developer, the best thing to get a new dev hooked. Is writing something that they vaguely understand and seeing something come out that they vaguely wanted to build, and that has gotten simpler than it's ever been.

I will happily die on the hill that we are in the best time it's ever been to start learning as a web dev, and I'm excited to see the learning materials continue to catch up. 

Emily: I think that's a great note to end on. , thank you everyone for joining us today, Michael Eve, Theo and Paul. If you liked the podcast, definitely feel free to follow us on wherever you [00:44:00] listen, and we will see you on the next one. Thank you everyone.

Theo: Thank you so much.

This was 

Paul: guys. 

Eve: you.