PostHole
Compose Login
You are browsing eu.zone1 in read-only mode. Log in to participate.
rss-bridge 2023-03-28T17:52:00+00:00

SE Radio 557: Timothy Beamish on React and Next.js

Timothy Beamish of BenchSci discusses React and Next.js, two of today's most popular front-end frameworks. Host Philip Winston speaks with Beamish about components, routing, JSX, client-side and server-side rendering, single-page applications, automatic code-splitting, image optimization, and more. Beamish also details his experience moving a real-world application to Next.js.


Timothy Beamish of BenchSci discusses React and Next.js, two of today’s most popular front-end frameworks. Host Philip Winston speaks with Beamish about components, routing, JSX, client-side and server-side rendering, single-page applications, automatic code-splitting, image optimization, and more. Beamish also details his experience moving a real-world application to Next.js.


Show Notes

  • SE Radio 382: Michael Chan on Learning ReactJS
  • BenchSci

Transcript

Transcript brought to you by IEEE Software magazine.

This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number and URL.

Philip Winston 00:00:17 Hi, this is Philip Winston for Software Engineering Radio. My guest today is Timothy Beamish. Timothy has been a software developer for more than 20 years with a focus on front-end architecture. He’s currently a staff engineer at BenchSci, overseeing a suite of front-end applications, written in React and Next.js. Prior to BenchSci, he was a senior staff engineer and web team lead at Plenty of Phish, one of the largest online dating sites. Welcome Timothy. Is there anything I left out of your bio?

Timothy Beamish 00:00:45 No, I think that’s good. Yeah, front end mostly focused, dipping into the back end a little bit, and yeah, built tons of tons of websites of over the last few years.

Philip Winston 00:00:53 Great. So let me just set the stage for the show a little bit. So, React is a very popular open source front end library, I’ll say, released by Facebook in 2013. And Next.js is a framework for React released by Vercel in 2016. So, we’re going to divide the show into three parts. First, we’ll talk a little bit about React itself, with an eye towards the following discussions. Then we’ll talk about Next.js and go through a number of features and discuss the advantages and some of the disadvantages of Next.js. And finally, we’ll talk about a recent migration to Next.js that Timothy oversaw at his current company. This part of the show is based on a blog post of Timothy’s called Moving House to Next.js that we’ll put a link into the show notes. I also wanted to mention that Timothy and I both currently work at the same company, although kind of at opposite ends of the company, so we don’t really encounter each other day to day. Before we dive into React, I want to highlight a previous Software Engineering episode that discussed React in pretty good detail: Episode 382, Michael Chan on Learning ReactJS. So, to start off, is React a framework or a set of components or a library? How would you characterize React?

Timothy Beamish 00:02:12 React is a framework for building front-end applications, and it’s important to know that it only does one thing and it does that one thing well. It doesn’t do everything. It doesn’t solve all the problems of the front end. Its job is to take data and represent that as a state via UI. So, it just places a bunch of UI on the screen, which is telling you what your data situation is currently in the front end. As soon as that data changes, the front-end changes, the UI changes. And that’s pretty much all it does. There’s lots of other problems you have to solve on the front end, and React doesn’t solve any of those for you, which is where kind of Next.js comes in to help out a little bit. It helps solve some of the other problems.

Philip Winston 00:02:52 I saw the name React and looked it up, and it said it’s kind of based on reactive programming, which is kind of what you were saying: the ability to handle data updates to otherwise static content. Is that a fair characterization?

Timothy Beamish 00:03:09 Yeah, so in the days before React — in fact in the days of static webpages when the web was pretty boring — you’d go to a webpage, it would render; if you wanted to go get some new information, you’d have to render a whole new page again. Then Ajax came along and that blew up the internet, and it meant that webpages didn’t need to load in entirety to change themselves. They could dynamically shift over time without loading the whole page. Little pieces could reach out and ask questions of servers, get answers back, and re-render just portions of the internet. And this opened up webpages to be dynamic applications, but it also creates a lot of complexity because now you’ve got to manage which parts of the page are updated, what the state of different parts of the page, different parts of the page have to be in different types of state.

Timothy Beamish 00:03:56 You have to have some sort of global management system to handle all that. And we had tools like jQuery to help us kind of paint things on the page, but it didn’t, it didn’t help us organize the data. And then things like Angular and React came along as solutions to this problem. And then for a little while we had the massive front end framework wars, and these days React kind of stood out as the leading way to do this. But basically, its job is to manage the data that’s coming into the application — the global state of the application — and allow you to represent that using UI. So, it’ll figure out which parts of the page is need updating, which parts don’t, and you don’t have to worry about making sure that everything’s in sync. You just make sure that your data’s correct and that you have a good mapping to the UI.

Philip Winston 00:04:42 One React concept is components. Are these visual components you can point to on the screen? Are they more generic than that? What is a React component?

Timothy Beamish 00:04:52 By and large, yeah, they would be visual components, although not always. You can have components that are hidden in the background that don’t actually render anything, but generally speaking, a component is a little piece of UI that gets some data sent to it or it holds onto some internal data. When it gets data sent to it, that’s called a prop or a property. And when it holds onto internal data, that’s called its own internal state. And it’ll render something to represent the props and state that it has. So maybe if the component is meant to represent a button and the button needs to be red in some cases and green in other cases based on some information coming into it, the component’s job is to say, hey, I take a property that tells me whether I’m on or off, and if I’m on, I’m red and if I’m off, I’m green.

Timothy Beamish 00:05:36 And the thing that talks to me only has to know whether I’m on or off. It doesn’t enough to know anything about red or green. That’s my job to handle that on means red and off means green. And I will take care of that. You just make sure that the data flowing into me tells me whether or not I should be on or off. And that’s kind of what a component does. Now you can have — that’s probably like the simplest form of component. There’s a few different types of components and the more, I guess, trickier ones would be things that have to fetch asynchronous data to update the application. So, some components, their job is to say, hey, I need to get some data to render myself property. We don’t have it. I need to go ask a server for some data. So, it has to do,= some sort of asynchronous operation. Then it becomes more complicated. It has to handle things like, hey I’m asking for data now, but I still need to render something so I need to render the fact that I’m asking for data. So, I’ll typically put like a loading spinner on the page.

[...]


Original source

Reply