Translator’s note: This translation is based on the one-and-a-half hour live broadcast of “React.js core developers”. It includes all the questions and answers in the live broadcast, and retains the central meaning of Dan’s answers as much as possible. Some expressions are used in order to make the sentences easy and easy to understand. The article is more than 1.5w words, and contains a large number of professional concepts and inspiring ideas. It takes about 30 minutes to read through. Suggest collect first come down, read slowly. Finally I wish you all a harvest!
Hit the blackboard and underline the key points
For you to highlight the intimate.
- About State Management
💡 The really important issue is not which state management library to choose, but understanding what type of state you are dealing with.
💡 React may not be like a library, but you can think of it as a UI programming language, where components correspond to functions in the programming language and Hooks correspond to variables.
- On the Difficulty of getting started
💡 There are UI frameworks where you start by modifying HTML templates and gradually learn to program. With React, you start with a programming language. If you don’t know how to program, the React learning curve is really steep.
A framework like 💡 Next. Js is a good place to start.
- About Programming Paradigms
💡 It is important to understand the paradigm “UI is a calculation”.
💡 For React, I prefer the concept of “functional-Lite/functional-light programming”.
- About the features
💡 React sees problems that are related to each other in a more theoretical and systematic way, which makes React intrinsically superior to third-party libraries and other solutions.
💡 The original planned Concurrent Mode no longer exists, but the little ideas behind it give React a lot of features, essentially giving React the ability to render “asynchronously” and a lot of things in the world are inherently asynchronous.
💡 In most scenarios, we expect users to use the Server Component functionality via frameworks such as Next.
💡 For the most part you should use frameworks. The framework is like the infrastructure that connects and organizes the various parts of the project for you.
- About the Vue
💡 Vue is constantly exploring what we can do with mutability, while React is constantly exploring what immutability can do.
💡 We are very confident about where we are going because we have nearly 50 years of functional programming research behind us.
💡 Vue will prioritise some of the more desirable features. React is probably a little bit more cautious, we want to make sure that every solution that React offers is completely reliable and reliable, and you may have to use some third party libraries until we release certain features.
💡 Vue and React, just like Android and iOS.
- About competitiveness
💡 I’m not a big fan of the term Virtual DOM. We try not to use this word because everyone has a different understanding of it. The Virtual DOM has nothing to do with performance; it exists only to make certain features feasible.
💡 Some benchmarks represent only 2% of the performance difference in the actual scenario and are not worth the time and effort to support larger scale user code rather than trying to win the benchmark race.
💡 We try to look at the whole picture, to deal with problems that are difficult to solve from a single point in a more generic way, and make them easier to implement. I guess that’s where React competitiveness comes from.
💡 Even if React doesn’t have new features for the next five years, the way React describes the UI won’t be obsolete.
- On the framework
💡 SSR, CSR, NSR, ESR, these should all be done by the framework, I still recommend you to use a framework, such as Next. Js is a good choice, the framework will help you with these parts, so you only need to use the same template to write the code.
💡 React itself is not a framework, just a library, because it doesn’t constrain the way you work or the structure of your project. React is just a way of building uIs, and frameworks can be built on top of that.
- About the maintenance
💡 Other frameworks often don’t do this, they need to release a version and then maybe a year later someone finds a bug and reports it.
💡 In a company the size of Facebook, even a 1% deterioration can affect millions of people. So it’s easier to spot if there’s a big problem.
- About growing up
💡 Don’t say “the front end is changing all the time” because you don’t know the full picture. I don’t think that’s the case.
💡 There is no need to read the React source code.
Say Hi
Host: Hi Dan, say hello to everyone watching!
Dan: Hi, everyone!
Host: Most people here already know you, can you introduce yourself again?
Dan: Thanks for inviting me. I’m Dan. I’m one of the React core maintainers and I’ve been on the React Team for the past 5 years. That’s pretty much how I introduce myself.
I started programming when I was 12
Host: I see from your blog that you’ve been programming since you were 12 years old, which is pretty impressive, how did you get interested in programming?
Dan: It was a coincidence. I didn’t learn programming on my own. When I was doing my homework at school, I liked to do some presentations. I don’t know if you still use PowerPoint, but I had PowerPoint 2003, and PowerPoint had a programming language built into it. If you right-click and open the menu, you can do some macro recording. I didn’t know what they were at first, but I was so interested in them that I bought some books and started to learn programming.
React state management tool
Host: This is your first meeting with a Chinese engineer. We have prepared a lot of questions. Are you ready to answer the questions from enthusiastic netizens?
Dan: I’m ready.
Host: What do you think of the React state management tool?
Dan: I think different people might use different libraries, and if I had to make a recommendation, I wouldn’t recommend any particular library. The really important issue is not which state management repository to choose, but understanding the type of “state” and understanding what “state” is. Since “states” is a very general and large concept, I don’t think we should talk about which libraries are better on the surface, but rather what kind of states you’re dealing with, what’s the purpose of using these libraries, and what’s the difference between different options. For example, there are UI states that are specific to the UI components that are displayed. For the text input box, what is the text content, whether the text is selected, whether it is in the focus/hover state, or record the current page is selected Tab, these are the state of the UI. The other state is more like cache, which caches the data returned from the server, and it might be more like some kind of draft. So we need to choose a state management tool based on the actual requirements. For UI state, I personally don’t recommend using any libraries, just use React state. You can use React State, or React Context, to pass State through the component tree. For data caching scenarios, I do not recommend a solution related to “state management” (here Dan uses quotation marks ✌️✌️). I recommend that you use libraries that are specifically designed to handle data caching, such as React Query, Apollo, and React Relay.
Host: Now a lot of people want to use React Hooks and Context insteadReduxYou mentioned something similar in your answer just now. Could you share some of the design ideas behind React Hooks?
Dan: Right now, React Hooks can only be used with function components, and we have no plans to make them compatible with class components, because these are two different paradigms and it doesn’t make sense to mix them up.
I think this is more of a question about Hooks design, and I’m not sure how to answer it. In general, Hooks are somewhat reflective of how we think of React Components. Conceptually, a Component is a function that receives props and returns the UI. Hooks are an enhancement to this function. They now have a place in the component tree for states. You can use Hooks to record states, to record behavior, etc. That’s the general idea. Along the way, React may not be like a library, but you can think of it as a UI programming language. In programming languages, we have functions and variables. If you think of React as a “pseudo-” programming language, components would correspond to functions in the programming language, and Hooks would correspond to variables. This is my own idea, I wonder if other students can get it.
React quickly
Host: Many developers think it is very difficult to get started with React, so do you recommend a way to get started quickly?
Dan: I think it depends on why people find it difficult to get started. The problems may vary from person to person. For one thing, React requires you to have a JavaScript programming background. It can be difficult if you’re new to programming because it’s not built using HTML and templates. With some libraries and frameworks, you start with a template, add a few criteria or loops to the template, and you learn how to program as you tinker with it. But with React, you start with the programming language, and you start with code. If you don’t know how to program, the React learning curve is steep. Some people find it difficult to get started with React, but after a while they learn JavaScript, they can come back and watch React. This is the threshold created by JavaScript. On the other hand, I think it’s important to have a good development environment. Tools such as nex.js or create-React-app will help you get the configuration you need for your project ready. Sometimes people find it hard to get started simply because they don’t know how to create a single page app (SPA). These aren’t React’s problems, but people tend to blame them on React. If you use Next. Js as a starting point for your project, I think that would be a good place to start.
The React from the pit
Lehrer: Next question. For people who have started using React, could you give us some advice to help them avoid some pitfalls?
Dan: It’s important to note that if you use React Hooks, you usually need to use matching Lint rules. We have two recommended rules for Hooks that can be integrated into your project as plug-ins. In addition, I think it’s important to understand two concepts in React. One is immutability, you need to know how to update the state without changing it. You can do this with the extension operator (…) Or some other syntax implementation. A great library called Immer is recommended, which allows you to use Vue/Svelte style changes in your programming while still maintaining invariance. Give it a try if you’re upset about this. The other thing is to understand that React’s Rendering process is supposed to be pure. When a component is Rendering, it’s calculating what the next UI should look like, and you shouldn’t use the Rendering process to create and manipulate the Rendering process. I think it’s very important to understand the paradigm that UI is a calculation.
Functional programming
Host: React is getting closer to functional programming, but some people say that JavaScript is not a functional programming language. What do you think about this contradiction?
Dan: Maybe React is a little more functional than other UI libraries, but I don’t think React is a framework for functional programming. There’s a consensus here that everyone who likes functional programming doesn’t think React is functional because it’s not “pure” or whatever. For React, I prefer the concept of “functional-Lite/functional-light programming”. An important idea that React borrows from functional programming is to break complex things down into functions that can be combined, such as using immutability whenever possible. But React code doesn’t look like traditional functional programming code because React tends to use a more direct coding style. For example, if you need a loop, you can write the loop directly in your code, without having to write higher-order functions, and then combine them in complicated ways. Writing React is just like writing JavaScript, so the code doesn’t look “functional” like Ramda or Lodash FP. So React is kind of in the middle. I don’t think it’s a contradiction that it combines the ideas and concepts of functional programming with the ability to code in the mainstream of JavaScript most of the time.
Too fast on the front end?
Host: The front end is a rapidly evolving field, how do you keep improving yourself and keeping up with the pace of technology?
Dan: Interesting question. I don’t think the front end is evolving that fast. I haven’t seen much new stuff in these years, maybe I didn’t look hard enough. But most of the results I’ve seen are iterations and refinements of existing features. Some things are released in new versions every year or two, but most of the time whether it’s a new release or a new library, the same ideas are used. So, if you are familiar enough with and understand enough of the things that already exist, you may not find new things new, because they are to some extent homogeneous things. So I think the best way to get ready for something new is to get familiar with what you already have. When you get familiar enough, you only see similarities.
Host: What’s the future of React?
Dan: It’s a big issue, like a roadmap for the next 10 years, and a lot of the features we’re working on are actually related to that.
The main problem
Host: So what are the major issues at the moment?
Dan: It’s interesting that we’re dealing with a lot of different problems, and different teams are working on them in different ways. I can give you examples of data-fetching. How to design a data acquisition scheme with good scalability, so that the number of components will not cause requests to Waterfall, thus ensuring UI consistency. You can write the logic closer to where it is called so that data and code can be loaded in parallel. Data-fetching is a very complicated problem and you have to think about how to facilitate users. Current data-fetching is very annoying. That’s a big problem to solve right now, and another big topic is all kinds of optimization, about code-splitting, Server Side Rendering, how to get the extra stuff out of the JavaScript package, How to pay less for Hydration and so on. This may sound like an entirely different area, but there are many similar points, and with these optimizations we can make React intrinsically superior to third-party libraries and other solutions. Another big topic is animation, but we haven’t started working on that yet. But in all of these directions, we’re going to try something different. Many UI frameworks or libraries tend to tackle a single point of problem independently, offering different solutions to a single problem, providing a convenient API for a better development experience, and so on. But in our view, some of the issues are interrelated. We try to connect related problems and solve them in a more theoretical and systematic way. So if I had to talk about React in the future, I would like it to be a tool to help me write components and integrate data-fetching, code segmentation, animation rendering and so on, all of which are combined seamlessly. Because React’s central idea is to put the pieces together like Lego, we hope to be able to support those features in the future.
Concurrent Mode
Host: Some people have asked about concurrent mode. React Concurrent Mode has been around since version 16, but it wasn’t until React 18 that it was finally released. What problems and challenges did the React Team face when designing this feature, and what are your plans for the future?
Dan: Ok, let me start by saying that React 18 hasn’t been released yet. We’ve only released an alpha for the library maintainers. If you go to reactjs.org/blog, you’ll see an article called The Plan for React 18. Check it out if you want to see what’s new and when it will be released. We also set up a working group and invited around 50 community developers to help us with some of the work surrounding the React 18 release, such as making sure the entire React ecosystem of libraries is compatible with the new version. All relevant information is in GitHub Discussion. Although non-members are not allowed to comment, they can read it. You can find a lot of information about distributions, including the concurrent mode information you asked for. As you say, we have stated for many years that we are going to be a true concurrent mode, but there has been a big policy change in the meantime, that it is no longer represented as a separate mode. So we might not end up adding a concurrent mode to React, but rather a mechanism for concurrent rendering. Essentially, concurrency means React has the ability to update multiple states at the same time. For example, when you are updating your status, some status updates take a long time to get the data, and rendering a complex page can be costly. If concurrent rendering is used, React will not block the browser in these scenarios. This means that you can type text while the page is updating for a long time, and the background status updates don’t block your interaction. Basically, you can think of concurrent rendering as running setState() in the background. This is something we’ve always wanted to do in React, but it’s important that it’s not a separate mode anymore. When you need to use concurrency, we provide a function called Transition. You can use Transition to wrap the setState() operation so that React will render concurrently when the API is called. So this will be a callable feature in the future, rather than a global schema for a Web application, it will only apply to your package operations. In terms of challenges, we do have a lot of challenges. Because we started from a theoretical point of view, we came up with a lot of theoretical ideas, such as we thought “concurrency is good”, “it’s not reasonable to block browsers for long periods of time”, “render should be interruptible”, etc. And then we built on those ideas, completed a prototype in 2015, and then rewrote React to actually implement those ideas, which is React 16. And then we really spent a couple of years thinking about how we could put these features into production. The new Facebook.com site uses React’s concurrency feature. Little thoughts like “render should be interruptible”, “setState() should be concurrent” and “render should be done in the background” actually have a lot of consequences, which took us a while to realize. These features resulted in better server-rendering, code-splitting and data-fetching and we will use the same idea to achieve better animation in the future. This idea plays out in a lot of places, because it essentially gives React the ability to render “asynchronously,” in a world where a lot of things are inherently asynchronous, like the features I mentioned above. It really took us a while to sort through the features and figure out how to make them work together. But we’re pretty much done with it now. These features will be integrated into React 18. So, again, I suggest anyone who is interested check out the React 18 release plan on the React blog and click on the related discussion board for details.
Experience React 18 Alpha
Host: So you can use React 18 Alpha right now, right?
Dan: Yes, but there are two caveats. One is to go to the blog and read the instructions for the new version. For example, the project may need to replace the reactdom.render () method with the reactdom.createroot () method after the upgrade, and so on. Some new apis will come in. If you don’t do this, the program may report a warning. But that’s how you start using new features. Another point that users of Strict Mode should be aware of is that the new version of strict Mode is much more strict, which means that things that are already there may break. So if your application doesn’t work at all in the React version, try removing strict mode, it’s probably because of this. It’s also important to remember that React Alpha is primarily a release for library developers. Many libraries, such as Redux, have not yet been updated to support them. So if your project relies on a large number of third-party libraries, your project will most likely crash after updating React 18, but that’s the purpose of the release, giving the library authors plenty of time to upgrade. So don’t be discouraged if you find that your project doesn’t work at all in the new React version, especially if it crashes due to the introduction of third-party libraries. By the time React Stable releases, most popular libraries will have been fixed and will be compatible.
React Lane
Host: Can you tell us a little bit about how React Lane is designed?
Dan: That’s a pretty technical question. We don’t really want people to know that React Lane exists, because it’s not a public API, but something that involves an internal implementation of React. But I can tell you briefly what it is. As I said above, we’ve added concurrency to React, which means it’s possible for multiple states to be updated simultaneously at any given time. Concurrency is particularly important to our Transition feature. Let’s say you type in the input field, press enter and the page updates, this is a regular page update operation. But if you want auto-completion while you’re typing, or if you want to get a list of candidates from the network and need to connect to the back end, the old practice was to manage the asynchronous rendering process yourself using useEffect. But now that we have this built-in process in React, you can use synchronous code writing to handle asynchronous data operations. I’ve always thought of A UI as a state in time, or moment in time, so to express this, you should create a Transition for the result of the list, so that the browser request might take some time, But when the data comes back, React will be responsible for presenting the results correctly. Lanes is a mechanism inside React that marks which state updates React is currently working on. You can imagine React adding it to a bitmask every time you call setState(), like a bunch of switches or checkboxes. It’s kind of like a task list, if you’ve ever used a task list you know that tasks have high priority and low priority. Or a Label on Github, which can be used to mark a high priority, as well as a bug, feature, or discussion. Also for setState(), React also provides a set of tags that indicate whether it is a Transition, an emergency update, and so on. This tag is Lane. When React renders, it selects which state updates to execute based on the Lane. If there is an Urgent status update that requires an Urgent page re-render, then only the status update under Urgent Lane will be performed. Then, if all the urgent updates are done, I check the Transition Lane for status updates, and render it if data is returned from the network, such as loading the autocomplete candidate list. So Lane is an internal mechanism in React that uses bitmasks to associate status updates with priorities, which React then updates according to.
React Server Component
Host: The draft RFC for Server Component was released late last year. What is the main purpose of Server Component?
Dan: Yes, we released a technical preview of Server Component last December, but it’s still early days. It’s a research feature, it’s more experimental than React 18, and it won’t be included in the React 18 features, so it’ll probably be released later. But broadly speaking, it’s not the same as SSR, and that’s where people often get confused. The biggest difference is that the Server Component only runs on the Server and is not downloaded. You can think of them as some kind of API. In the past, client applications might request JSON APIS to retrieve data. Server Components are similar, but the API is replaced by a Component that runs on the Server side. The advantage of this is that you don’t need to download any code, and you can achieve performance optimization. Another advantage is that because these components run on the server side, they can communicate directly with databases, microservices, or any other resource on the server. You don’t need to expose these resources to the client, just leave them on the server.
Host: Some users have already tried using the Server Component, so when we need to use the Server Component in a project, we need to maintain three components instead of one, which adds additional complexity, doesn’t it?
Dan: Well, I personally don’t agree with that. I don’t want to define the problem as we need to maintain three components instead of one. I think it’s more accurate to say that in traditional React, we only have one type of component; In Server Component, we divide them into Server Component, Client Component, and Shared Component. It’s like you used to have only one phone, but now you have a phone, a watch, and a TV. But that doesn’t mean you have to use all three, you just have more choices. So in this case, it’s not that your components will exist in three different forms in the future, but that you can only use the components that are Client Component now. It would be nice if you could just use the Client Component, but when the Server Component feature hits the ground, you’ll have more options for doing the same thing. At that point, if you want to blog with React or want to read the file system, you don’t need a lot of complicated frameworks to do that. If you just want to do some database reading using a traditional Web programming style like PHP or Rails, the Server Component can do that for you. In most scenarios, we expect users to use The Server Component functionality through frameworks such as Next. Js. So with luck, you don’t have to think too much and you don’t have to create an API. You just add.server.js to the file name, and the file will run on the server side, and you’ll be able to use all the functionality of the Server Component.
Host: So we can use this functionality directly through some framework?
Dan: Yeah, I think that’s most of the time. Because the framework is like the infrastructure of the entire project, connecting and organizing the various parts of the project for you. You can do this manually, but it’s not as easy as using a framework. In particular, the framework can enable these functions without configuration, and if you want to do it yourself, you have to connect the pieces of the project yourself. We don’t have any suggestions on how to use the Server Component yet, but since the Server Component is already supported in Next-.js, if you want to deploy your own Server Component, you can see how they do it. Then copy what they do. Or you can just use next-js or another framework like it.
The React with Vue
Host: People often compare React to Vue. How do you personally compare the two? I would like to talk about the design, performance and purpose of use.
Dan: First of all, I haven’t used Vue personally, so I probably can’t do a very detailed comparison. Technically speaking, they may be implemented in different ways. Vue builds on mutability and allows you to modify state directly. Some of the benefits of this are that it’s easier to write, and you can write code in a mutative style, which is favored by many developers. But there are drawbacks, such as the fact that at a higher level, some features can be notoriously difficult or impossible to implement. Like the Transition feature we’re doing, or the new animation feature we want to do. The difference between the two is too big, as if separated by a deep technical gap. Vue is constantly exploring what we can do with mutability, while React is constantly exploring what immutability can do. But we are very confident about our direction, because we have nearly 50 years of research results of functional programming behind us, so we know that although we may encounter some difficulties in practice, our approach is reasonable from the perspective of theoretical analysis. Vue and React are just exploring two different directions, which is great, you just have to pick the one you like. When it comes to design, I think the biggest difference between the two is that Vue is more inclined to make some compromises and pay more attention to solving practical problems. For example, it will provide some of the coveted features, including easier animation, easier conditional rendering, component templates, and so on. But React may not be the same, and we want to make sure that every solution that React offers is completely reliable and trustworthy. So we prefer not to implement some of the features that exist just for convenience. Let’s say React wants to redo the animation feature, and we’re going to end up delivering it to users several times faster than the current solution. We’re not going to standardize some of the existing solutions, because we have our own idea of how to implement animation, and that idea will be deeply integrated into the React library, which will be different from all the frameworks we see now. So, in Vue, you can get the functionality you want faster, but in React you may not find the functionality you want, you have to rely on third-party libraries to implement it, and until we figure out how to solve the problem and how to do it right, we won’t integrate it into React. It’s a bit like the difference in design philosophy between Android and iOS. IOS often has fewer features than Android. For example, the first few versions of iOS didn’t even have a copy-and-paste feature until the notification center came along. IOS features may lag a little bit, but when it does do something, it does it very well, and I think that’s what we’re working on. I think there are pros and cons to both approaches.
The Flow and the TypeScript
Host: What do you think about the fact that Flow is no longer used in Vue 3 and React is still used?
Dan: I don’t think that’s important. Depending on how the library itself is written, we still need to do some static type checking for now. This has nothing to do with what type of React users are using, but affects the development of the React library itself. We use Flow only because we started with it, and it meets our needs later. We can also use Typescript, but I don’t think that’s critical. This doesn’t affect React users at all, because there’s also a difference between the types we have inside and the types we expose. So it’s not important. We don’t care. We could certainly switch to Typescript, but the cost of the migration just isn’t worth it.
React competitiveness
Host: There are some new front-end frameworks that have come out recently, such as Svelte and Solid-JS, that are no longer using virtual-DOM and claim to be better than React in terms of performance and bundle size. What do you think about that?
Dan: Again, I haven’t experienced any of these frameworks in depth, so IT’s hard for me to judge. But again, it looks like there’s always something new, but it’s not. React is immutable, Vue and Svelte are mutable, and Svelte and Vue are mutable. There may be some differences in implementation between Svelte and Vue. Solid-js should also be a branch of this path. Speaking of virtual-dom, I don’t really like the term. We try not to use this word because everyone has a different understanding of it. But I don’t think it’s a performance thing. Again, I don’t want to use the term virtual-dom because it’s a very confusing concept. When we use the term “virtual-dom,” we’re really talking about an in-memory representation of the UI. This should be something you expect, as it gives developers more options. For example, the Server Component runs on the Server side, but it needs to define a data format to pass the Server output and then receive it on the client side. If you’re using the Server Component for a page transition effect, you’ll want to incorporate it into your existing UI. This is unlike traditional client-side rendering like IN PHP or Rails, where the old page disappears and the new page gradually loads without any state remaining. If you have a search box, and you type something in, and you click search to go to a new page, the search box will clear. Nothing similar happens with Server Component. We send the Component tree back to the client. We can diff it with the existing UI on the client and render the parts that differ, so that the state of the search box can be preserved. The component that needs to be replaced is replaced, and this is possible because the UI has an in-memory representation of an intermediate state, which is what people call virtual-DOM. This is an example of how virtual-DOM works. Another example is what I would do if we were now to integrate a full animation system into React. Let’s say we’re doing a gesture drag animation, we don’t want to render every frame, we want to compute only a few versions of the UI. Assuming that the left-most is the 0% version and the right-most is the 100% version, we calculate several keyframes like this, and as we drag, we can interpolate to figure out what the current UI looks like. But then again, how do you generate those keyframes? You need an in-memory representation of the UI so that you can interpolate between the two. This example also illustrates the significance of virtual-DOM, and some features cannot be implemented without it. So virtual-DOM has nothing to do with performance, it just exists to make certain features available, and we think that the in-memory representation of this UI is important. Although we may be about 10 percent slower than others in some comprehensive tests, you should know that this is not a problem. At least in our tests, when analyzing some of Facebook’s more complex page renderings. What we’ve seen with our own eyes is that React only takes 10% of the time, and the other 90% of the time overhead is due to the application code. The framework can be optimized for only 2% speed. So when you look at those tests, you might have 1,000 lines of test code with only one Component. You might only be looking at that 2% difference, but it doesn’t reflect the actual performance of the app. So what really affects performance is how the overall app works and how we can make user code work better. This is what Concurrent Rendering, Server Component, and all the new features are for. Instead of trying to win these benchmark races, some of the benchmarks have small pieces of less than 10 lines that aren’t worth the time and effort.
Host: There are a lot of new libraries coming out recently and people want to know how React can keep up with the trend and stay competitive.
Dan: Yeah, I think I’ve answered that one in a way. We are working on a more general way to deal with problems that are difficult to solve from single points, such as data-fetching, code segmentation, animation and other features in the future. React will make it much easier to last minute fetching. I guess that’s where React competitiveness comes from. Personally, though, I don’t think React needs any features to “stay” competitive. So for example, when I’m doing some prototypes with React, and I’m going to draw some UI, React is going to be very natural, very handy. Even if React doesn’t have a new feature in the next five years, I would find it natural to use nested functions to express the UI. I think it makes perfect sense, and I like React the way it is, so I don’t think React needs to be more “competitive” (Dan marks it with two hands) for people to use it. But again, there are a lot of features that we’re working on that can make complex development easier, and I’m excited about them.
SSR, CSR, NSR, ESR
The host: Vue and React are both addressing web Rendering issues, but currently there are many ways to render web pages, such as SSR(Server Side Rendering), CSR(Client Side Rendering), NSR(Native Side Rendering), ESR(Edge Side Rendering) : how do you describe the development of the next five years?
Dan: The problem is that there are many different ways to run your code. You can make it run on the client side, on the server side, or anywhere else. The question is how you organize them. But I think most of the work here will be done by frameworks, so again, I recommend using frameworks. Something like Next. Js is a good choice to give you a general idea of how this is implemented. Nex.js can simplify this part by wrapping existing React concepts. For example, if you want to use the Server Component, nex.js has its own API, getServerSideProps(), or something similar. You don’t need to use The React native way to organize your projects. Next. Js will organize your projects using its own API, allowing Server Component and the like to work. So I think the future… Well, it occurs to me that if you’re interested in the Server Component, you might want to take a look at the recently released Framework from Shopify, Hydrogen. They recently released a Demo that, if you search for “Shopify Hydrogen Demo” or similar keywords, shows how they use the Server Component, as well as a preview of the future scenario. If you only have one render tree, say you’re writing a page or a blog, you just read some Markdown files in the file system on the server side, then render them to the corresponding components, and then pass the rendered components to the client side, you only need to worry about the components. Where you execute the code logic is entirely up to you. Some pages may be executed at build time, and some pages can be run on the server side if you wish. Only the code relevant to the actual interaction will be delivered to the client and run on the client side. Ideally, this whole process is still a single render tree, and you don’t have to pay attention to this part of the difference in real time. You just need to give a few hints, such as changing the file’s extension, and the code will automatically execute in the most logical place. So you don’t have to think too much about doing both server-side rendering and client-side rendering and possibly other side rendering. The framework will take care of that for you, you just need to use the same pattern to write your code, and it will work in all places.
The React and frame
Host: How do you comment on the statement that React is more like a system than a framework?
Dan: I wouldn’t say React itself is a framework. I don’t think that’s fair. First of all I think React is just a library because it doesn’t constrain the way you work, it doesn’t constrain the structure of your project, it just gives you the tools to build components. But I do think React is becoming an Architecture, but it’s different from a framework. There are many ways to update React framework, but now React has its own “views” on some technologies, such as data-fetching, routing, server rendering and how to last row and last row. React is just a way to build a UI, and different frameworks can provide higher level capabilities for users based on this.
Attract front-end developer characteristics
Host: What do you think makes a good tech company attractive to front-end developers? Can you just name two or three?
Dan: Well, let me see. I think the most important thing is to be able to learn from the people around you. For me, having an environment where I can learn new things all the time is the most important. This is not to say that you need to learn new libraries all the time. Don’t say that the front end is always changing just because you don’t know the whole picture of the front end. I don’t think that’s the case. As I said, most of the new things are inherited from the old ideas. They come out one after another, but the essence is the same. If you dig deeper, you’ll see that they’re all the same thing. But I think the ideal environment is one where you are encouraged to learn new things and there are people on the Team who have 10 or 15 years of experience and you can learn from them. The high degree of autonomy within the group is also great — you’re not assigned a specific task, you can do what you want from a to-do list, which makes work more interesting. Passive motivation is important, but it’s also very valuable if you’re able to take initiative and make your own choices. I don’t know if that answers your question.
How do I learn React code
Host: A lot of people are interested in your personal experience. How did you learn the structure and concept of React when you first joined Facebook, and then slowly started to contribute code?
Dan: React has a very complicated codebase. It has a lot of complicated contexts that make it hard to get started. Usually when new team members come in, we spend a lot of time with them going through the code. They may start by making small bug fixes or relatively isolated feature points to get used to the code. The key is to get familiar with the architecture, and once you have a good understanding of the architecture of the project, the rest of the work will fall into place. One of the things that helped me a lot was to look at people’s issues and solve them. At different points in time, I would go through all the issues that were currently “Open” to see if I could solve them, think about whether I could understand what they were saying, and if not, learn the context. I think I’ve personally seen thousands of issues, and I think it’s a great way to learn if you want to get started quickly on a project. You can click on the “Open” Issue, and there should be about 500 of them, either from the beginning or you can jump to the last page and start with the oldest one. By looking at the Issue you gradually understand what the current issues are, slowly understand the code, understand the project’s update history, etc., so that’s how you learn through the Issue. To be honest, we don’t need people to contribute that much code, it usually takes us a long time to Review code, and it’s hard for people to get the features right. So when we receive code submitted by the community, we don’t really get much out of it. But answering people’s issues for us really helps, and sometimes a user submits a Bug report when it’s actually their own code that has a problem. If someone in the community helps them find problems, find bugs, we don’t have to spend any more time on these issues, and that’s my favorite way to contribute.
Maintain the React
Host: React has a very large codebase. How does the React development team and community maintain such a complex code repository?
Dan: The repository does present some challenges, but it is challenging not because the repository is large, but for other reasons. First you need to know how to develop, how to get the code to run. For example, we rely on a lot of automated tests, thousands of tests to run, I think it’s probably more than 5,000. At the moment we probably write more test code than source code, and we rely heavily on that. One thing we learned: Be sure to write test scripts against the React public API. What we used to do was unit test individual modules, which is a very bad idea for a project like React, because once you’re rewriting React, those test cases against the old code are no longer useful. As we rewrote React, we kept realizing that “Oh, there’s another bunch of test code that doesn’t work because the old code doesn’t exist anymore.” So we changed all the test cases to test only the public API to simulate the actual user behavior. The test case can only use reactdom.render () or similar methods, and does not have access to the internal API. In the case of testing only the public API, even if we replace the original file, the test sample will still work and we can also test whether our rewrite is correct. That’s kind of what we learned from practice. Another interesting point, and perhaps a more controversial one, is that we have a lot of files that have two versions. If you look at the source code, you’ll see that we have files like.old.js or.new.js. These files are basically copy-and-pasted, and their contents are basically the same. We use them to test potentially risky updates, and in the case of Facebook, we can deploy multiple versions simultaneously. We sometimes write these experimental updates to.new files, then regression test them in Facebook’s experimental environment, and copy them to.old files if the metrics don’t deteriorate, so we have two versions of the site at any given time. During the lab test, someone else can do the other parts of the code submission. This may sound strange, but it works well in practice.
Host: So is that the secret to keeping the quality of your React code in development?
Dan: Yeah, I think the Facebook testing environment is really good. Not only do we have tests for the React warehouse itself, but we also have a lot of tests for Facebook. Sometimes we break features during React development, and we can find them during testing. During production, and even after production, we can deploy experimental tests to see which indicators are falling. For example, we did a refactoring last October, and after that we had to put our work on hold for two months because we saw a 1% drop in some metrics, I think it was the number of reviews on the site or something like that. We need to find out if it’s a performance problem or a bug or something. You know, other frameworks don’t do this, they have to release a version, and then maybe a year later someone finds a bug and reports it. But we don’t do that. We want to make sure React is of high quality, so we spent months looking into it. Divide commit commits with dichotomies, experiment with them, even with each commit. In the end, we found the bug, and the test environment we deployed did have a bug. When we repaired it, the indicators were back to normal again, and that gave us confidence. You know, in a company the size of Facebook, even a 1% deterioration in metrics can affect millions of people. So it’s easier to spot if there’s a big problem.
Read React source code?
Host: As a front-end developer using React, do we need to read the source code of the React library? Is there a good way to read the code if you need to?
Dan: I don’t think so. It would have been quite a difficult job, because we didn’t mention how React itself was structured anywhere else. If you start reading the code, you might get very confused and wonder why it’s designed this way. This is something we may need to improve on in the future, and at some point in the future, we may explain how this works. But I don’t think it’s painful if you just want to have fun. For example, one thing I like to do myself is to use the debugger’s step-in feature to run the code line by line and see which functions the code runs to and which different files it runs to. Another thing you can do is use Chrome Performance Tools, you can open Chrome’s Performance Tab, hit Record, and then do something in your app, and then click Stop, and you’ll see a flame diagram or a flame table. The result of this analysis is very useful, it’s like a kind of stack, you can see the order in which functions are called, you can see what’s happening in the code. It is often used to test performance. You can see which parts of your code are running slowly, but you can also use it to get an overview of the current functions, since it shows the names of the functions. You can see what different things happen when you change your state. You might find, “Oh, this function gets called everywhere, what does it do?” . And then you can click in and see what’s going on. I think it’s also a good way to learn what parts of React you spend your time on, what functions are at the heart of it, and so on.
Be enthusiastic about React
Host: How do you stay enthusiastic about React?
Dan: I just love it. I don’t know why, but if you think about it, it’s because React really fits my view of UI code. I’ve been using React since before Facebook, when I was in a small startup. We were working on a very complex application and trying to move it from Backbone to React. We moved not because React was the big trend at the time, but because it was really hard to build a complex UI by Backbone, compared to how easy it was to do it with React. The idea is to write a function of state that says what should be on the screen at the moment. This is a question I often ask myself, what my components should look like and what should be on the screen. This kind of thinking and my programming thinking is a natural fit. However, there are some things that are not easy to extract from this paradigm, such as data-fetching. You really want to think about what’s on the screen, but when it comes to data-fethcing, you have to think about how to communicate with the server, how to wait for the server to return the result, and maybe set some state while waiting so that the user can ignore the result of the last request when they make the request again. I only wanted to think about what should be on the page, but these things just complicate things. This is why we want to provide users with data-fetching capabilities such as Suspense to help you reduce the complexity of thinking about problems. I just have to think about what I want to see, where I want to get it from, and I don’t have to think about time even if it’s an external URL. I just want to express what’s on the screen right now, and then let React decide how to show it. What I am very excited about is that React has been able to implement UI combination and nesting well, but there are also data-fetching, animation, code segmentation and data-asynchronous which are difficult to achieve at present. I hope that these functions can be made easier to use. My hope is that five years from now, we’ll be able to build complex apps in a much simpler way, and that simplicity comes from the fact that React helps users deal with that complexity. That’s what I think.
How to be as good as you
Host: If I want to be as good as you, is there any good front-end learning materials I can recommend?
Dan: I’m not sure if I’m good or not. I don’t keep up with The Times in many ways. For example, if you ask me to make a nice app, it might be hard to do. Since my knowledge of CSS is still in 2010 and I don’t know much about CSS Grid and Flexbox, I don’t know if this is what you want to hear. But if you need me to recommend learning resources, I think it’s helpful to pick a few sample UIs and implement them from scratch. Do not use React or any other libraries in this process. For example, try to implement an input field with auto completion, or a TAB in a dialog box, and experience the complexity of doing this. Another thing THAT I really like is making little games, which also helps, like tic-tac-toe, or snake. Making games forces you to think, to think about how programs are designed, to think about how problems are solved, in a way that you don’t get from writing forms and interfaces. In conclusion, I recommend you make something small, but deep, and get the most out of it.
How do you spend your leisure time
Host: How do you spend your leisure time after work?
Dan: I don’t really do much good outside of work. I used to love Fortnite. I didn’t play it very well, but IT lasted a long time. I’m a terrible builder. If someone beats me, I build a wall, but usually I get scared and run away. But I haven’t played in a while. Now it’s more like listening to music, taking walks, doing side projects, that sort of thing.
justjavascript.com
Host: You wrote a “Just Javascript” series, which I personally enjoyed very much, and I can’t wait for the next installment to see what happens with the new articles.
Dan: Ok, for those of you who don’t know, this is actually a personal side project of mine called Justjavascript.com. It’s like a JavaScript course, and it’s free right now, but it’s not going to be free in a few weeks. This class is special because it doesn’t teach JavaScript in the traditional way as other classes do. It teaches you how to understand the code. There are lots of visualizations like animations and diagrams. It will also teach you to implement something from zero. I want it to show people how to read code properly, how to understand how code works properly. Of course we’re working on some new content. Right now we’re packaging the whole course and we’re going to upload it to the website, and when it’s done it’s going to be a paid course, and you can buy it and you can see it, and all the lessons, drawings and test questions are going to be on the website. We don’t know if anyone will buy it yet, but if it makes money, we may update more content. The project has been free for about a year and a half, and we want to see if it’s a viable commercial product before we decide how to run it. The project will officially launch in a few weeks, so if you want to support it, you can follow it.
What to say to Chinese developers
Host: Is there anything you want to say to Chinese developers?
Dan: I don’t know what to say. I’m not sure how many people use React in China, I just know that Vue is very popular in China. But I think it’s good to have more choices, and I’m very grateful to the React docs translators, as well as the many Chinese developers of the React library. I don’t know if React will be popular in China, it may not affect us in a foreign country. But if you’re really interested in React, you have a chance to change the environment around it and make it popular. If React catches on, it might be easier to get a job in the future (laughs). We are happy to see people translating blog posts, spreading knowledge, and hosting conferences, and we sincerely thank everyone for their efforts.
Host: Do you want to be more active in the React community in China in the future? We’d love to talk to you more.
Dan: Sure, I’d love to, but I don’t know how. It just so happens that you invited me, I think this event is very cool, and then we can communicate more often.
Host: Ok, I’m done with all the questions, and thank you very much Dan for this very long online conversation.
Dan: Thanks for having me.
Host: Thanks, see you next time!
Dan: Bye!
The appendix
| The British | In the |
|---|---|
| State Management | State management |
| Single Page Application | Single page application |
| Immutability | invariance |
| Spread Operator | Extension operator |
| Funtional Programming | Functional programming |
| Funtional-lite programming | Light functional programming |
| Data-fetching | Data acquisition |
| server-rendering | Server-side rendering |
| Flame gragh | Flame figure |
| Tic-tac-toe | Tic-tac-toe chess |
| Snake game | snake |
| Fortnite | Fort night |
A few digressions
Thanks to my colleagues for translating and proofreading the entire interview.
His nuggets 👉 juejin.cn/user/239218…
For more details, please follow our wechat official account 👉 ByteDance Web Infra
The original video in the efforts to add subtitles ~