Should You Use React in 2023?

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.