Should You Use React in 2023?


Meta frameworks are increasingly popular. People dunk on React all the time. Are you insane for still using React? The talk is going to cover how real companies make this evaluation of which framework to choose. It's talking about the advantages of using React, primarily focusing on the positives but also offering constructive thoughts on why you might not want to.Should you use React in 2023?

31 min
02 Jun, 2023


Sign in or register to post your comment.

AI Generated Video Summary

React is a popular choice, but there are claims that it's dead and should be replaced. React has good out-of-the-box performance and is suitable for most applications. React Native allows code sharing between React and React Native. When considering a migration from React to Svelte, there are trade-offs to consider. React offers a standardized way of working and easy onboarding.

1. Introduction to React

Short description:

Hello everyone! In this talk, we will discuss whether you should use React. We have two speakers, True and Jordan, who share their experiences with React. React is a popular choice, but there are claims that it's dead and should be replaced. Let's explore this topic together.

So, hello everyone. So, yeah, we're here to talk about don't use apt-router. Jordan, Jordan. Wrong talk. I'm so sorry.

Okay, so our talk is, it is the year 2023. And you're wondering, should I use React? Yeah. So, hi, I'm True. I'm a software engineer at Discord, working on the Discord app. So I build features in React and React Native. And fun fact, I first used React at Uber when I was an intern there in 2016.

And I'm Jordan. I have no idea what this photo of me is. I'm a tech lead at MissinLabs. I build out front-end products and build front-end teams there. And I think the first time I used React was at Nike in 2014. Yeah.

So, yeah, React sure is popular. And for a lot of us, it's actually become the default pick. Especially given this is React Summit, I'm sure for a lot of us, it's the default pick. But maybe you've seen this framework discourse on Twitter. Maybe you've followed a clickbait YouTube video. And it's been telling you that React is dead, you shouldn't be using it. It's slow. It's ugly. It's hard to learn. And there's some beautiful new framework that will solve all of your problems. And that's what you should be using instead. You should feel bad for using React. And I'm sure a lot of us have an answer to this question.

2. Should you use React in 2023?

Short description:

Should you use React in 2023? Use React if it makes sense for you. Not everyone has the same needs, use cases, and evaluation criteria. Understand how you'll evaluate your options and separate the signal from the noise. React is still great. Familiarity is a good reason to choose React.

Should you use React in 2023? And I'm guessing that the answer is yes, given the name of this conference. But this question, we've seen it kind of increasingly, especially from people who are more new to the community. And don't really understand the nuance of that discussion that's been happening. And as React turns 10 years old, it's time to look at our 10-year-old baby and say, is it working? And really ask the fundamental question... Should you use React in 2023? And so, thankfully, we're here to give you the definitive answer that applies to everyone that's asking this. Maybe. Yeah. Maybe. I don't know. Why would I know? Depends. Yeah, it's... Yes, maybe. So, yeah. But as always, terms and conditions may apply.

So, really, what we're trying to say is use React if it makes sense for you. And this does feel like a cop-out. Does feel like we just wanted a free trip to Amsterdam. But there is really an underlying message here. Not everyone has the same needs, the same use cases, and the same evaluation criteria when they look at frameworks. And when you're making a decision like this, it's really important to understand how you're going to be evaluating your options, and separating the signal from the noise. These decisions generally aren't made in a vacuum, and there's so much nuance that goes in that can kind of be lost in this online discourse. And so, to understand what we mean by this, let's first understand why we think React continues to be a great choice in 2023.

Yeah, React is still great, don't worry. So the first big topic is familiarity. And so, I stream on Twitch, and I build a lot of websites. And so, I use React for a majority of them, because that's what I'm most familiar with. And it seems super obvious, but it's a good reason. It's a good reason. And so, knowing React helps me build faster, so instead of learning on stream, I can actually have code output. And so, in the context of the small projects that I build on Twitch, this could be the only reason that I choose React.

3. Benefits of React and Available Resources

Short description:

Familiarity with React can save time in hiring and onboarding, especially in larger companies. The React community offers extensive resources, including documentation, educational content, scaffolds, and meta frameworks like Next.js and Remix. These tools provide sensible defaults, pre-configured settings, and extended functionality. Additionally, there is a vast array of open-source tooling and libraries available for building with React, such as Storybook, MUI, Chakra, Radix, Headless UI, TanStack, Apollo Client, Jotai, Zestand, and FrameRemotion.

But, as an extension of this, at a bigger company, familiarity means you spend less time hiring and onboarding. So if you have engineers on your team that are already familiar with React, it makes it an easy choice to pick. And so, personally, also as a React developer, when I join new companies that have used React, it makes it a much easier, the onboarding process is a lot easier. And so at Discord, this was the case for me.

Yeah, and at Mystin, we've been building out our front-end teams, and we've indexed pretty heavily into React. We have an entirely React product suite, and our onboarding times when we hire only, or people who are familiar with React, we don't only hire React developers, but when we hire people who are familiar with React, we've found that their onboarding is dramatically reduced, in a matter of a couple of days, they're able to be making impactful contributions to our codebase, just because we have pretty vanilla React apps and they're very familiar with that.

Also, because of the massive React community, most problems in React have already been solved, and there's probably some medium tutorial on the internet explaining it. React also has very good documentation. The new docs that were recently launched, they're very good, such a good resource, and they're regularly updated. Alongside the docs, there's also so much educational content on the internet in the form of YouTube videos, blog posts, courses, etc. There's also scaffolds, free and paid, and even meta frameworks like Next.js and Remix that greatly enhance the dev experience of React. These all come with sensible defaults and pre-configured settings, so this speeds up your dev process and the setup. They also provide extended functionality beyond what React comes with out of the box. For example, Next has server-side rendering, static site generation, API routes, automatic code splitting, and there's a lot of resources around building websites with those frameworks like Next and Remix. Yeah, and the documentation in Next is also fantastic. I mean, they have very thorough examples, so long as you make sure you're on the pages and not the app side of the fence. But if you stay there, everything's good. Yeah, and so along with that huge amount of resources, there's also an insane amount of open-source tooling and libraries. You could literally name anything, and there's probably an npm package that helps you build it in React. You could also probably throw out a noun and an npm package exists, too. Yeah, almost certainly. So some very well-known examples of good resources with React are Storybook, MUI, which apparently is not MUI. I know, I learned that yesterday. I've Been saying MUI my whole life. We've been saying MUI a lot. Chakra, Radix, Headless UI, TanStack. Yeah, which is its own sub-ecosystem. They've got TanStack router, TanStack table, TanStack this, TanStack that. Everything. Apollo Client, Jotai, Zestand, FrameRemotion, etc., etc.

4. React Ecosystem Integrations

Short description:

There are numerous third-party integrations available in the React ecosystem, including GraphQL client libraries like Relay. Many analytics providers also offer React bindings and integrations, and there is a wide range of off-the-shelf UI components available. Companies like Qlrk provide Auth services and complete built-in Auth UI, making complex organization management much easier.

There's so many options here. Yeah, and the best GraphQL client library, Relay, is also available in React. Probably a story for another talk, but yeah. There's also an npm package for every single character in the English alphabet, just one character exported at a time. Yeah, so there's so many of these third-party integrations with React 2, lots of the sponsors of this conference, but also analytics providers, error monitoring, A-B testing. This is something I've actually kind of learned as I've been doing this at MISTEN. You would not believe how many no-name analytics providers also have React bindings and integrations pretty deep into React router to kind of provide good analytics there. Yeah, and there's also a lot of off-the-shelf UI components in the React ecosystem. You mentioned some of them, but even for more complex use cases like Auth, there's companies like Qlrk that provide both Auth services and complete built, Auth UI. They have components that let you create organizations and switch organizations in complex organization management situations, which is kind of crazy to think about that all of that entire problem area is solved now. Yeah, it's kind of awesome that you don't have to write any code. Yeah, the best code I ever wrote was no code for sure. Exactly, so, checks out.

5. React Performance and Integration

Short description:

React has good out-of-the-box performance and is suitable for most applications. Frameworks like Next.js and Remix provide automatic code-splitting and server-side rendering, resulting in improved load times and user experience. React features like Suspense and React Server Components offer more ways to fine-tune performance. Other libraries like Quick and SolidJS can be integrated with React for performance-critical components. The component-based nature of React allows for easy integration between frameworks.

So yeah, and I'm going to say something that counters a very popular narrative right now and that React has pretty good out-of-the-box performance. Like, sure, there's more performant libraries and sure there's some cases where React might suffer performance issues, but who hasn't? So for most applications, React performs very well.

To further this, a lot of frameworks that make the web experience of React better, like Next and Remix, they exist, sorry. Next.js has automatic code-splitting, which I mentioned earlier, which means that users only load the JavaScript necessary for the page they're viewing, and so this reduces load times drastically, and they also use server-side rendering by default, so that makes sure you have the best default user experience for your site. And so yeah, these frameworks' Lighthouse scores are great out-of-the-box.

Yeah, and there's also React features that give you a lot of ability to fine-tune performance, especially some of the newer ones like Suspense and React Server Components, which I don't want to unpack the controversy of here, but these are ways that, they do give us more ways to deal with performance in a more nuanced manner. There's also projects like Astro out there, who have tried this islands approach of solving performance, which is kind of an interesting take at it. In extreme cases, you can also be non-exclusive with React, this is a little bit interesting, but you can always write performance critical components in other, maybe more performant libraries, like maybe Quick or SolidJS and have those integrated in your React tree. The beauty of component-based frameworks is that the component boundary ends up being pretty good and it's pretty easy to integrate between frameworks. And, obligatory, like the React team will also remind you, maybe there's an optimizing compiler. I've been hearing that for years, but it will solve all of our performance problems. So, yeah.

6. React Native and Building Products

Short description:

React Native is super useful because it allows code sharing between React and React Native. At Discord, product engineers work on both front end and back end. React's knowledge extended into the mobile app space is beneficial. Missyn also considers React Native for their products. React is a great choice, and it's okay to not use every feature. Focus on building your product and don't get distracted by shiny tech.

And at the end of the day, like your app's probably not even shipping, so why are we even talking about performance? Yeah. And yeah, some other things that I want to mention, Discord has found React Native super useful because we use React. And so, the ability to use React Native and share code between the two is super helpful. And so, at Discord, the product engineers are a little different. There's no, like, front end or back end. Everyone kind of does all part of the stack. So, for example, for me, I have to write React Native, I have to do native code, all that. And so, having something that I can, like the knowledge of React extended into the mobile app space is super useful for me. And so, I really like that.

Yeah. And at Missyn, we've also been kind of looking at React Native for some of our products. And having a product suite that's already built in React makes it a much simpler proposition. Yeah. Exactly. So, yeah. I mean, this sounds pretty great, you know? React is awesome. Yeah, we wrapped up our talk in ten minutes. So, yeah, we can use React for everything, you know? I mean, nobody ever got fired for picking React. Yeah, they also say that about Java. But, yeah.

So, let's take one big step back. And understand some of the more nuance here. Just because you pick React doesn't mean you need to pick every feature of React. This is kind of what we were alluding to earlier with some of the non-exclusivity with performance. There's a lot of things that you might not have to use in React. There are lots of cool new features like Server Component Suspense, but it's totally fine if no one here is shipping an app with that. Most of the cases, what you want to focus on is building your product and not over-focusing on how you're building your product. Don't get too distracted by shiny tech. I'm not trying to shame you if you do. I get distracted by shiny tech all the time.

7. Choosing the Right Framework

Short description:

React is a good pick, but it's not the only pick. There are a lot of React devs, but there's also a lot of Vue devs, there's a lot of Svelte devs, there's a lot of Solid devs. These days, when it comes to performance, it seems like it's table stakes that new libraries beat React in some performance metric. There's no objectively right or wrong decision that you can make here. What we've presented here actually isn't a reason to pick React. It is a set of evaluation criteria that we have looked at React through the lens of. Maybe familiarity is the most important at your company, or maybe performance is really critical. It's really subjective based on where you're making this decision. Let me give you an example of how importance can impact these decisions. Prior to me joining Misson Labs, I worked at Netflix on our TV application, and one of the biggest pieces of feedback that we got from users was that performance and stability were the key drivers of user retention in our apps. We ran some experiments using Svelte and saw significant performance and memory improvements.

I spend my weekends looking at things. She hates it. Focus on what makes sense to you. Really, what we want to get at here is React is a good pick, but it's not the only pick. There are a lot of React devs, but there's also a lot of Vue devs, there's a lot of Svelte devs, there's a lot of Solid devs. There's a lot of React packages in tooling, but similarly for those other frameworks, there's a lot of really good packages in tooling.

These days, when it comes to performance, it seems like it's table stakes that new libraries beat React in some performance metric. Looking through this evaluation criteria that we talked about before, if your team is entirely comprised of Vue developers by trade, maybe it makes sense to pick Vue instead of picking React. You don't have to default to React just because it has a big ecosystem. At the end of the day, it's just a set of trade-offs. There's no objectively right or wrong decision that you can make here. Maybe in your case there is, subjectively to you, but there's no globally correct framework that you should be working with. It's just a matter of looking at what decision you have to make and looking at what's important to you and evaluating it against that.

There's a lot of really great devs out there that don't use React, and this is a point that I always try to make. Even personally, I love Veep Press. It's a project that is based on Vue, and some of the favorite projects that I use are documented with Veep Press, but I really want to keep using React, and so that's inaccessible to me. That's a tradeoff that I'm comfortable with, but it is a tradeoff by only investing in a React ecosystem. So really, what we're talking about here is what is important to you. What we've presented here actually isn't a reason to pick React. It is a set of evaluation criteria that we have looked at React through the lens of. For example, we've looked at familiarity, the ecosystem, the performance, native support, but we've kind of assumed that these are all equally important, and in most cases, they're actually not. Maybe familiarity is the most important at your company, or maybe performance is really critical, and you need to have a performance app that React maybe can't meet the needs of, and maybe there's entirely different evaluation criteria that we haven't even talked about here, and it's really subjective based on where you're making this decision.

So let me give you an example, a very concrete example, of how importance can impact these decisions. So prior to me joining Misson Labs I actually worked at Netflix on our TV application, and the TV application's a big React application, there's a custom React reconciler that works with all the TV platforms, it's kind of crazy. I worked on a team that specifically looked at the memory and performance of that React application, and one of the biggest pieces of feedback that we got from users and that we saw in A-B test results was that performance and stability were basically the key drivers of user retention in our apps. And the TV platform has really interesting constraints. We were using a JavaScript engine that I think at this point is 10 years old, like 10-year-old JavaScript engine, which is insane. There was no way to run JIT, and there was kind of all of these interesting constraints with how the images were painted on the screen, and we looked at React's rendering model and intersected with those constraints, it kind of ended up with a lot of memory that ended up needing to be garbage collected. We ran some experiments using Svelte to see if its compiler architecture would yield improvements, and what we saw was that we actually spent 10 times less time in garbage collection pauses by leveraging Svelte. And we saw similar performance improvements and overall memory improvements throughout the rest of the application.

8. Trade-offs in React to Svelte Migration

Short description:

When considering a migration from React to Svelte, there are trade-offs to consider. Losing access to community packages and onboarding React developers to Svelte can be challenging. Code sharing and the motivation of other teams also play a role. These trade-offs depend on the context of your project. Using data to make decisions and evaluating different solutions can help solidify your choice.

And unfortunately, I left Netflix before we were able to really capitalize on these findings, but when we looked at this migration, this hypothetical migration from React to Svelte, we looked at our evaluation criteria and we looked at a set of tradeoffs. Are we comfortable losing access to the community packages that we were using? Quite frankly the package JSON on the TV application is mind bending. It is one of the largest I've ever seen, and we would lose access to a lot of the packages that we were previously depending on. And sure there were Svelte versions of some of the things that we were using, but it wasn't quite at the point that it was with React.

Were we willing to onboard all of our React devs to Svelte? This is a big question. Everyone was hired to work on a React app and now we have to figure out what the best practices are. We have to figure out day to day how we're going to actually teach people to use Svelte, what that migration would look like. And it's worth noting in extreme cases, changes like this can actually lead to attrition. People can be very motivated about their JavaScript frameworks and might want to keep working on a technology stack that they're familiar with.

And were we okay losing the code sharing that we had previously depended on? Netflix was a big React shop and we would not really have the ability to share some of the components that we previously had been. Especially given the other teams weren't necessarily motivated in the same way that we were to make this change. And at Netflix, this set of trade-offs was actually something that we were reasonably comfortable with. There was a lot of time and resources we could dedicate to a project like that. But if you're at a company that doesn't necessarily have performance as a number one metric, or the time or resources to invest in something like this, these trade-offs might terrify you. And that's totally fine. It's why it's really key to make these decisions in the context of your project or company Understanding what trade-offs are important to you and what the relative importance of how you're evaluating your project is.

And the other thing is, if you do find yourself in one of these very specific situations, so similar to what we did with Netflix, take time and try to use data to make this decision. So what you probably want to do is spend time evaluating what your different solutions are, seeing what they give you and measuring very concretely if they're actually accomplishing what you set out for them to accomplish. This is what we did at Netflix, there's a thirty-plus page document that exists somewhere internally at Netflix, I wish I still had access to it, that captured all of the nuances between the different rendering, the different ways rendering worked in these two frameworks and the alternatives that we considered, and very concretely what the impact of that would be. This is a really good model when you're trying to make decisions that go against the grain. What I mean by this is if you're a company that primarily uses React, you're trying to convince folks to use something else, that's a decision that goes against the grain. These types of decisions tend to have a ton of inertia behind them. You have to generally put energy into changing the course of that decision. And similarly to Netflix, when I was at Square we were making the decision to move our Ruby on Rails application to some JavaScript framework. I had to do a deep dive analysis on Svelte versus Preact, et cetera. I used data to compile this, looking at things like bundle size, request time, all that. The data really helped me drive validity into my choice. I ended up picking Svelte. I was able to use that and show non-technical people things and point them to data so they can feel better about the choice. It helps also solidify what the user impact will be.

9. Final Thoughts on React

Short description:

React is great. It has great resources, packages, and a supportive community. When making decisions, consider the weight they carry and focus on what you're building. Avoid FOMO-driven development and don't feel pressured to adopt new technologies just because others are using them. Thank you all for attending this talk on choosing React. It's controversial, but it's clear that React has many advantages.

Exactly. So anyway, we lost the lead here, but React is great. Not trying to tell you React is bad. React has great resources, it has great packages. It has a great community. We're all here right now at this talk. But there's also more out there. These decisions, you know, they carry a lot of weight, so just think about what you're doing before you make a decision like that. But in most cases, try more to focus on what you're building and less about how you're building it.

And really, really importantly, try to avoid FOMO-driven development. This is a trend I've seen increasingly on Twitter. Greatest platform, I guess. But it happens to the best of us. Even me, the best of us. This happens very frequently. And you know, not only with new libraries and frameworks, but even with new features in React. Don't get FOMO just because you see someone on Twitter using something that you maybe want to use. Doesn't necessarily mean that you need to use that. You could keep building product the way that you've been building product. But also, maybe think about what they're using, because maybe it's good. But I don't know. Like, you're a smart group of people. I'm sure you'll figure it out. Yeah.

So yeah, anyways, thank you all so much. This is a talk. I hope everyone enjoyed this little nuance on why to choose React or not. It's controversial, of course, like I said in the opening. But I think you've actually made a great advertisement for React. I was thinking you would be more nudgey, like, going, like, no, no, but Svelde? I mean, you know, I figured we had to, you know, throw a bone to React given it is React Summit.

10. React, Onboarding, and Choosing Frameworks

Short description:

Despite having a passion for things outside of React, I still love it. React is a great pick, but it's not the only thing. React offers a standardized way of working and easy onboarding. However, when it comes to choosing between different frameworks, it can be challenging to change the established tech stack. Unifying the tech stack requires careful consideration and discussions with the team.

I do, I mean, despite me also having a big passion for things outside of React, I still really love React. I mean, I had the choice to use anything else at my new job when we were setting things up. I still reach for it by default. I think it's still a great pick. I mean, it's just that, you know, it's not the only thing, right?

Is this prop water or is this real water? It's proper water. You can grab it. Real glass also. Oh, nice. Yeah. But one important thing is that you touched on in the start, I think, is that the onboarding time. I think React is, besides that it's a great framework and everything, it's also a great standardized way of working. And indeed, even in a big code base, like I work at Miro, we have a few hundred frontend developers and still people can get onboarded within a matter of days. And that's also one of the biggest powers that I think, that you have when using any framework probably. And then as far as I know, React is of course the best. Would you agree? Would you agree? Yes?

But have you ever had really sat down with your team like you gave the example at Netflix, but maybe at Discord like, okay, for this new product, come on, let's go the Spelt way or let's go the Angular way, or? I don't even know how I would approach that at Discord. I feel like a lot of people are very set in their ways too. And everything that we have at Discord is based on React. React Native would be a hard thing to position towards. But maybe if there's a marketing site or something, that's something that could come up. But yeah, no. I don't think I have done that too much. Have you? Yeah. The example at Netflix. Yeah. I think also for me, like we hadn't really picked a unified tech stack. There was a project in View, there was a fledging project in Spelt that people were talking about. And then there was—or I think people had been talking about or looked into Spelt. And then there was some React projects. And so we hadn't really made a decision to unify. When I joined, I kind of talked to a lot of folks on the team and we did make the conscious decision.

11. Contextual Considerations for Choosing React

Short description:

We wanted to pick React because we were familiar with it and saw potential for future React Native projects. The outcome would have been different if we were View developers or had performance issues. The decision is highly contextual.

So like, let's just, you know, we wanted to pick React. And for a lot of the reasons we talked about. Like we knew that maybe there's React Native projects down the line. And we didn't really see the benefits that I think some of the other frameworks would have given us, given we all were familiar with React. But I think if we'd had that discussion and we're all View developers, the outcome would have been very different. And I think if we had had that discussion and had performance issues in our app or something else, like I think that we've—the narrative of that conversation would be very different as well. So it is, it's very contextual.


React's Contextual Suitability and Opting Out

Short description:

React is never objectively bad, but there are contextual cases where it may not be the best choice. For example, in game development, it can be challenging. If millisecond update times are crucial, React may not be the ideal option. However, React offers flexibility, allowing developers to opt out of its rendering model in certain cases. It's important to use React where it's needed and opt out where it's not. React can still deliver good performance, as shown in Misko's talk. Canvas is occasionally used alongside React at Miro. A question from Alexander asks about the availability of the Why Not App Router talk.

Alright, thanks. We have questions from the audience. I'm just enjoying my own conversation, but I'm not supposed to do this.

A question from anonymous. What use case do you think React might objectively be a bad choice for? Yeah, I mean the case that I always come up with is—well okay, I don't think it's ever objectively like bad. I think it's like maybe contextually bad. You have one? I have one. Building games with it? We have one talk about someone who built a proper game. It was hard. But I think it's already been, or? Has that talk already been? No, it's on Monday. I think it's on Monday. Yeah, I used React 3 Fiber, it was one of the hardest—it was very humbling. I think game development is just hard. I know, that's true. What was your piece? I think it's never objectively bad, I think it's contextually bad. I think if I was working at Bloomberg on their next generation terminal, where millisecond update times matter, you know, maybe something like that, where you really care a lot. Or maybe, I don't know. I'm sure that there's lots of these extreme cases where it might not benefit you, but you always have—I think one of the powers of React is that you have so many ways to opt out. Like, with Canvas, for example, React and Canvas kind of have a—they're not the tightest things to integrate. So, if you're doing Canvas rendering, a lot of times you'll just opt out of the React rendering cycle by getting a ref and doing a lot of imperative logic there. I think that's kind of the beauty of React, is that you can kind of opt out of its rendering model in a lot of cases that you would normally maybe say it's a bad decision. Yeah, use it where you want it where you need it and opt out where it's not. And even, like we've seen this morning with Misko's talk, you can just quickify it and boom, you still get the performance. Yeah, we use Canvas every now and then at Miro. Every now and then? Yeah. Yeah. Question from Alexander. Is the Why Not App Router Talk also available? He's asking for a friend. Sorry, is what? The talk you mentioned at the start, Why Not App Router. Yeah.

AppRouter and Reactions

Short description:

AppRouter exists in my head. I think it's great and hilarious that we put a slide to tease Lee. People's reactions to AppRouter are interesting to watch on Twitter. I personally love it and even gave a workshop on it.

What about it? Does it actually exist? It exists in my head. I mean, I think AppRouter's great. I do think it's hilarious that we were speaking opposite Lee, which was kind of why we put the slide in there, just a little dig at him. But, yeah, I don't think we really have any real objections outside of, I think it's funny how many people hate it. I also think it's interesting to watch people on both the pro and the con side gradually lose their mind on Twitter, arguing the same points over and over. I think people just don't like change, right? I personally love it. I gave a workshop on it, love it.

React's Scope and Freedom of Choice

Short description:

Question from Jay: What is the scope of React in the future? If given the freedom to choose, the speaker would stick with React due to its usefulness in various use cases and its compatibility with Electron and React Native. The speaker would consider minimizing the use of Flux for stores and explore alternatives like Zustand. Despite being relatively young, Discord has made a significant impact. The speaker humorously mentions jQuery's continued popularity compared to React's smaller user base.

Yeah. Question from Jay. What is the scope of React in the future? I'm not sure what Jay means by this. Is Jay here? Maybe Jay can elaborate, or is Jay remote? Remote Jay, can you elaborate? Remote Jay? No, remote Jay? What is the scope of React? It's a big question. In the future. Let's go ask Lee. Let's go ask Lee. We will have to ask the ForSale guys. Thank you.

All right, question from Anonymous. If you had the full freedom to write Discord with a big enough team in any framework, would you stay with React or hop into another framework? Oof. Okay. I don't think the thing that I would change is React, because I think we get a lot of good use cases out of it, like Electron and all of that, and then React Native is super useful. We do a lot of native code as well, so Objective-C, Swift, Kotlin, but the React Native side helps a lot. I think what I would change is we use Flux for our stores, and there's a lot of stores. So I would figure out a way to kind of minimize that. We've been pulling in stuff like Zustand. Is that Zustand? I don't know. That sort of stuff. But far from that, I don't think I would stick with React. I think that's the one I would pick, yeah. Plus Discord came out like in 2015, 2014, right? Is it dead young? Yeah. It's not that old. It feels like it's been around for ages. Maybe I'm wrong. I just randomly come up with a date. No one fact-checkers. Wait, what would you do? If I was React, would you? Have you heard of jQuery? Hey. It's still the biggest thing out there. I mean, React is a fraction of the use base of jQuery.

Using Rust and Tori, TRPC, and GraphQL

Short description:

I use Rust and Tori for my projects. Rust can be compiled to Wasm, which allows everything to be in Rust. A question was asked about TRPC, and the speaker shared their positive experience with it. They also mentioned inventing a similar tool called MagicAPI. Despite liking TRPC, the speaker prefers GraphQL.

Oh no, you know what I do? I use Rust. And use Tori. Well that's true, yeah. Then you gotta still have a UI layer. Yeah, that's true. That's true. Dang. Right. Rust. Compile it to Wasm. And then have everything in Rust. Sounds like proper job security driven development right there. Exactly. Exactly.

Here's a question from not-Teo. Not-Teo, so Teo is not asking this question. Teo is remote I think. What's your opinion on TRPC? Oh. So, okay, I used it a long time ago for a project and it was super, super awesome. It was really easy to use. I'm really bad at talking about the technical side of things, so he was the one that introduced me to TRPC for that project if you want to talk about it a little bit. Fun fact, I invented TRPC before it was invented. It's on my GitHub. It's called MagicAPI. Shameless plug. I mean, it's awful. Don't use it. But, no, I love TRPC. I like GraphQL more. I'm a big GraphQL stan.

TRPC, Implementing React, and Final Words

Short description:

TRPC can be a great solution for solving problems in smaller scales, but may not be suitable for huge companies with thousands of microservices. Implementing React in already built systems, such as IT service management systems, is highly contextual and depends on factors like company processes and project scopes. The approach taken can vary greatly, from year-long discussions to simple migrations. Thank you for attending this talk and enjoy your time in Amsterdam!

But I think TRPC does solve a lot of problems, especially in smaller scales. I think... I couldn't imagine using TRPC at like a huge Netflix-sized company, but I think TRPC's great. Yeah, even for a lot of companies. It's just like, you know, when you have a thousand microservices and you're trying to aggregate those into a big graph, I think TRPC would not be the best decision.

All right. Thanks. Yeah. And then we have time for one more question. And it's from a great visitor called Anonymous. What approach should we use when implementing React in already built systems? For example, IT service management systems. Do you want to take this one? I don't have a lot of opinions. I mean, like the whole point of the talk, which is, you know, it is a cop-out, but it's very contextual, and like, how your company operates is different. I mean, like, you know, the approach that I took at Netflix, for example, was, I mean, it was a year long and still was an ongoing discussion by the time I left. And to this day, now a year later, there is still some discussion ongoing about like, what is the next thing? So it's not an easy discussion and every company will navigate this differently. So, but similar, like at my current company, we've done view-to-react migrations that were just as simple as going to a group of people and saying, hey, are we all cool with this, right? So it is going to vary a lot by, you know, what your company's process, you know, how, what the scope of these projects are, all that. But yeah.

All right, well, we have minus 13 seconds left. Any last words? None. It was great doing this talk. Thank you so much for inviting us. All right. Enjoy the rest of your time in Amsterdam.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
JSNation 2022JSNation 2022
28 min
Full Stack Documentation
Interactive web-based tutorials have become a staple of front end frameworks, and it's easy to see why — developers love being able to try out new tools without the hassle of installing packages or cloning repos.
But in the age of full stack meta-frameworks like Next, Remix and SvelteKit, these tutorials only go so far. In this talk, we'll look at how we on the Svelte team are using cutting edge web technology to rethink how we teach each other the tools of our trade.
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.
In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.
React Advanced Conference 2021React Advanced Conference 2021
27 min
(Easier) Interactive Data Visualization in React
If you’re building a dashboard, analytics platform, or any web app where you need to give your users insight into their data, you need beautiful, custom, interactive data visualizations in your React app. But building visualizations hand with a low-level library like D3 can be a huge headache, involving lots of wheel-reinventing. In this talk, we’ll see how data viz development can get so much easier thanks to tools like Plot, a high-level dataviz library for quick
easy charting, and Observable, a reactive dataviz prototyping environment, both from the creator of D3. Through live coding examples we’ll explore how React refs let us delegate DOM manipulation for our data visualizations, and how Observable’s embedding functionality lets us easily repurpose community-built visualizations for our own data
use cases. By the end of this talk we’ll know how to get a beautiful, customized, interactive data visualization into our apps with a fraction of the time

Workshops on related topic

React Advanced Conference 2021React Advanced Conference 2021
132 min
Concurrent Rendering Adventures in React 18
Workshop Free
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?
There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.
Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.
You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.

React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Workshop Free
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.
The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.
React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.

React Summit 2023React Summit 2023
171 min
React Performance Debugging Masterclass
Workshop Free
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Workshop Free
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.

React Summit 2023React Summit 2023
152 min
Designing Effective Tests With React Testing Library
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents
- The different kinds of React application tests, and where component tests fit in
- A mental model for thinking about the inputs and outputs of the components you test
- Options for selecting DOM elements to verify and interact with them
- The value of mocks and why they shouldn’t be avoided
- The challenges with asynchrony in RTL tests and how to handle them
- Familiarity with building applications with React
- Basic experience writing automated tests with Jest or another unit testing framework
- You do not need any experience with React Testing Library
- Machine setup: Node LTS, Yarn