Mini Ep 5/5/2023
===

Emily: [00:00:00] Good morning developers. Today is May 5th, 2023, and I want to welcome you to our first ever pod rocket Roundup episode in these roundups. We'll be giving you snippets of our best episodes from the past two weeks, so you can catch up if you miss an episode, or just get a quick rundown in between meetings.

We're excited to share it with you and welcome to this week's roundup. 

On Monday we had React team, core members, Joseph Savona and in Satia joining us to talk about React. Forget 

Joe: so forget the idea is that you can just forget about memorizing code. ~You can just,~ you can just forget about that ~as, as a, ~, in react. ~Um, ~

So it started off ~as,~ as really auto memorization where we thought about Okay.~ You,~ when you write, react, the kind of mental model is that ~you,~ you re-render components, ~um,~ and their props flow down to children and the, those children re-render.

Right? ~Uh,~ and so ~kind of~ conceptually you're re rendering the tree conceptually, from top to bottom. ~Every,~ every time there's any kind of, ~any,~ any. ~Uh, ~and then, ~you know,~ react has a bunch of optimizations within that. And one of the things ~that the,~ that the user can do is ~to,~ to add [00:01:00] manual memorization.

So using, ~um, you know, uh,~ react dot memo, ~uh,~ or, ~uh,~ in, in, ~in the,~ in the old days, ~uh,~ should component update, right? ~Um,~ react pure component. So there's ~kind of~ variations of this. ~Uh,~ and then of course, within a component you can use, ~uh,~ use. And use callback. ~Uh,~ and the idea there is you can ~kind of~ figure out, okay, where are my updates actually flowing and which parts like really unaffected.

And if you ~kind of~ add memorization that sort of constrains ~the, the,~ the update to the actual path that matters, right? You have some value that's like flowing from. One component down to one particular leaf, and you can just ~kind of~ avoid all the other paths along the way. ~and,~ and this works really, ~you know,~ reliably, you can use dev tools to figure out which components should have some memorization added.

Go add that, and now , ~you know,~ you're gonna get, ~uh,~ pretty good update performance. But , there is that manual component. You do have to actually pay attention to adding that memorization logic, figuring out like when, ~um, you know,~ as your component of like changes over time, make sure to keep that memorization logic correct.

~Right.~ So if you have ~like~ some new property, you have to make sure that you're checking for it or else you can, maybe your component won't update. Things like that. ~ ~ and so the idea was, okay, memorization is. [00:02:00] Really more of an implementation detail. Like it's not the thing that you shouldn't have to ideally think about that.

What we want is for react to just be reactive. When data changes , ~your,~ your UI should just react to that automatically. ~Um, Uh,~ and , again, like ~kind of~ initially thought about it is just really , ~um,~ getting rid of the need to write, use memo or reactive memo manually.

And over time we ~kind of~ realized it's really about ~this, like ~ The reactivity model that we want developers to think about. I have a value when it changes all the places that it's used will just automatically update, right? ~Um,~ and what that means is unfortunately in JavaScript, ~uh,~ if you create a new array, in, every single render, That is a new array, right?

, two empty arrays JavaScript does not consider them equivalent. ~Uh,~ and so if you do that, react will sort of overreact and say, ah, this is a new array. , I must redo my rendering because you've given me a new value. ~Uh,~ and so the idea is ~kind of,~ think about it as an auto reactivity compiler, is to say, okay, , ~um,~ let's really understand ~the,~ the semantics of JavaScript and make it so that your components.

When they should and not more than they should.[00:03:00] ~Um, and,~ and so that's, that, that's ~kind of~ how we think about it. And of course the implementation of that is memorization. Yes. But conceptually, it really is more about reactivity, ~uh, and,~ and reacting only and like as much ~as, as,~ as, as close as we can get to like exactly when and only when it we need to you

Emily: We also covered how React server components are the next big paradigm shift of React.

Joe: I think the next big paradigm shift is happening now. is server components. ~Um, so, you know,~ I'm sure there will be a thing after that down the road in a few years, but, ~um,~ it, it's, we're ~kind of~ still right in the middle of, ~uh,~ a big shift right now. ~And that,~ and that, that's server components.

~Um,~ I think, ~uh, you know, we've,~ we've talked about this, ~uh,~ a lot and~ I think the, the.~ Depending on your background and how you approach, ~uh,~ react, ~um,~ server components make sense in different ways. ~Um,~ but the basic idea is that server components are react components that can run on the server.

So with traditional server side rendering, you're taking the kind of client side react code and ~kind of~ running it ahead of time on the server, whereas server components are components that only run on the server. ~Uh,~ and ~so, uh,~ they get to run on the server where you have, ~you know, ~ you're right near your data, you [00:04:00] can go, you can have async components , that go and you use regular Async Await to go and fetch data, ~uh,~ and then render a bunch of client components.

And the idea is that, ~you know,~ you can do all your ~data,~ data loading on the server. And then figure out ~which,~ which client component you need to render. And then send just that, that component and it's ~kind of~ props down to the client and then ~kind of~ continue rendering there, ~uh,~ for interactivity , ~um,~ And ~so, you know,~ this has a lot of analogies.

, if you're ~kind of~ familiar with ~like a,~ like a Rails background for example, might think of ~like, well,~ the stuff that you used to do in Rails and then ~kind of~ have rails hand off to react. You can do the rails piece of it on the server in React and ~kind of~ use one framework. a bunch of other kind of interesting things that server components enables. ~Like, uh,~ you can have components that can run both on the server or the client. 

Paige: ~Mm-hmm.~

Joe: ~you know,~ an example would be, ~um, You know,~ the everyone's favorite,~ like blog, you know,~ blog example of, ~uh, you know,~ markdown posts, right?

Where like if you're just viewing the blog, ~um, ~you might as well just render the markdown to HTML on the server so you don't have to download , that very large complicated code to convert markdown html to the client. But if you're editing the blog, well now you can have an interactive preview and use [00:05:00] that same exact component.

And that's the kind of thing that you couldn't do when you were mixing technologies, right? Whether it be. Rails and React or PHP and React or even , ~um, you know,~ some of the other kind of, ~uh, uh,~ MPA frameworks in JavaScript where you mix, right? A different set of, ~kind of~ different code, different types of, ~uh,~ logic, right?

For, ~uh,~ like for example, for Astro or something else between like your Astro components and your React components. And when you use server components, it's all just the exact same technology. And so you can have these truly shared, ~uh,~ components. So I think ~that~ that is a, a really big paradigm shift.

~Uh, and,~ and, ~you know,~ Still early, there's still a lot of people who are like figuring out how to adopt them. ~Um, you know,~ it's still a bit experimental. ~Right. And,~ and ~kind of ~support across the ecosystem is coming along.

Emily: We also recently welcomed on Sunil Pie, a former React Core team member to talk about how he went from working for large corporations to becoming an indie developer, , including developing his most recent project party kit, which Paige asks him about in this next clip.

Paige: so let's talk about some of the features that Party Kit boast.

Sunil: . ~Uh,~ the first one is that the platform is [00:06:00] deployed on the edge. ~Uh, ~the simplest way of saying that is edge networks like Cloudflare's, and . ~Uh,~ I use CloudFlare to build party kit. ~Um,~ They've deployed these servers out across the planet in about 270 something cities, ~uh,~ 10,000 points of presence.

~Uh,~ what that means is that, ~uh,~ somewhere within five to 15 milliseconds of me here right now, or most people, ~uh,~ is a CloudFlare endpoint. ~Um, so, uh, when, ~. When you want to build an a collaborative application, it means that it's going to use points that are closest to you to synchronize , ~uh,~ these messages, these applications that you build.

~Uh,~ simply by nature of using these edge networks, we monitor the next thing, which is that it is as fast as could theoretically be. If I can draw a straight line between Page and Sunil and use that as a way to synchronize. There is nothing that could be faster. ~I mean,~ it might get faster , ~uh,~ if, ~uh,~ Cloudflare's network gets broader, 

~uh,~ number two, we let you bring your own code. ~Uh,~ there are a lot of third party services that enable, ~uh,~ [00:07:00] collaborative, ~uh,~ applications. ~So, um,~ And these are other players in the space with their own strengths. ~Uh,~

~uh, ~, but ~uh,~ one of the things that distinguishes particle is that, ~uh,~ from these others, is that you get to write your own code that runs on these machines. It's not a simple, ~uh,~ messaging system. It's not a database to which you're making queries, even though you should be able to , ~uh,~ deploy your database onto part directly, ~uh, you can,~ you can think of it as ~uh, , ~, if AWS is a. Computing platform, ~uh,~ simply because they don't really care what code you run, but they take away some operational cost and complexity. You can imagine that party kit is, ~uh,~ the a w s, but for collaborative applications that you take some code that runs anytime a user connects to a room or a document, ~uh,~ Particle will handle all the infrastructure underneath that for you.

You just need to bring your Java script and your vam and we take care of the rest.. ~Uh,~ I mentioned how it's faster than anything else, simply because we are leveraging as well, as fast as the laws of physics could, ~uh, uh,~ manage, uh, batteries [00:08:00] included.~ uh, ~

because it's such a brand new paradigm of computing, ~uh,~ the libraries and ecosystem for it aren't a hundred percent there yet. They're getting there and there's a great community behind it. But par kit. Says, Hey, you don't have to reinvent all of this from scratch. You do not have to invent conflict resolution data types, which are a way of building these sorts of application.

And further, it works well with your existing stack. Hey, if you have an application already on a word cell or a netlify, Wherever, \ . ~Great, great team there. By the way,~ you can keep all of that still running except just put the multiplayer networking part onto party kit. 

But all the synchronizing between users and. ~Um,~ so on, ~uh,~ party kit will take care of that for you. So that's sort of what I mean by, ~uh,~ batteries included.

And I think that's also important if we want, ~uh,~ adoption in the community. We want regular folks to build these applications. That's the whole dream with JavaScript. Anyway, 

Emily: , and finally we had Josh Como on to talk about AI taking our jobs, whether using React is a good choice [00:09:00] and the future of web development.

Here, Chris asks him what AI is really going to do to web developers. And Josh has a fairly optimistic outlook .

Chris: so this next thing we're gonna talk about, is, the end of front end development. So it's no circuit to everyone. Like I can't wake up and walk five steps without hearing the word AI or chat G p t or whatever's gonna take our jobs.

I wanted to just get a quick summary in your words, ~like, um,~ what does this address about the future of web development and like,~ like,~ what are your general thoughts about that?

Josh: Yeah, so the idea with the blog post was I was seeing a lot of the discourse on Twitter there's a couple different ways that ~I've,~ I've, I've seen this. One of them is someone plays with G P T four chat, G P T, one of these tools, and their takeaway is ~like,~ my goodness, if things continue to accelerate at this rate, Like G P T four is so much more impressive than G P T three and that was only a couple months ago.

~Uh,~ so you ~kind of~ extrapolate out and you imagine like in a year or two,~ like~ this is gonna be able to do everything that I can do as a developer. And then I think the other take that I've been seeing, which is like,~ like, uh,~ [00:10:00] amplifying this is the people working in AI or who have AI startups who are sharing like in six months we won't need developers anymore The reason I felt compelled to write this blog post is I didn't like how certain everyone was seeming about this because , I'm not an AI expert, but I've learned enough, ~uh,~ just from experimentation and reading about it.

And it isn't clear at all to me that that's the way it's going to go. Like certainly the things that it can do are really impressive. But you know,~ But you know, like the most,~ the most common examples we're seeing, ~like,~ there's that joke website where you give chat G P T , a photo of a sketch that you took.

~Uh,~ and , ~you know,~ in the photo there's a button, you click the button and it gives you a joke. You feed that into this magical AI machine and it spits out an H T M L document that has the JavaScript wired up to actually generate the joke. But then you look at the code that it produced and it's ~so, so,~ so different.

Like ~it's,~ it's so far removed from the work that we actually do as front end developers. And I think that, ~you know,~ you know, it's impressive, but there's so much more to our job than what I have seen, ~uh,~ the AI do. And it's not always evident that ~like~ the pattern continues forever. Like certainly it's gotten a lot more impressive.[00:11:00] 

The analogy that ~I,~ I thought of recently that I like for this is like,~ like,~ if you had asked people in 1970, ~like~ a year after we landed on the moon, how long they thought it would take us to get to. They probably would've said like a few years, ~like~ you see that they can get to the moon, and you assume that getting to Mars is just.

Look at how far we've come, we can get that further. , but you know, scale brings complexities of its own. And the reason I'm skeptical about this is that, ~you know,~ the AI tools are ~really,~ really good at predicting texts, and that's ~really,~ really useful for like short code snippets.

But with larger projects, ~I,~ I just, I have a hard time believing that it will, ~uh,~ understand the nuances. Given that it doesn't have any way, at least as far as I know of validating its assumptions, so if it thinks that it works a certain way, It doesn't really have any way to, it can't ~like~ run the code, see the result and then adapt it.

Like you can run through that loop with it, which works well for smaller snippets. ~But, you know,~ I think we're still, ~uh,~ very far away from the future of ~like~ a non-developer sits down with a chat bot, ~uh,~ explained that it wants like Uber [00:12:00] for cats or ~like~ whatever startup idea people. And in a short couple of hours back in having ~like~ a back and forth dialogue, it spits out ~like~ a production ready, secure, accessible, full stack application with the database and everything else.

~Like~ that just to me feels ~like, uh,~ that's the, not just going to Mars, but ~like~ going to another solar system. ~Uh,~ I don't know how, ~uh,~ and I could be wrong, like the thing that. ~You know,~ I don't wanna be hypocritical. I am irritated by the confidence people have, and I am not confident in my own assumption here.

So maybe I'm wrong, ~maybe,~ maybe. ~Uh,~ we are pretty close to that happening. It's just from everything I've seen so far, ~like I have not seen any, uh,~ nothing I've seen so far has made me, ~uh,~ believe ~that~ that's the future, that we are only a couple of years away.

Emily: And that's it for today, Friday, May 5th. You can check out the full episodes linked in our show notes below or on our feed, and if you liked what you heard, follow Pod Rocket. For more great web development content. See you at the next Roundup. This episode was brought to you by Log Rocket. You can try it free today@logrocket.com[00:13:00]