Programming Throwdown - ReactJS

Episode Date: May 22, 2020

Hey all! In this episode we chat with Guillermo Rauch, co-founder of Next.js, about ReactJS. ReactJS is an amazing framework for web development that I've been a huge fan of for years. We dive deep into how ReactJS works and why it can lead to clean, structured development. We Introduce Next.js, a ReactJS framework that supercharges web development at scale. I recently built a site using Next.js and loved the developer experience! Check out the show notes for links to learn more about Vercel and Next.js. Show notes: https://www.programmingthrowdown.com/2020/05/episode-101-reactjs-with-guillermo-rauch.html ★ Support this podcast on Patreon ★

programming throwdown episode 101 react js with guillermo roush take it away jason hey everybody we are here with the uh ceo of vercell and a co-creator of Next.js, Guillermo Rauch. How are you doing today? Excellent. Thanks for having me. Cool. Cool. Thanks for being here.

So I think this is super, super interesting. The only thing I've talked a lot about on this show is for people who want to just get into coding, try to build something where you can interact with it and even better something where other people can interact with it. You know, that's the way the hardest part about getting into coding. This is true if you're listening and you're a high school student, college student, or if you're coming to this from another profession is just keeping motivated. Right. And the best way to stay motivated is to have something you can show someone. And really the best way to do that is with the web. As someone who's rolled out desktop apps,

I can tell you it's a huge nightmare. A little bit easier on mobile, not that much. But on the web, it's beautiful. You can just reserve some space on AWS. If you're a student, it's beautiful. You can just, you know, reserve some space on AWS. If you're a student, it's free. You know, put your site there and other people can interact with it right away. And so, you know, we're here with Guillermo Rauch, who is the creator of Next.js, which is a platform for basically making that whole process, you know, more beautiful and streamlined. And so I think it'd be great for the audience to just

kind of get a bit of background on if someone comes to you not knowing anything about how front-end dev works, how can you sort of wrap that up for them? Yeah, so that's a good start. Front-end and back-end are kind of the two divisions that we typically make when you think about how a website works. Front-end being the part that your visitors and your users interact with, and back-end being the systems that support that front-end, that are typically more related to reading and writing from databases, talking to other services, talking to other APIs, etc. Next.js is primarily concerned with the front end, and React is primarily concerned with the front end. The big thing about React is when we used to make websites in the past, we didn't have good ways of kind of

organizing them, kind of having the abstractions for making them work in ways that were very cohesive. So React came out of Facebook open source with this idea of websites and web applications are actually made out of components. That is to me the big breakthrough that React has really come up with. It's this idea that I've called it in the past,

Lego blocks for adults. All right. Because as you were saying, when you're starting to create something new, you need building blocks, right? And when you think about front-end development, the building blocks that has emerged with the rise of React is a component.

So anything that you can, it's funny, like the metaphor, like anything you can build with Legos, right? Like you've seen people build all kinds of things, right? From sticking two blocks together to, you know, building amazing machines. And I think of it that way with React as well, because if you're just new to programming you can you know build a blog so before we started the call i was telling you that uh when when we tell people about learning to make a website with next.js we point them to next.js.org learn

and that walks you through creating a blog and that blog is built with react components but with our technology what we've seen is that people have really built anything you could imagine so like hulu.com uh their entire marketing website but also their viewer for you know when you're watching a show on hulu online it's all built with next.js and react components so that's awesome it's an an incredible technology for just organizing this universe that is a front-end development workflow. Yeah, one thing that people might not know, I've been getting really, my son's been getting really into Lego. And so I've been watching a lot of Lego videos with him. And when they build these huge Lego structures, like if you go to the theme park, right, and there's these enormous Legogo you know like like refrigerator sized lego things

is that they actually have something similar they have this module structure which is you know a group of legos and they have people kind of just assembling these sort of building blocks and they have other people taking these larger lego pieces these modules and sticking them together usually it's not just done one Lego at a time. And so what you're saying is that React and Next let you do that for the web. Yeah, it really is a good metaphor because what you're describing is effectively what happens when Next.js developers are building really large things, right? I use Next.js also for my own blog, and obviously I just work on it myself.

I write about different things. I include components sometimes that are more interactive or sophisticated. Like recently I wrote about code golfing and I embedded a code golf demo. So that's like a really nice property of the web. What is code golf? I never heard of this. So code golfing is basically a competition that happens between developers on who can accomplish a certain outcome or a certain output, usually with the fewest number of characters. And since we were on the subject of learning to code, I wrote this blog post about why code golfing is so great. Or in general, little fun competitions are such a great way

of learning to code and there was this website that i point out called code-golf.io that basically has this remote verification system to make sure that you give them your program with very few headers and they ascertain that you know you're getting to the right output and just like golf you're doing so with the fewest number of strokes right oh that's cool oh now i now i get the metaphor that's awesome yeah um yeah so i wrote about it and um and yeah like i said like my blog is just you know not many components and it's for the purpose of just putting some content online, right. But when you when I think about the teams that we support at larger enterprises, they are doing exactly what you described, they sometimes have what we call the design systems,

where their whole point is to build this, not just now Lego bricks, but you know, you could think of it like stacked Lego bricks or more complex shapes that then their team can reuse. So they're building those modules that you were talking about, almost like, you know, supporting them so that, you know, we know that every website is made out by a series of components that are like buttons and forms and header navigations. And so you can sometimes say, okay, I'm going to invest ahead of time in having a team that'll dictate what those reusable larger pieces are. And they'll dictate also a visual design language that not only looks like the brand and, you know, retains the colors that represent the brand or the system, but also work really well. You know, like the thing about the web in contrast to native mobile development is that sometimes it feels like you're always

starting from a scratch, that you're always starting from an empty canvas, right? Like you start an HTML file and there's nothing there. And you've probably seen this, but like the default style sheet of a web browser is just downright gross. And it's not consistent either. The text flows from end to end of the screen, which I'm not an expert in typography but

like and typesetting but like i know that people are not able to read comfortably if text flows from one edge of the screen or the other edge of the screen right so the web has always felt like this heavy lifting in contrast with like you know apple's design guidelines and their built-in component set we're like they've spent you know decades thinking about you know what makes for a great user interface and they give their developers kind of like a lot of pre-existing lego bricks the web and i think for better is is a very um medium where, you know, you're free to publish anything and you're free to build it however you want. But in turn, what happens is teams and people tend to have to build their own component systems so that they have this kind of reusable layer. And that's how they scale their companies and their systems. And it's been a really nice

trend to watch because, you know, at our company, we've built our own design system and we're putting in constraints in there that are very interesting, for example, for accessibility. Like we make sure that our buttons react in certain ways to user input so that they're accessible to people on, you know, screen readers and things of that nature. And components can also make sure, you know, that they have the right font sizes so that, you know, the developer doesn't have to come up with it. They don't have to really decide that every time they build something from scratch. They're like, what is the right font size for this? What is the right amount of padding for this? So this has really all been enabled by React creating this idea of you are, as a front-end developer, your job is to define components.

And by doing that, they kind of elevated the abstraction bar. Because in the past, when you were programming with JavaScript and you were working on your front-end, you had primitives that were, to put it lightly, too primitive. So if you were working with full stack legacy technology, you were working with templates. And then on the client side, you were working with functions or you were working with classes, and there was really no structure to how you were doing things. So React came in and were like, okay, what you're building is not a function per se.

It's not a class. It's not a template. It's a component. And by doing that, they've really just revolutionized front-end development. Yeah, I mean, I think with, and this might be different with HTML5. You could check me on this. But, you know, at least with early HTML, you were limited to the tags that the browser provided. So there's a button tag, there was an input tag, a head tag,

a body tag, paragraph tag, but there isn't a calendar tag, right? And so when you're writing your HTML, if you get to the point where you need to drop in a little calendar, you have to use this tag called div. And then what you have to do later on is you give that div an ID, which says, you know, my great calendar. And then later on in JavaScript, you would have to basically fill that div in with with with with, you know, the logic behind that calendar, which is going to be composed of all of those tags that you do have access to. But then that makes things really frustrating because you end up with just a whole HTML file

full of divs with different names. It'd be great if you could just have a calendar tag. And that's basically the premise behind React. Yeah, yeah. And doing so, by the the way proved very challenging right because what you were describing is a great kind of uh historical review of how websites used to be made and you mentioned that word id right and that's kind of the how a developer would approach kind of giving life to an html tag And even the very idea of an ID was very limiting

in terms of the reusability of the Lego bricks because an ID was pointing to a specific element. So from the get-go, you weren't designing something that was reusable. Like you couldn't clone your calendar and use it in different places of the system, and it wasn't parametric. So that's why I was saying that components is such a great abstraction, because typically what would happen is like, okay, I have this div, and this div in particular that

lives in this very page, I'm going to convert it into a calendar. And it's going to exist with fixed parameters. It's going to be this big, it's going to be this fixed parameters it's going to be this big it's going to be this wide it's going to be set you know the default date is going to be today but tomorrow another developer was like oh hey i need that calendar but i need it more for like i know selecting your age and i need it for like uh you know other years and the default should be i don't know like 20 years ago and then they would be like oh i maybe the best thing i can do is copy paste here and fork the calendar into two calendars and like it was really messy and it's crazy to think that you know like that was not that long ago we're programming like that yeah that's right probably some people still program like that so yeah and and it's also not

for you know it's not really their fault because you were saying, the web emerged for hypermedia. And it was a specifically a very narrow subset of what historical review when the web was being discussed in this open mailing list and like they were discussing the early you know uh standards and emerging standards and the early web browsers there was a lot of resistance to adding power to the web and and it was for a good reason because there were all these interesting constraints that the designers of the web had for, you know, how well the web should work. So one of the things I always point out is there was a very heated discussion about adding images to the web. And it's a discussion in which Marc Andreessen, the co-founder of Netscape, is involved. You can look it up today because it was a public mailing list. And you can see how there was resistance to adding, in that particular case, an extra hop to the information transfer process.

Because when the web was created, you would request an HTML file from a remote server, and that contained the entirety of the information that you requested. And the constraints were there because obviously at the time we didn't have good, you know, internet connections. So we're working with what we had. So like, you know, you were sweating every hop,

like, you know, like it was the end of the world. Yeah, I mean, everyone's seen this, you know, where you get a little square with a red X instead of the image. And that's because it didn't come with HTML. and correctness, and performance of the system. But at the end of the day, the free market, so to speak, because Marc Andreessen was creating a new web browser, right? And he was coming from, I could imagine him in Silicon Valley saying, like, the web could be doing so much more.

We could have images. We could have video. And in the future, people are going to be telecommuting and doing telemedicine and like you could have all these dreams about the web, but the web was super constrained. So it was a slow process, but the web started getting more and more power and more capability. So, you know, that created the image tag. But as you were saying, the web goes through this process of adding things to standards so as we stand today we actually don't have a calendar tag you know i mean like it's been it's been 30 years and through sweat and tears we added things like you know image tag to html but we still don't have a calendar so but but um you know if someone

is listening today they were like oh i just I just filed my taxes online or whatever. And there was a calculator right there. So that's what you're dealing with is basically the ability for the web to grow its own component set thanks to the help of JavaScript, which can sort of take all this primitive HTML tags like div and turn them into very interactive widgets right and in a way the github uh you know with npm and github and and the github star system you can kind of get a standardization through democracy right so now what people do is they say react.js calendar cycle and github.com they punch that into google they find some calendar uh component that has you know 100 000 github.com they punch that into google they find some calendar uh component that has you know a hundred thousand github stars and they grab that and and so does everybody else and it creates sort of a nice sort of gnosis like people now have this sort of unconscious understanding

of of of the calendar because they've seen the so the same similar calendar so many places. Yeah, and this open system, right, I think takes longer. The open system makes it such that, you know, we've been through generations of broken, inaccessible subpar calendars, but there's always this constant iteration process aided by what you were saying, like all kinds of different scoring mechanism

and popularity mechanisms. And, you know, people just wanting to beat the horse that is not yet sufficiently dead in some ways. Like I've seen so many times that like, I consider a problem to be solved on the web and then I see someone doing it better. You know, like they just make it smaller. They added an animation that, you know, I didn't think of.

They make it work better on mobile. Like the web is just this constantly iterating system. But for people that are getting started, you know, it doesn't mean that they have to go through that. It doesn't mean that they have to build their own components. So you can always choose from libraries of components that other people have made. Like in the Next.js world, we know a lot of people use Material UI, which is like Google's component system that is open source. And it's being distributed today as React components.

There's another one called Ant Design that came out of Alibaba Cloud in China. It's very popular as well. So companies have also open sourced their entire component systems, which is really nice. Yeah, that's awesome. Yeah, so maybe just like we could talk a little bit about how React does this. How does React add components to HTML? I think that would be really interesting. Yeah, that's super interesting because one of the things that I always point out that

React has been really revolutionary for is the programming model. So when React started, when the authors of React were kind of presenting it to the world, they were saying, look, React hasn't been so much inspired by previous JavaScript libraries, like jQuery and so on. They were saying, listen, this is an altogether new thing. And I think because of that kind of narrative, they were dismissed a little bit in the beginning because you know a lot of people were telling you like sit down this is completely different and then you end up being disappointed right but in this case it was true so react wasn't so much inspired by previous uh what we call imperative dom manipulation libraries so dom is the uh basically the way that you interface

typically between javascript with those html, they said it was more inspired by how game engines paint a screen. And this is really what also, in addition to the introduction of Component, which is not altogether new, and there were all kinds of widgets and widget systems all over the place, including jQuery UI, but what was truly revolutionary was this idea that you're not really giving specific instructions to the computer when the user does certain things. You're always saying to the computer, hey, for this state of the world, I want the entire screen to be like this,

almost like a mapping from data to screen in a way where the developer didn't have to think about the deltas. So for example, say that you're programming a clock, right? And you want the time to be rendered. I'm in San Francisco right now in the time zone of San Francisco. The primitive value of the time, let's say it's a timestamp, it's an integer.

And then I want to say every second, I want to update the screen, and I want to render the time formatted to the time zone of the user, which is, I'm in San Francisco right now, and I want to decorate the clock in some way or another. When we used to program that with old technologies in the web, we used to have all these imperative codes. So for example, we would say, okay, it's the beginning of time. So let's render the time for the first time. Then we would like put in that code. And then we would create a timer that says, hey, every second, take that and update it. So basically there was this distinction in how you would program. There was this idea of time that was being embedded in like, okay, this is the beginning.

We painted like this. Okay, now changes are coming. I have to go and look at the screen and make this specific change. Whereas React came in and said, look, you're just going to describe what the screen looks like. And we'll handle all the updates to the screen for you we'll handle for example um if you register the time to change uh every n seconds and we have to make a manipulation to the screen we'll do all that you just tell us for this particular data how you want the screen to look like and what components you want to involve in that

yeah it's kind of like uh there's something similar with with with the graphics world the computer game world like for example with open gl if you just use pure open gl you have to say you know draw the triangle wait a 60th of a second draw the triangle draw the triangle draw the triangle triangle move next time draw the triangle. But if you do something like Unity, you just say, I have a triangle and it's at x equals 3. And then you could wait a day or an hour or a minute, whatever. And then say, okay, now my triangle is at x equals 6. And Unity is responsible for just saying, draw the triangle. You're just saying how the world looks.

And you let Unity, the game engine, engine handle drawing it and so react is kind of that for the web exactly and the web we were working on the web exactly like you were describing with like almost like accessing the graphics card we were working on such a low level that we were concerned with things that could be basically automated i remember when ria was getting really popular a lot of people were comparing it to automatic garbage collection and going from manipulating memory manually to letting an engine do so automatically. And the metaphor is really good because the best example is in modern, very complicated software programs, you're not just dealing with like moving the triangle from A to B, you're dealing with the user saying, well, now forget about it. I don't want to try or want to

go elsewhere. And you have to ditch the triangle and you need to like get rid of it entirely from the screen. And if you think about the old world and how we used to program, we would use what we would call CSS selectors. And we say, hey, okay, the user wants to go somewhere else. So first let's clean up the screen and we'd be like, select the triangle dot remove. And we literally write that code. We invoke a function to handle this deltas of the screen's contents ourselves. So you can imagine how buggy programs were because, you know, a developer that is working on like millions of different things sometimes but it was also this transition away from imperative programming to declarative programming and just involving techniques from functional programming a lot more. Yeah, it totally makes sense. Like in Excel, right? Excel, you set up

sort of these equations. And then as your data changes, you don't have to go back and recompute anything. It's just kind of, it's reactive. And so React.js is also reactive in that way. Yeah. And, you know, a lot of, there's been lots of debate about whether React is a truly reactive system in the, you know, formal definition of the technique. But the reality is that what you're saying is absolutely right. Like the developer that works with React today is more concerned with manipulating data than describing, okay, my screen should look like this for different versions of that data. And then they're not concerned with adapting the screen when the data changes.

Much like you're saying with Excel, when you change a data point, you're not going and updating all of the data points that depend on that data point, right? You're not doing any of the manual calculations. That is, in fact, the true power of Excel. So React is kind of bringing this

in front of developers, which is really, really fascinating. Yeah, totally makes sense. Hey guys, we're going to take a little break to talk about University of California, Irvine's Division of Continuing Education. So this is a pretty cool program. They have a variety of different

kind of certificates that you could acquire. They have things like Python, they have data science, they have machine learning. And these are things where, you know, kind of certificates that you could acquire. They have things like Python, they have data science, they have machine learning. And these are things where, you know, if you didn't necessarily get, let's say a degree in machine learning, or you haven't worked in a, in a, in a, as a machine learning engineer for a bunch of years, um, this is a way to sort of get a lot of that knowledge, a lot of that expertise. And, you know, I know Patrick and I, we've both done a bunch of courses online. And so it's a really good way to sort of boost, you know, your knowledge and your skills in a particular area. Yeah. I mean, I did tons of online classes when I first started working. And, you know, for me, being part of a class, I mean, it's always

interesting. But the curriculum, the self-paced stuff, it works great sometimes. But sometimes having a here's what we're doing each week, marching through their curriculum and going through it, it's very similar to how, you know, just a normal university class works. In fact, you know, feeling like it's almost exactly the same is just a comfortable thing, a good way to learn. And learning from professors who, you know, that's their thing. They teach, they help others to learn and having access to it, doing the assignments. It really helped me go from, you know, where my undergraduate left off to, you know, to just kind of bootstrapping into more specifics, higher level things, things that were more pertinent

to my job at the time. I, you know, I, I highly recommend people taking classes, continuing education from a, from a college. Yep. Yep. Yeah. I think getting it through a university is, is actually a really, really stellar. I mean, it's really awesome that universities are starting to get into this and, um, you know, you know that there's going to be sort of quality lectures and professors. There's a very strong brand behind any sort of major university. And UC Irvine is one of the top universities for CS.

So they've been around since about 1962, I think. And they've been around a long time. They've been doing, you know, they've been teaching a long time. They've been teaching online a long time. And so it's a good place to go and get this kind of education. Yeah. If you're interested, I think they're still doing enrollment for some late classes for spring, but summer's upcoming. And as you've been talking about this whole episode, I mean, I think everyone has extra time at home these days. Oh, my gosh. If you're interested, you can check it out at ce.uci.edu slash programming throwdown. And we'll put the link in the show notes, of course.

But once again, that's ce.uci.edu slash programming throwdown. Yeah, and if you do sign up and take any courses, we'd love to get feedback. Please write us in. Tell us what you think of it. We could pass it on to them. But also for us, it's really good to know what you thought about that, folks out there who are listening. So, all right, back to the show the thing about react that um might be a little tough for folks is um is you know there's the the um uh jsx like there's

like a the way you sort of mix the html and the javascript i know that throws a lot of folks off um but nowadays you know with the uh really nice ide support, that makes that whole process a lot easier. I mean, you get the right syntax highlighting, and the IDE will tell you right away if you do something wrong. And so I think combining React.js, for new folks, combining React.js with a good IDE and a good development system is really important. Yeah, and this is kind of why we invented NGIS too, right? So React started as a mechanism for kind of being able to capture the emerging and kind of relentless complexity that was growing within Facebook's code base. You know, there were classes of bugs, categories of bugs that kept

happening that were frustrating the developers who were saying, you know, like, I think one of the interesting things that I've learned about software engineering is that the appreciation for categories of problems rather than problems as independent, unique things really makes a world of difference, right? Like, you don't want to spend your time fixing, like things, novel little things that come up, you try to say, okay, this belongs in this category of problem. Let's try to find ways that we can fix the category, rather than patch each issue as it happens. Yeah. Fixing the root cause, right? And there were categories of issues that were happening within Facebook that are very much related to what I was sharing earlier.

Like, hey, I'll give you an example also with the clock. Cleaning up stuff when something that was on the screen is not there anymore was always a challenge for web developers. For example, the clock has to repaint every second so that we can make the time change, but we can make, I don't know, the column flicker so that we have a nice animation for our clock.

What happens when you navigate away or you just go to another portion of the system where that clock is not there anymore? So a category of problem that would happen a lot was like the developer would correctly remove the clock from the screen because that's a clock lingering there that you didn't want but what they would forget is it cleared the timer that was trying to every second um clean up the update the clock and do an animation whatever so um the interesting thing about this is that it would be completely silent that timer would be running in the background because of an implementation detail in jQuery which is a library that people were using a lot of the time, which when you would select an element that was no longer on the screen,

it would just swallow the error. So basically, if no HTML element matched your selector, in this case, the clock was not there, and you were trying to do something, like update it or whatever, jQuery would just say like oh it's all okay and then you would have all this load accumulating in the background that is completely invisible to both developer and user so this is really bad you know especially at the

scale of facebook where like people spend a lot of time on on uh like navigating their news feed or there's lots of things that are constantly updating, right? Like you've seen how likes update in real time. You've seen how comments update in real time. Now they incorporated that your friend is typing in a newsfeed post. There's video, there's polls

and everything auto updates. So imagine managing all that complexity manually, all those timers, all those subscriptions to real-time updates from the server. It was resembling a very complex video game, really, with lots of characters animating on the screen and things like that. So when they needed to solve these categories of problems,

they created React. But what we noticed, and this goes to your point about usability and IDEs and making things easy, is that people needed a very easy way of using React for everything. So Facebook at the time was concerned with incrementally adopting their own invention and solving, you know, the most pressing problems. Like, if I remember correctly, I've heard in their team that, you know, the notification center was something that they wanted to fix immediately with React. The chat windows that kind of hover over your screen is something they wanted to fix with React. Like more of the challenging pieces of the UI that, again, deal with lots of data updates. So as of this morning, I was reading on Twitter, like people were annoyed that for whatever

reason, a bug on the system, like the notification count is not updating correctly. So those are kind of the pressing things that Facebook was solving with React at the time. But what we noticed is, hey, this model that Facebook is using for very specific components, what if we could use that to build the entirety of a website or the entirety of a web application? What if React is your starting point and React really kind of becomes your language so that you don't have to relearn all these painful practices of HTML and jQuery and imperative programming. What if you could just start your project and everything is already configured for you? React is configured. All the production optimizations are figured out for you.

The compilation pipeline is figured out for you. And all you say is, hey, I want to start a new Next.js project. And this is kind of how Next.js was born. In fact, the need that I had when, like, React was already open source and it was already getting a lot of traction, but I needed to build one page with one form for a company to receive emails. And I was like, you know, it's very hard to assemble all the pieces. React is awesome, but starting from scratch is so difficult that it felt like you were

configuring a compiler and writing a file. Yeah, just to give some insight into this, so yeah yeah the react is you know you don't like in react you can have a calendar tag right but html as we talked about doesn't that tag doesn't exist so react has to do is it has to turn all of these tags that you invented um you know into the into their you know basic components and it does that by by basically compiling a lot of these files down into essentially another language or some generated code that's not human readable. And that process is pretty expensive.

It takes time to do all of that. There's challenges around hot reloading. Ideally, you want to change a component and see the result right away. Or at least you don't want to have to compile every file. There's just so much complexity there. And there's Create React App, which is a wrapper project

that gives you kind of an initial react app with a lot of the bells and whistles but um but even that then is now complicated and so you have to do with like proxies and and a whole bunch of other things there and so yeah and what you're saying it really goes to the heart of the problem right like the reality is that react is not a native thing of the web again going back to like how the web was created and like how it was evolved and the standard systems that are around it react is like a foreign body in all this right like it was something that a company invented it was made open source and it interoperates with the primitives of the system. The primitives of the system are HTML, JS, and CSS.

So something that MixJS does, for example, is really interesting. I was giving the example of the blog. So if you're designing your blog, you're thinking about it in terms of components. And we use this JSX language that allows you to refer to components as if they were HTML- looking tags inside your code. So when you're designing your blog, you define a function called blog and you say return and you include the header tag and you include the blog post tag, which are all these components, and they include the heading component and the text component and then the footer component

and then the contact form component. And you return that. And it's really nice because if you have, if you think in terms of math, you're writing these functions that have a discrete input and a discrete output. It's a beautiful thing. So like you're basically just returning components

from a function body. But what happens is, again, the web speaks a different language. It doesn't speak components. It doesn't speak JSX. It doesn't even speak the new versions of these languages that people want to use. So that's where the compilation step comes in. So an interesting thing that Next.js does is that for the first impression of your website, we compile it down to HTML and CSS. So that is super, super fast. In fact, no JavaScript has to get loaded for your visitors to get, again, primitives of the web, HTML and CSS that you didn't write by hand because you

were speaking the language of components and you were having a very nice and easy time creating your system but again we have to interoperate operate with the web that has you know billions of devices all the different versions and browsers and so on so that's where next.js is kind of like hiding all this complexity from you and it's quite you know it's quite interesting what we call this developer experience right like this is kind of the term that emerged we used to speak only of user experience ux and then at one point this word started getting traction called dx right developer experience because again like doing all this juggling of what the developer wants experience to be but then on the other side, we have this kind of,

I'm not going to call it legacy system, but we have this very basic system that is a different version because of different web browsers. And we needed to build that glue to kind of make those two worlds compatible. Yeah, that makes sense. So can you explain to me a little bit, what's the, you know,

what does Next.js build on top of React.js? So in both cases, you have JSX, which is not something the browser can understand. So we compile it down to, at least in React.js, we compile it down to HTML that's being generated by JavaScript functions. So you have this JSX file. It has a lot of these HTML tags that don't exist in the browser. And so the compilation step, you know, runs that, basically like runs through that file looks at those tags and then kind of recursively goes through and and and replaces them all with the with the right thing from from something the

browser can understand and so what is next.js build on top of that yeah so one of the biggest things that next.js became very very popular for for that, for example, Create React App doesn't do. And this is not because Create React App existed and we're like, oh, we're going to fix it. But they both kind of came out at the same time. It's pre-rendering. So this is one of the pieces of Next.js where most of the investment went into. And it's why it's been chosen for many, many large websites and web properties that receive lots of traffic. So pre-rendering means, as you mentioned, there is all this JavaScript that has components, that has JSX and so on.

But we already know with the data already in there uh instead of an empty page with a lot of java strip that then has to make an hdp call to the to an api or or whatever again like that's why i mentioned this single principle of the web right like um we we host lots of news websites for example right and when the visitor comes there's kind of two worlds here like one world is you give them an empty page like no html only like a root element and you give them a big bundle of javascript that then when it boots up on the user's machine and and if you're if you've used the web a lot you probably see this sometimes and you get an empty page, and then a long time passes, and then some content magically appears. So we wanted to prevent that,

because there's large categories of pages on the internet that, you know, they don't need that extra hop. So Next.js became very, very popular because of this pre-rendering technology. And so that's kind of one you were asking at the compilation yeah that makes sense technology is underneath the other is that again uh we don't want to make the web dumb we want to make it very powerful this is even you know what react is really good at so what we do is we can take the pre-rendered markup and then we hydrate it on the client side. And then you can

kind of bring in endless interactivity to the website. That's why, you know, like kind of something that I kind of became a hill that I've chosen to die on for many years now is that I don't really see a distinction between a website and a web app. It really is just a matter of the developer deciding how much of the content is pre-rendered or not. You might find that some websites only pre-render very little because the content is so naturally dynamic, right? So like if you're building a multiplayer chess website, well, when you first load it, you know, there might not be that much to pre-render because again, like there's a lot of animation and interaction and the data, maybe it's stored on the, even the

local device rather than on the cloud. And there's all these needs for a very dynamic client side rendering and hydration. But if you're building a news website and something recently that happened is that, you know, we noticed that when governments were kind of, you know, rushing to get stuff out about coronavirus, they would put it on systems that would immediately collapse in their load, that would be slow, or they were taking too long to get the information out. And this is why for us, pre-rendering has been such an important feature because if you're going to tell somebody, you know, what the three-phase plan is for, you know, releasing the lockdown in the US, you're better off putting out a pre-rendered page that is primarily HTML and CSS that scales tremendously well with huge spikes of traffic. And it kind of becomes your, you know, using the web as a printing press,

I call it, right? Like you pre-rendered a page and that pre-rendered page becomes infinitely scalable. It's like a magical pen that you could distribute across the world. But the magic- So if I could sort of just recap for folks the audience so the idea is you know originally you had html and you had javascript

and they were in separate files so someone would go and download the html file it would have and as we talked about earlier the image images were in separate files so you'd get the html file that would have you know none of the images and no logic, but it would have a lot of structure, and it would have all the text, and it would have the structure, the layout of the page. You would download the JavaScript then next, and it would have logic that could then go to a server and pull some extra information or not.

You don't even need a JavaScript to have a website. And it would pull all the images, right? So then when you switch to React, what you end up with for most people is the HTML page is effectively empty. And all of the React components end up turning into JavaScript functions. So you download this empty HTML file, you download this enormous JavaScript file, and then you kind of call go on this JavaScript file, which then recurses, creates a bunch of functions or launches a bunch of functions all of those create this massive string of html and then that ends up replacing the empty html um and uh and that's how you can have things like a calendar tag which aren't which don't exist right and so what you're saying here glia is that is that with next js

oh yeah just to finish the React thing, and then because these websites are sort of living, breathing things, you also have an update function. So every component has your sort of render function, and then you have the ability to sort of call that again. So it's kind of on you to say, hey, go fetch some data from the network, and then call render again on this component. Yeah, I'll even say that the calling the render, this is what's fascinating.

The calling the render for all the parts of the screen that could have possibly changed is done by React, right? So like going back to your great Excel metaphor, your job as a developer is just mostly to alter the data. As you said, with networking API calls, even sometimes like reading or writing from the local device. But then React just like says, oh, I'm going to repaint. I know what parts of the screen need to get repainted. I'm going to repaint them, right?

So there's very little work for you to do in terms of re-rendering things, which is a huge time saver yeah yeah but you still have to you're still responsible for for basically using some kind of you could use a observable type thing but but you're responsible for going out you know uh if you're if you're let's say uh if you're doing the chess example you're responsible for going to the server saying hey has the other person played yet the server comes back and says yes they have and then you have to update that um you know somewhere whether you sort of yeah however you do that is up to you but you have to go and update that um yeah and so basically so when we when we uh talk about react especially for those that are going to go deeper into it

we say a component has a state and it has a render function. And the render function returns HTML as a function of that state. So it's almost like a bijective function of, hey, here is state. It has the properties of the board, where all the pieces, and then we return a bunch of components

for like the chess pieces and so on, and React does all the heavy lifting. Yeah, and so, you know, for some of these components, the state might change very often, right? But for some of them, you know, maybe the state, you know, going to your calendar example, maybe the state just holds the day you wanted to start the calendar on. And so, for that reason, the that reason, the state isn't changing all the time. It might change if someone picks a day, but let's put that aside for now. It's not changing every minute or anything.

And so actually the majority of your components probably change very little or none at all. And so what Next.js does is it says, let's look at the initial state of all these components. Let's call that big function that generates that huge bunch of HTML, and let's send that instead of the empty HTML. And then if there are changes, you know, we'll handle them. But at least that very first thing, which is really expensive, we could do that on our side so that each browser doesn't

have to do it yeah yeah that that's exactly how it works and so to give you context on this transition we went from the web just being html that was like non-interactive at all and it was all coming in one hop and as you know this kind of rich JS applications with components were kind of growing and pricing, we kind of went all, we overcorrected it the other way. And this is kind of the story of how progress is made because then we've had to bring it back to the middle with Next.js a little bit, right?

Because we went from, oh, now you go to a website and you get nothing in that initial response. You just get lots of JS that your phone or your computer has to boot up the JavaScript virtual machine, you know, interpret, compile it, optimize it, parse it, and then spit back out some HTML,

which is really, we're talking about that OpenGL triangle. That is how the information will actually come to your brain eventually, right? The way that, you know, data is transformed into pixels on the screen today is that fundamental HTML or DOM, you know, data structure. So we were adding latency and we were adding, as you said, megabytes of JS that had to be downloaded before doing anything at all. So Next.js was like, okay, that cannot be the only way. That's one good way for certain things, but that cannot be the only way to build things.

So Next.js added this idea that, hey, you have all these components and all this rich JavaScript. How about we also try to pre-render it so that the user can get content and data right away? And this actually made React just way more broadly accessible and more broadly applicable to things where you would dismiss it sometimes.

You would say, oh, no, I cannot build a landing page with that. I cannot build a coronavirus instructions page with that. I cannot build a blog. I cannot build a news website. I cannot build all kinds of systems. And going back to the hill that I die on is that I don't think any system has ever fell in one direction or the other. You could have the most dynamic system in the world, but it can assure you that there are pages that are fundamentally somewhat static and you could have pre-rendered market for. I remember the first experience that I had with this thing was like I was building a very dynamic system with React and then I had in terms of service of my system

as a separate file, right? And this was all written with components because that's how I wanted to build the world. I wanted to use this Lego blocks. So I built the terms of service with React. And then the naive compiler that we had at the time was shipping the terms of service together with the rest of my application in one gigantic JS bundle.

Anytime the user wanted to do anything at all. And as you know, a lot of visitors of the internet don't ever even go to the terms of my application in one gigantic JS bundle, anytime they used to want to do anything at all. And as you know, a lot of visitors of the internet don't ever even go to the terms of service, unfortunately, right? But that's what happened, right? So like, we, we were so naive with how we would bundle things, that we ended up with this gigantic, just like apps that were getting downloaded. And for a time, we kind of mitigated that with, you know, CDNs and whatnot. But then we started realizing, like, why are we shipping all this code that the user is not even interested in going to yet? Right? So another feature that Next.js added that was quite interesting was what we call pre-fetching. So we have pre-rendering,

and then we also have pre-fetching. So for people that are used to visiting very dynamic JavaScript apps or single page apps, as people call them sometimes, you know that the transitions are super snappy and that really feels awesome. So you touch something and then you immediately go to it. There is no delay. There is no perception that you're going to a remote server or anything like that. So as it happens, we wanted to retain that property for our system as well. So what we came up with is this idea that, hey, there's this component called link that we give you, this component you don't have to build yourself. And when you use link to link pages

together we can start pre-fetching the next page before the user has even thought about going there so what you end up with is the system that merges pre-rendering with pre-fetching so you kind of have your cake and you do too so the system feels super snappy you get data in or you get a shape or you get content in the first response and you still retain all this goodness of the web you retain hyperlinks uh you retain bookmarking you retain back and forth navigation and yet things can be infinitely complex once the pages get hydrated. So that's what I'm saying. You can build anything you want with React. You can build a chess game. You can build a blog. You can really build anything. It's quite the interesting technology to learn. That's awesome. So the

idea is if you have your terms of service behind some settings page, then if someone hasn't gone to the settings page yet, you don't really need to even bother loading the terms of service. When they go to the settings page, as soon as they get there, before they even click terms of service, then you can say, okay, let's load it so that at least if they are going to click that, it happens instantly. Yeah. And you know, what's fascinating about this is that we use information about the viewport to prioritize what to prefetch. And we also make sure that we're not getting in the way of other important information being loaded. So we use an intelligent prioritization system.

First of all, we prioritize prefetching what's visible on the screen. But secondly, we don't prioritize it so much that it's getting in the way of loading the chessboard, right? Or whatever it is that that particular page that you were developing was concerned with rendering. So we actually have spent lots and lots of engineering in this intelligent prefetching system. we're really happy with where it is today, but there is so much more still that we can do. So something we're researching currently is we can know based on the trajectory of your input device, right? Whether you're likely to, where you're likely to go next, right? And we know this from several sources. One is the motion of the pointer itself,

right? Like the pointer is pointing to a certain link. We can start prefetching that. The other one is on mobile determining the motion, right? Like the user might be blindly scrolling or they're stopping and looking at something. And in a lot of cases, what we do is we start prefetching when you first begin the tap action rather than when the tap gets released and so on. And then we can use information about your traffic as well. So there is a integration for Next.js called Guess.js that uses information from Google Analytics to know what to prefetch and to prioritize prefetching.

So it's quite fascinating, right? Because the only thing that you think about as a developer and you get all these benefits, it's just linking between pages. I shall say also that that's the other kind of important primitive that Next.js added to the React universe that it was, in my opinion, sorely needed, which is the page. So in the Next.js universe, you don't have just components.

You define what pages you're building first. And all those pages themselves are just React components as well. The top level thing is a component and then there's deeper components. But the fact that there is a page as a concept allows you to like i said retain all these very cool uh properties of the web but also powers this intelligent prefetching system yeah that's awesome yeah that makes a

ton of sense um so you were talking about um things that you know you're kind of looking forward to and things you're working on. So what is it kind of like to work at Vercel? How many folks work there? And what's that environment like? Yeah, so funny enough, before this coronavirus pandemic happened, we had just organized an online event for basically front-end developers. We called it Back-end Lestant because the mission of our company is to empower front-end developers and allow them to bring their websites online and web applications online with ease.

And for companies to also have the opportunity to reinvent their front-ends because we know, we noticed a lot of companies kind of neglected investing in the front end and you know i always say you know front end is where your visitors are front end where your customers are so we started vercel as a way of you know tailoring and targeting and helping this front end experience problem. But before, even before the pandemic happened, we're already organizing online events like back in the stuff. Because what we've noticed is, you know, our product was already starting to enable people to work in ways that were very distributed, right? Like you didn't have to be in an office to build components, to deploy them and get a URL and share it with your teammates. So our product was already kind of like headed into this world of like, hey, like if you have a great structure, if you have a great way of dividing up the work in the world, it kind of makes sense that you'd be able to do that work from wherever you are.

Right. so as a company from the get-go we're very um remote friendly so even though the headquarters are in san francisco we always figured hey you know the purpose of this technology is to allow people to kind of be freed from the constraints of the physical world to begin with after all we are publishing to online media, right? So Verso was always a company that had this as a kind of guiding principle. That makes sense. It's one of the great ironies of Silicon Valley that the people who invented, or at least I guess the country that invented video conferencing. I think it was

invented in New York, but it's sort of like, you know, then it's like everyone's sitting in a giant bullpen, right? It's like, couldn't even dog food that invention. Yeah, it's fascinating. I think it's part of a transition. I think it's part of an acceleration. A lot of people, you know, say, well, you know, we're about to enter a recession and things are going to get really bad. But I honestly see it as the opposite. I see it as we're about to enter the dawn of a lot of things that we're doing in ways that were quite paradoxical, I think. When it comes to work, I think it was a paradox. We were building tools for remote work, but the builders of the tools were not embracing remote work.

And I think that goes also for publishing. This is a problem that we're really attacking face-on with Vercel. We were publishing our front-ends to one location in the world. Like you mentioned AWS earlier, like the way that people use AWS by default, and this is the default region, right? They create a server in Virginia. It's the US East location, but we're publishing globally. You're selling globally. You're speaking to global audiences. Why are you putting everything in one server, right? So Vercel gives developers this workflow where they publish your edge network, which is located in dozens of cities around the world.

So when you publish your pages, when you publish your content, there's no way to deploy just to Virginia. This is a new normal, is deploy your front end to an edge network. So in some ways, you know, like you could argue, oh, we're, you know, a little bit ahead of the curve and whatever. But I think what's going to happen is that with this new world, people are going to realize these things that were already problems that were pre-existing to our systems. And now those solutions will see an acceleration in adoption because we need them. And we needed them before this even happened.

Yeah, when I look at, you know, when I hear reasons as to why things can't be decentralized, it always comes down to things like we'll have to document our code more. Like we'll have to have we'll have to have contracts between the teams, you know, like software contracts between the teams. And I'm just sitting there like, okay, that sounds amazing. You know, and it's like, no, no, no, we'll need an extra, you know, let's say 10% more people, you know, to do all of these things, to have all this awesome documentation. It's like, yeah, I mean, that sounds like an amazing trade-off. And in exchange, those people can be anywhere they want. I mean, it sounds like favorite essays online that I come back to a lot is this interview to a researcher out of MIT who works on what he calls digital reality

and in the field of his research is to try to understand what exactly is the distinction between an atom and a bit and what are the technologies that facilitate the conversion from the bit to the atom right and the most obvious one is 3d printer right like you have content that is purely software defined and then you can convert it into reality. And one of the things that he talks about, and he talks about Lego pieces as well, is that the geometry of the pieces is what enables the system to get complex. And he talks about how, you know, you've probably seen this with like, you know, how we can birth human beings that end up being larger than the human being that they were born from, right? Like, there's this incredible complexity that yields from very basic pieces,

as long as these pieces can fit with one another, we can build really complex, interesting things. And John Conway died recently. And his idea of Game of Life is very similar from how very simple rules very interesting complexity can emerge and i think the way that i see this play out in the software engineering world is that we sometimes have ignored the geometry of the pieces and we have built things that are just so incompatible with one another and react made this gigantic contribution saying, hey, the building block is the component. And now you can fit the pieces together really well. And now that means that we can build complexity in ways that are actually good, right? Like we don't want to build complexity to make

the world worse. But now you can manage that complexity. And you started from one little component, and you can grow out of that into a very interesting machine and go into your comment about comments in software engineering you know like i think our job really is to always be defying these nice contracts so that you know we make certain classes of problems completely irrelevant or invalid uh version control has helped us go in that direction, but I think we're going to see that become even more and more rigorous over time. Today, when you push a commit to Git, in a lot of cases, it contains no validation whatsoever. This system treats everything as just dumb text. But as we evolve our systems, we start getting

better understanding of what should be accepted or should be rejected altogether. And honestly, I hope that, you know, us defining collectively these better interfaces will just, I think it'll make work a lot more pleasant so that we can focus on the creative sides of software engineering rather than like the bugs and all that boring stuff. Yeah. I mean, a good example of this is code style, right? I mean, people would just fight and argue about code style. And then finally, we got editor config and we got the prettier, that's right. I forgot the C++. Oh, yeah, Clang format.

But basically, we got these machines and these rules that do it for us. And now, as you said, we can focus on, you know, we don't have to spend time arguing about tabs and spaces. We can focus on more important things. You mentioned something really interesting. You mentioned hot module replacement earlier. And I really think that React has also helped popularize, you know, hot module replacement. So for those that are not familiar, as you're editing your code, and you save it, you automatically see the change in real time with no interaction with no refresh button on the screen. And this

has been a really interesting thing about React is that because it defined this incredible geometry lots of other trends emerged together with it so hud module replacement you could argue could have always been possible but why did it become a thing that react became known for well because the encapsulation of components and state and like the ability to cheaply repaint, like all that led to, okay, this new amazing capability is now we take it for granted because for example, Next.js automatically configures and gives you hot module replacement. But again, like you go back, you know, 30 years, 10 years, five years, or even you go and look at how you mentioned desktop applications, how people develop desktop applications. And sometimes wait you know five minutes from a change to compiling it

to running it to seeing you know what the result of their change is so just imagine what that has done for creativity and just productivity and just ease of use and onboarding developers. I'm noticing this fascinating thing on Twitter. It's called hashtag 100 days of code, where people are every day, you know, doing one challenge a day. And I noticed how fast newcomers to the industry are picking up React. And it's just really motivating for me to see, you know, that we can be a part of helping that movement come alive, which is,

you mentioned something interesting as well. It's like people switching professions, which I always see as an opportunity to also bring fresh new ideas to our field. I think that idea that you can go back and forth from, you know, an expertise that you already had to a new expertise or a new medium for publishing. It's absolutely fascinating. We've been, with Vercel, we've been

sponsoring researchers of coronavirus, of immunology, of virology. And we had the really great opportunity to sponsor a team, I believe it was out of Switzerland, of very renowned researchers. And something that really stood out to me was that they were all proficient in React and Next.js, even though that's not their thing. They were using the technology to create these interactive models

with drag and drop sliders. You know, I'm sure that the idea that they changed the data and then the screen reacts automatically made lots of sense to them and it was easy to grok. And then they only had one person in the team that was more of a traditionally trained software engineer, but everybody was contributing to this project. So this is kind of what we're still in the early innings of seeing this impact that React is having in the world. But I think it's going to be,

you know, cross-disciplinary. I think it's going to, you know, help novices and professionals alike. We still work with lots of customers that have, you know, spaghetti PHP and JS code, you know, all intermingled with lots of the categories of bugs that React has eliminated. But they're still code, you know, all intermingled with lots of the categories of bugs that

React has eliminated. But they're still making, you know, like lots and lots of money. And like, they have very successful businesses, but they still, you know, are looking for that opportunity to like, reinvent their front end. So it really has been a revolution kind of across all fields and all levels of expertise. Yeah, it's amazing i do think that that um that yeah we'll sort of a lot of these things will kind of democratize as as as we have been i think you know on my side i do a lot more on the machine learning and ai side and you know pie torch and tensorflow and these technologies have done the same thing where you see um there's a person who made uh people are making like art with neural networks and they're they're you know people who like

artists and and people who don't have a background in software are able to like participate it's not just kind of for wizards anymore which is i think you're going to see as you said this sort of cambrian explosion of ideas as all these people from around the world can kind of express themselves, right? Using this new tech. Yeah, absolutely. I'm really excited because it's the programming model for me that was really the game changer. I remember when I got into React, I didn't actually use React. I wrote my own React because I really wanted to understand the... Yeah, that makes sense. What's going on here? And it just blew me away that, you know, oh, like this is a new way of thinking, really. This is a new way to program, not just, you know, like a JS library.

And so much so that, you know, SwiftUI, the new library that Apple put out for native UI programming, is very much inspired by React. And we're seeing, you know, this inspiration of React just, you know, go everywhere. And that's because of the programming model, not because, you know, like Facebook developers wrote very good code, which they did,

but like it goes beyond the code. And that's really, really interesting to me. Yeah, that makes sense. So Vercel, the company, are you folks hiring? Do you have internships? Is there any statement? We are, and we're specifically also hiring for interns. We basically run permanent internship programs.

We always have our application process open to anybody that wants to get deep into this front-end world. There's two classes of problems that we invest in. One is, what is the right cloud infrastructure for a modern front-end? So what, like I mentioned, an edge network, global delivery mechanisms of infrastructure, like minimizing latency, minimizing the friction between the page and the visitor. So that's one category. The other category is we work on Next.js itself. We work on our own dashboards and ways of sharing the information about the projects that you have, the pages that you've built. And so you can basically contribute to our company in those two main areas, both infrastructure and purely front-end code.

Right now, we're attacking some really interesting issues with Next.js that have to do with scaling to very, very large projects. So projects, we're talking with millions of pages or tens of millions of pages uh or tens of millions of pages um and one thing that i love about our internship program is we've seen people that came in as interns that are now our full-time you know senior software engineers and we kind of helped them throughout that entire transition so um in addition to that we're hiring for, dev role. Basically, you can go to versatile.com slash jobs and get the full list. But yeah, we'd love to stay in touch with everybody that kind of listened to us today. Also on Twitter, my handle is RouchG. And also for anybody that's interested in Next.js and learning React or starting to build something useful with React, we recommend Next.js.org.learn, which is basically a step-by-step tutorial on building something with React from scratch.

Cool. So I think folks are interested step one i would say go to next.js.org learn so that uh um you know this is a not to go on too much of a tangent but um i saw something recently where someone applied to to a job and um i thought i felt like they were a pretty good software engineer but they they actually kind of knew nothing about the company or uh or or like any anything kind of you know like anything that they're sort of getting into and so you don't want to be that person so uh so check out i think that's a really good point not only because it just helps your chances in a very objective sense it's like i think it allows you and this is kind of like a byproduct of this new open source world is you can get to know the

people that you would be working with and the problems that they're working on prior to making any kind of commitment right yeah that's right yeah totally right um yeah you can see kind of uh um you know i think a really good side of people is when when you have sort of design arguments um that's actually a side of people where you get to see kind of uh the real metal right and and what that give and take is like and everything. And all of that is out there in the public. I have a bunch of open source repos. But people have told me feedback.

They say I'm very short when I talk online. So that is something that maybe I'll work on. Maybe I won't. I don't know. But you can see uh you know what what the folks are like which is awesome and learn more about Next.js and then yeah if you're a folk uh if you're folks out there in in in college or or uh high school um you know and you you're interested in doing an internship definitely reach out um for sure nextjs.org

slash jobs is that correct no uh next.js.org slash well. Is that correct? No, nextjs.org slash. Well, you'll find your way if you just go to nextjs.org. You can go to the Vercel website by clicking on the top. Oh, I see. Got it. Okay, cool, cool. Great. Yeah, this is really, really awesome.

You know, I knew sort of very vaguely what React.js was all about. But now, sorry, I knew vaguely about React.js, but now I kind of have a deeper understanding of what it's all about. And I actually have a project that I'm doing, that I'm live streaming on Twitch, where I'm just building basically a simple website. And I think we're going to start it with Next.js. So yeah, I actually was going to start last week and then I had some family stuff.

So I'm going to be starting it this week. And folks out there, I don't know if the episode will be out by next week, but we'll try this with Next.js. And so personally, I'm looking forward to trying this out. So thank you so much for the time. I really appreciate it. And I know the folks out there are going to love it.

Thank you. Thank you. Cool. And for everyone out there, thank you again for all of your support and all of the feedback. We've been getting a lot of emails, which is awesome. There's actually some emails from people who are kind of first, second connections to programming language inventors and all of that, which is awesome. There's actually some emails from people who are kind of first, second connections to programming language inventors and all of that, which is awesome. In general, thank you so much for the support. I hope everyone out there is being safe and you're kind of taking

this as a time to do some kind of fun side projects and have time at know at home catch you later the intro music is axo by biner pilot programming throwdown is distributed under a Creative Commons attribution share alike 2.0 license you're free to share copy distribute transmit the work to to remix, adapt the work, but you must provide attribution to Patrick and I and share alike in kind.