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?
Should You Use React in 2023?
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
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?
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
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
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
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.
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
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
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.
8. Trade-offs in React to Svelte Migration
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.
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.
9. Final Thoughts on React
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
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
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
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
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
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
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
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.