Panel Discussion: Open Source & “Perceived Competition” Between Projects

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Watch video on a separate page

FAQ

Open source contributors often choose projects based on their work needs or personal interests. They might create or contribute to a project if it solves a problem they face or if it's something they find intriguing. Building expertise in a specific project can be beneficial and fulfilling.

Contributing to open source projects offers opportunities for learning, collaboration, and skill enhancement. Contributors can gain valuable experience, network with like-minded individuals, and sometimes even become project maintainers.

Even with limited time, one can contribute by writing detailed bug reports, filing issues, or starting with small fixes. These contributions are valuable and can gradually lead to more significant involvement over time.

Competition in open source is often about ideas rather than individuals. Healthy competition encourages innovation and improvement, driving projects to evolve and offer better solutions. It's more about collaboration and learning from each other.

AI tools can help contributors understand complex codebases by explaining code structures. While AI can assist in generating code snippets, users need to verify the accuracy as AI outputs may not always be correct.

Maintainers should focus on the competition of ideas rather than individuals, fostering an environment where ideas can be shared and improved upon. It's important to collaborate and learn from different projects to enhance the overall ecosystem.

Documentation is crucial as it helps new users understand how to use the software, contributes to knowledge sharing, and assists in onboarding new contributors. Good documentation can significantly enhance a project's usability and adoption.

Beginners can start by engaging with the community, working on documentation, writing tests, or addressing small bugs. It's important to pick projects that align with their interests and gradually increase their level of involvement as they gain confidence.

Contributors should be prepared for both successes and setbacks, as not all contributions may be accepted or receive immediate feedback. It's important to focus on learning and collaboration, seeing it as an opportunity to grow and contribute to the community.

Non-code contributions include improving documentation, writing tests, providing detailed bug reports, and helping others in community forums. These contributions are vital for the growth and maintenance of open source projects.

Michel Weststrate
Michel Weststrate
Mark Erikson
Mark Erikson
Alessia Bellisario
Alessia Bellisario
Fredrik Höglund
Fredrik Höglund
Dan Abramov
Dan Abramov
29 min
20 Oct, 2023

Comments

Sign in or register to post your comment.
Video Summary and Transcription
Panel discussion highlights insights on choosing inspiring open source projects, work-driven contributions in React and Redux, showing initiative through pull requests, maintainer rights based on engagement, challenges in pull request reviews, healthy competition dynamics, AI's role in open source, diverse non-code contributions in documentation and testing.

QnA

Insights on Choosing Open Source Projects

Short description:

Thank you for joining the panel. Open source contributors share insights on selecting projects. Importance of choosing inspiring projects. Find communities that draw you in. Early career interest in open data and civic tech.

Thank you, everyone, for joining this panel. I'm sure everyone is very excited to hear your insights on all things open source.

So the first question is, as open source contributors, involved in multiple projects, can you share your insights on how you decide which projects to contribute to or create? We can start off with Dan. Sorry. The question is, which projects have you worked on? Just insights on how you decide to pick which projects to work on or create. Oh. I mean, I think usually it's, like, whatever you need for work. That tends to be the case. I think, at least in my case, I haven't created many projects. I contributed to a bunch. But in cases where I created something, it was usually because I was building a product and I needed a piece that did not exist. And I tried to make it. And then sometimes you try to make it usable by other people. I think it's mainly about the project that kind of inspires you or intrigues you. Just pick one. It doesn't really matter which one. Just don't try to do all of them. That's the most important thing, I think. And then you become an expert in one specific one. And that's, like, really helpful. Because you see all the different environments that people use something in. Which is often really surprising. But that just requires time to build up that knowledge. So just pick one that intrigues you.

Yeah, I think for me it was really sort of finding communities that I felt drawn toward. At the very beginning of my career, I was really interested in open data and civic tech. And just found really welcoming people in that space. I didn't have the skills yet at that time to really meaningfully make an impact. But I still felt like it was just a really interesting time to be exploring, at that time, these Ruby libraries for data processing. And if it wasn't for the community around that, I wouldn't have maybe even started this career.

Work-Driven Project Contributions

Short description:

Projects driven by work needs. Learning React and contributing to Redux. Gratitude to Dan for open source start. Encouraging others to find time for contributions and seize opportunities.

I think for me it's always been work driven. Or that's where I've found the projects I want to work on. I had a problem at work. Like, where I saw a missing piece that I wanted to contribute. And then I did. Back when I had free time. I started learning React in mid-2015. Sort of related to a work project. And it was coincidentally the same time that Redux came out. I volunteered to write an FAQ page for the Redux docs. Dan accepted it and merged it. Gave me commit rights. Got busy with React. And then handed over the maintainer keys of Redux to me and another guy named Tim Dorr.

I owe Dan for my start in open source. I wouldn't be here without him volunteering to say, hey, you can get involved. And I owe you. Since I first got involved in Redux, too. Whenever we talk about this, I think about this scene from Tom Sawyer. Painting the fence. Or he paints the fence and makes it look like the most interesting thing someone can do. And then somebody takes over. Great. That's so cool. And I love the fact that you were speaking about the opportunities that you gained.

As someone who wants to be an open source contributor, what cool opportunities have you seen other people get? Have you got yourself? And what would you say to someone who feels like they don't have enough time for it? How would you convince them to actually make time to contribute to open source projects? We can go the other way around this time to switch it up. So I'll give a relatively recent example. We've had two primary maintainers on Redux Toolkit for the last couple of years. Myself and Lenz. And we had a person hanging out in our chat channel answering a lot of questions named Ben.

Initiative in Open Source Contributions

Short description:

Contributing through pull requests and showing initiative. Viewing open source contributions as part of your work. Learning through issue filing, reproductions, and project involvement.

And about a year ago, he started contributing some actual pull requests with features. And he was enthusiastic and the pull requests were well tested and he was answering questions and we could see he was actively contributing. And so he was like, you're a maintainer, too. Welcome, join us. And it's kind of like that showing the initiative and trying to get involved, that shows the maintainers that you're interested, you get their trust, and they'll be happy to hand over more responsibility.

So I have a different answer. And that is, like, that's a good answer. But I also have a different one. That is kind of see it as part of your work, too. Maybe not contributing huge amounts of code or anything like that, but you are software developers and you're using third-party libraries. So if you come across a bug and you want to get involved in open source, the best thing you can do is write a good reproduction of that bug, file a very good issue, and that's a perfect way to get involved in open source. And as you do that in different projects, you start to kind of learn about the project.

You see the fixes. You see the pull requests that maybe someone else wrote. And given enough time, you might be comfortable to actually fixing the issue maybe in your work time where you get paid for it, if it's a small fix and it's something that you benefit in your company. And things like filing issues and stuff like that, don't ask for permission to do that. That's part of your work. Like, if you're spending days on it, of course, it's different. But yeah. Yeah, and another thing that I found, especially in the course of doing your day job, like, my day job currently involves working on an open source project, but before that, I was a product engineer at a bunch of different companies.

Learning and Maintainer Rights

Short description:

Contributing to open source for learning and mentorship opportunities. Granting maintainer rights based on active engagement and quality contributions.

And the last job I had working on a product was at Venmo. So we were using a lot of the tools that we all use in this room, but for testing, obviously, testing library. So setting a whole team up to contribute to a large test suite, we were using some linting rules from the testing library ESLint plugin. And browsing through the GitHub issues, I saw there was some ideas for new rules to add to that library and thought, okay, well, I haven't written an ESLint rule before. This seems like a good opportunity to contribute to something that will also benefit my team but contribute to the larger community. And what was so cool about that experience and, you know, amazing maintainers on that project is just, you know, being out of your comfort zone, working on, like in my case, you know, understanding abstract syntax trees, learning about just the whole DX of developing and testing linter rules, and then getting this amazing code review from folks who are extremely well versed in, you know, in this particular area.

And that being like such an amazing learning opportunity, no matter what stage of your career you are, you know, the cliche about software is that it's just an unbelievably vast and expansive field. And so it's open source for me has always presented a really fun chance to get outside my comfort zone and, you know, be able to have give and receive mentorship in a really generative, really productive way. So I don't think I've ever given maintainers right to anyone that was like asking for it. That's not kind of how it works. First, kind of the opposite, whenever it gets annoying to not make someone a maintainer, then I make that person a maintainer. That's basically the essence. That sounds very negative. But what I mean with it is like, if people respond regularly on issues, they're like, oh, I can't reproduce this, or this is the fix. And then they answer, but they can't close the issue.

I'm like, Oh, it would be very convenient if that person is on spot every time, we'd also close the issue. So it gives the rights for that. Same with pull requests. If someone submits free pull requests, which are pretty good, then it's annoying that that pull request lives in their own form, because you cannot commit back and that kind of stuff. So you invite them to become a maintainer. And that's how it generally works, I think. Okay, can I ask you to repeat the question? It's been a while. I actually didn't write this down. But it was just about how would you convince someone to contribute to open source and what opportunities have you got? Someone else? Yeah, I guess like, I don't see myself in the business of convincing people to contribute to open source. Like, it's not necessarily a good idea always. Like, both for your and the other person's sanity. Like, okay, more seriously, I think, like, there are different kinds of contributions. And also, like, I think some end up, you know, like, realistically, if you send the PR, sometimes, you know, it's going to get merged, it's going to get reviewed. Sometimes it's, it's not going to get reviewed, they're not going to get merged.

Pull Request Challenges and Bug Reports

Short description:

Challenges in pull request reviews and the value of detailed bug reports for maintainers.

Sometimes it's, it's not going to get reviewed, they're not going to get merged. And sometimes you get some good experience out of it, or like you get some knowledge out of it. And sometimes you just waste the time. So I think like, it's just, like, in my experience, I feel like I've gotten lazier about sending pull requests, because I'm just well, like, it looks like the person maintaining is it is pretty busy, like, their views are not coming in fast. Or like, it looks like the change I'm about to make, like, I don't even know if that's a good change. So I'm probably just not send it. So I don't know if like, it's always a good idea. But I think so like, like, I think it's just important to be prepared for disappointment that like you worked on this pull request for like a week and then nobody reviews it like that happens. But in terms of like what as a maintainer, like what I would usually find most valuable is, yeah, so like issue, when there is an issue, and I don't know what the problem is, like, there is a bug filed. And somebody says, like, oh, this thing is crashing, but like, I don't know how to reproduce it. And then somebody else comes over and digs into the code and like gives a precise way to reproduce the bug. That's very valuable. And so like, as a maintainer, I say, okay, like this person is actually like looking at what's happening in the code, and it's trying to help. And I just trust this person more. And then if this person sends a, you know, a code change, like, again, I kind of trust them more, it's easier to review.

Open Source Contribution Genres

Short description:

Two genres of contributions to open source: sending small changes for potential improvement and deeply engaging with project code to ensure quality and reliability.

And I think like, if you do want to kind of contribute to open source, I think there's just kind of like two genres. Like one genre is you send like a small change, and like you barely, you kind of just like throw it away. Like, here's the thing that worked for me, like, good luck with it. And then it's, it's still nice, because it gives maintainer a chance, like maybe that's a good idea, maybe that's a good change, or it gives them, you know, an idea to do something different. But it is kind of a contribution, right? You just send something out there, and hope it will help somebody maybe even like a random person scanning the pull request to find the fix for the same issue.

And another genre is actually like diving into, like how, like how the rest of the project's code is written, and kind of like really testing your change, really thinking through, like, you know, is this the right change to make? Or does it break something else? And then as a maintainer, if I see that, you know, it looks like you've done your homework, so to speak, it's so much easier to trust that sometimes I'm like, yeah, like, you know, looks good. Hopefully, this doesn't break stuff. But if it breaks stuff, I know there's a person who cares, who will come back and fix it.

Navigating Healthy Competition Dynamics

Short description:

Exploring healthy competition, implicit codes of honor, and challenges in maintaining balance amidst different player sizes and approaches.

Yeah, I don't know. That's helpful. No, thank you for that. Those are really good answers, because you spoke a lot about collaboration, upskilling, and how it can actually help you in your day job to improve like your coding practices and things like that. But we're here about the competition. And so what differentiates between, because all competition isn't bad, right? There's healthy competition. But what differentiates between from healthy competition to unhealthy competition? And how do you foster and make sure that we engage in a healthy kind? And do you feel like as maintainers, you have a role to play within this? So let's start off with Dan.

Oh, that's a tough one. Yeah, I'm not, I don't know. I don't want to set the rules. I think, I think there is like a kind of code of honor, an implicit code of honor, but I think it's different for different people. Like, not, you know, not saying like, I'll try bad things about other projects seems like maybe a good idea. But then there are some differences. And sometimes these differences are pretty significant. And so there's like this hard, like hard balance of like, how do you, and especially like, there's, you know, there's this equilibrium of like, if everybody is nice to each other, it's nice.

But then like, if you're if there's like a new, you know, there's like an established kind of set of players, and then there's a new player who, like does something differently. And because they're small, they kind of need to punch up, because they need to kind of prove, you know, here's why you should choose the small thing over something established. And so they kind of have to, like, expose the flaws in the establishment. And then the thing is, like, the established players can't really punch down because it looks bad. And so it's it's like a tough balance of like, how do you play this game? I actually don't know. Let's hear from other people.

Yeah, I think like, competition is a bit overperceived. In some ways. I have like a bunch of really interesting anecdotes around that. For example, I worked for quite a long time on my bags. I don't really like my bags that much. So here's the fun thing. Dennis is currently working with MobX, I'm currently working with Redux. I don't like... So that's how far competition goes.

Insights on Open Source Competition

Short description:

Exploring perspectives on open source competition, biases, and the positive impact of healthy competition in personal and professional growth.

No, but I literally had people walk up to me and said, like, why did you publish Immer? That only helps Redux and MobX? And it's like, yeah, who cares? Like, it's people sometimes think about open source as companies, where they're like, companies are competing with each other in a certain way. Right. And so they also talk like that's an issue. And they go like, hey, if you don't introduce this feature, I'm going to move to Redux. And it's like, okay, fine. Then apparently Redux is better for use case. So I rather have you move to Redux so that I don't have to deal with your issues. So people kind of over appreciate how that's in general works, I think. But the kind of rule I try to keep in my mind, as like, you're basically a jitters out there. Like, I have an opinion about other frameworks. Everyone here has an opinion about other frameworks. I asked JetGPT this morning what Mark thinks about MobX and it don't make me sleep really well. But just hallucinated, sadly. But anyway, like, we are all biased in a certain way. So it's up to you to decide what kind of works.

I think that's like the fair way to divide it. I think that's well said. Yeah, I think the whole question of competition, I don't know, I think of my kind of frame of reference for competition is playing sports in high school. And, you know, specifically basketball, soccer, football. And, you know, my, like, my coaches just really instilled this idea that like, you really want the competition at its best is when your opponent really pushes you to evolve and sort of bring the best that you can bring to the table as well. So I really think that, you know, it's sort of like, I'm a basketball fan, as I said, there in the, in the US, which is where I live, originally Canadian. Any Canadians in the room? Can I get a couple of who's? None. A one. A one. Amazing. Okay. Phew, there's always a couple secret Canadians lurking around so I just had to make sure. But yeah, there was the WNBA championships this week, and my team's New York Liberty, they lost a nail biter to Las Vegas Aces, who are the better team. But like Las Vegas, they had two injuries after the second game of two of their starters. And like, you know, as the team on the other side, like, that's always, you know, kind of disappointing, like, you know, if you want your competitors to be their best, and you know, you don't want to beat someone because they're, you know, having an off day, essentially.

Embracing Healthy Competition Dynamics

Short description:

Exploring the positive impact of healthy competition, idea sharing, and knowledge exchange in the JavaScript and react ecosystems.

So I think that that's, you know, the, the spirit of competition that like, I want to be a part of in the JavaScript and react ecosystems are like panels like this, you know, and not punching up or down or in any, any direction where you're like, trying to take away from what someone else has built. So I think, I think that things like this and meeting in person are just super productive. And like a great reminder that there are many, many, many other people that I think share in that idea of really productive competition in that sense of like, I want to bring out the best in you and I and by putting our ideas, you know, throwing them in the middle and kind of seeing what shakes out that that's how we're gonna get the best ideas in the end, you know? Yeah, that's how I think about it.

Oh, such great answers. I see it as academia, really, like, where maybe different universities compete about the same research, but it's mainly about sharing ideas. And it's mainly about the ideas competing and the best ideas winning if it is a competition. So it's not a competition between individuals. If it's the healthy kind of competition that is, it's a competition of ideas. And I think, like, that's what makes it so great to meet all of you and talk about all of these things. Because that's when the ideas can really clash and form something better. And you can inspire each other. And we share a lot of the same common problems as well.

So like, there's this form of competition where you're competing and withholding information from someone else because you want to win. Healthy competition, which is the kind I think we have is where we'd rather share these ideas and discuss them and make kind of all of our frameworks better in the in the process. So that's the healthy kind, I think. And I spent a lot of time reading discussion threads on Reddit and Twitter. And I see a lot of people fanboying the bad way. And saying, like, I love this tool. And anybody who likes this other tool is an awful person. And yes, there's kind of the competition in that if you choose to use React query to fetch data, you're probably not using Redux to do it. But that's okay.

Interactions with AI in Open Source

Short description:

Exploring knowledge sharing in open source, the impact of AI tools, and the challenges of utilizing AI safely in programming environments.

We are all taking inspiration and learning ideas from each other's tools and progress and pull requests. You know, the RTK query data fetching library that's part of Redux toolkit directly stole idea and drew inspiration from React query and Apollo. I've spent work this year trying to figure out how to properly set up packages for ES module compatibility. I published a blog post and you know Apollo and React query have learned from it. I contributed the changes over to Emmer. I even have a quote on the top of Emmer's documentation saying how wonderful it is. Like, there's a lot of knowledge sharing back and forth.

Yes, there's kind of the competition in that if you choose to use React query to fetch data, you're probably not using Redux to do it. But that's okay. We're all trying to build tools that solve problems in slightly different ways. And we are trying to make the best tools so that you can decide which one is the best fit for your situation. Love those. Oh, yeah. Round of applause for that. I love that. Well, I really want to speak about AI just a little bit. I just love it. I used to use copilot a lot. And now that I'm not using it, I'm like, oh, my goodness. This is going to be super tedious. But to those people who may be intimidated to break in, or not break in, but essentially contribute in an open source way, do you feel like AI and these tools have helped to encourage these people to contribute? Or what do you think the role of AI has been in terms of open source and maybe collaboration and things like that?

I haven't really considered AI and open source specifically. I did finally turn on copilot in VS code a few months ago. And I mean, my own personal perspective, I think that AI is and machine learning are potentially viable tools. My biggest concern is in a lot of ways it seems like you already have to know enough about the topic to use them safely. I've seen numerous cases where people pop in and ask questions and say, like, I'm trying to use a certain Redux API that was suggested by chat GPT, except it suggested something that literally does not exist. Or in one case, a person asked me about a blog post I'd written about fetching data in selectors, except that I never wrote the blog post. It's seen enough examples of my blog URLs to mimic it and suggest it, and it does not exist. And so I think especially a lot of beginners, they're learning great things from, you know, chat GPT and suggestions, but you sort of have to know enough to filter the suggestions yourself.

AI's Role in Open Source Exploration

Short description:

Exploring AI's potential in explaining complex open source projects, the impact of AI on technologies like GraphQL, and the future of AI in code generation and user interactions.

So my own experience, it's like, you know, copilot is great at filling in lists of code that I'm writing, or, like, some bits and pieces, but you do have to exercise some caution as you're using these things. I think my perspective is AI can be used for a lot of different things, right? There's the generative part where it writes your code for you, but I think where AI could shine when it comes to open source, if you want to contribute, is to explain this unfamiliar code base, because open source projects are often quite complex. The code looks a bit different from what you might be used to from applications. So using AI to explain and get into how an open source project functions could be a very, very good use case, I think.

Yeah, I also have not really deeply considered AI in the context of open source, although working on Apollo Client, which is a GraphQL client, you know, I do have some some colleagues who've been thinking about AI in the context of GraphQL, which I think is, you know, a whole separate panel and very interesting conversation. But yeah, a colleague of mine, Patrick, he has a talk, I believe it's up online now, from GraphQL Summit just about, you know, generating, like, schemas with AI and really just showing some sort of glimpses of the future and like proofs of concept. But certainly, I think certain technologies, in particular, like a query language, like GraphQL, there are, I think there will be some really interesting ways in which, you know, we will really be able to, you know, automatically turn sort of natural language commands into queries and really realize this idea of, like, the computer as a true, like, user agent. And so yeah, I think it's a, you know, fascinating topic overall, but I would encourage you to check out Patrick's talk. And, you know, if you're interested about that specific niche there.

Yeah, I didn't have a lot of thoughts about it either. I didn't think too much about it. The only thing I discovered is that like, there's one benefit to Brexit, and that's you have more AI services around here than in the EU. I don't really have much to add, I think. I really agree with the, it might be a helpful way to explore the code base. But yeah, other than that, well, GPT-4 is a lot better than GPT-3 here, for example, at, like, given, like, fake answers. I mean, not better. Yeah. Yeah. It gives fewer fake answers. But yeah, I don't know. We'll see. We'll see how it goes. I guess, like, one distinction is, like, I think it's interesting to think about, like, open source is usually, like, shared foundations. But then I feel like the place where, like, AI kind of shines more right now is, like, built on top of those. So like, you know, it's easy to, like, generate React components, but maybe not, like, write React itself. So I don't know if it will make its way to, like, being useful in the kind of lower levels where you have to have this precision. Whereas, like, at higher levels, when you just, like, compose things together, that seems like the, you know, the most comfortable, like, place to apply AI right now. Thank you. It's so interesting the way that AI is just, like, revolutionizing the way that we work. I wouldn't go as far as to say we're all gonna lose our jobs tomorrow.

Diverse Contributions in Open Source

Short description:

Exploring non-code contributions in open source, emphasizing documentation, testing, issue reproduction, and diverse problem-solving approaches.

But I will say that it's definitely helping, but it's not totally accurate, as we're speaking about. And one thing I want to end on is the fact that open source extends beyond code. And there's other ways that we can contribute in terms of non-code. Can you all just give examples for the last, like, what, two minutes of ways that people can contribute when it doesn't come to coding and good examples that you may have? Like I said, I got my start with Redux by offering to contribute a docs page. And every project needs more documentation. And sometimes you contribute, you can contribute to the docs without needing to have a deep understanding of the code. Docs contributions are always, always welcome.

Yeah, I agree. And I got started with Redux by writing the server-side rendering tests that were missing. So writing tests is also a good, good contribution. Even if you don't want to contribute code that runs in someone else's browser, you know. Also, as we talked about previously, issues and good reproductions are invaluable. I want to really push that point. They help so, so much. Yeah. Yeah, plus one on reproductions. In addition to, yeah, I'm just going to pile on sort of the answers that came before. They're all so important. But definitely, you know, if you're researching something based on an issue you're facing, and you're in the GitHub issues, and you have a few minutes to spare and see, you know, a question hanging out that, you know, is where you have the answer at your fingertips, or you have the ability to help create that reproduction or, you know, just move the conversation along in a really positive way. That is super, super appreciated as well.

Yeah. One thing I think about is competition between things can often be seen as like, or people perceive it as like maybe one solution is smarter or modern or faster or whatever than the other. But that's usually not where competing projects come from. Usually they come from trying to solve different problems. But those are often not very like explicit, or they're like hard to really well communicate what kind of set of problems one solution is trying to solve. And that's usually where the difference is. So if you have like, a good angle on that, or you feel like this solution worked really well in these circumstances, that's like super valuable for the community to be able to share that. Because like, often your view on that is even better than the maintainers view they have on such a thing. I think whatever gets you excited. Like, if you know, want to make like a library faster, that's like one thing you want to write a bit of docs, another thing, you can just like help people in issues or on Twitter or whatever. So whatever you feel like you want to do. Perfect timing. Well, thank you so much for those answers and your insights. And can we get a round of applause please?

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

A Guide to React Rendering Behavior
React Advanced 2022React Advanced 2022
25 min
A Guide to React Rendering Behavior
Top Content
This transcription provides a brief guide to React rendering behavior. It explains the process of rendering, comparing new and old elements, and the importance of pure rendering without side effects. It also covers topics such as batching and double rendering, optimizing rendering and using context and Redux in React. Overall, it offers valuable insights for developers looking to understand and optimize React rendering.
Building Better Websites with Remix
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a web framework built on React Router that focuses on web fundamentals, accessibility, performance, and flexibility. It delivers real HTML and SEO benefits, and allows for automatic updating of meta tags and styles. It provides features like login functionality, session management, and error handling. Remix is a server-rendered framework that can enhance sites with JavaScript but doesn't require it for basic functionality. It aims to create quality HTML-driven documents and is flexible for use with different web technologies and stacks.
React Compiler - Understanding Idiomatic React (React Forget)
React Advanced 2023React Advanced 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
Top Content
Watch video: React Compiler - Understanding Idiomatic React (React Forget)
Joe Savona
Mofei Zhang
2 authors
The Talk discusses React Forget, a compiler built at Meta that aims to optimize client-side React development. It explores the use of memoization to improve performance and the vision of Forget to automatically determine dependencies at build time. Forget is named with an F-word pun and has the potential to optimize server builds and enable dead code elimination. The team plans to make Forget open-source and is focused on ensuring its quality before release.
Using useEffect Effectively
React Advanced 2022React Advanced 2022
30 min
Using useEffect Effectively
Top Content
Today's Talk explores the use of the useEffect hook in React development, covering topics such as fetching data, handling race conditions and cleanup, and optimizing performance. It also discusses the correct use of useEffect in React 18, the distinction between Activity Effects and Action Effects, and the potential misuse of useEffect. The Talk highlights the benefits of using useQuery or SWR for data fetching, the problems with using useEffect for initializing global singletons, and the use of state machines for handling effects. The speaker also recommends exploring the beta React docs and using tools like the stately.ai editor for visualizing state machines.
Routing in React 18 and Beyond
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Routing in React 18 brings a native app-like user experience and allows applications to transition between different environments. React Router and Next.js have different approaches to routing, with React Router using component-based routing and Next.js using file system-based routing. React server components provide the primitives to address the disadvantages of multipage applications while maintaining the same user experience. Improving navigation and routing in React involves including loading UI, pre-rendering parts of the screen, and using server components for more performant experiences. Next.js and Remix are moving towards a converging solution by combining component-based routing with file system routing.
React Concurrency, Explained
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
Top Content
Watch video: React Concurrency, Explained
React 18's concurrent rendering, specifically the useTransition hook, optimizes app performance by allowing non-urgent updates to be processed without freezing the UI. However, there are drawbacks such as longer processing time for non-urgent updates and increased CPU usage. The useTransition hook works similarly to throttling or bouncing, making it useful for addressing performance issues caused by multiple small components. Libraries like React Query may require the use of alternative APIs to handle urgent and non-urgent updates effectively.

Workshops on related topic

React Performance Debugging Masterclass
React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Top Content
Featured Workshop
Ivan Akulov
Ivan Akulov
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 🤐)
Next.js for React.js Developers
React Day Berlin 2023React Day Berlin 2023
157 min
Next.js for React.js Developers
Top Content
Featured WorkshopFree
Adrian Hajdin
Adrian Hajdin
In this advanced Next.js workshop, we will delve into key concepts and techniques that empower React.js developers to harness the full potential of Next.js. We will explore advanced topics and hands-on practices, equipping you with the skills needed to build high-performance web applications and make informed architectural decisions.
By the end of this workshop, you will be able to:1. Understand the benefits of React Server Components and their role in building interactive, server-rendered React applications.2. Differentiate between Edge and Node.js runtime in Next.js and know when to use each based on your project's requirements.3. Explore advanced Server-Side Rendering (SSR) techniques, including streaming, parallel vs. sequential fetching, and data synchronization.4. Implement caching strategies for enhanced performance and reduced server load in Next.js applications.5. Utilize React Actions to handle complex server mutation.6. Optimize your Next.js applications for SEO, social sharing, and overall performance to improve discoverability and user engagement.
Concurrent Rendering Adventures in React 18
React Advanced 2021React Advanced 2021
132 min
Concurrent Rendering Adventures in React 18
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
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 Hooks Tips Only the Pros Know
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
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.
Introducing FlashList: Let's build a performant React Native list all together
React Advanced 2022React Advanced 2022
81 min
Introducing FlashList: Let's build a performant React Native list all together
Top Content
Featured Workshop
David Cortés Fulla
Marek Fořt
Talha Naqvi
3 authors
In this workshop you’ll learn why we created FlashList at Shopify and how you can use it in your code today. We will show you how to take a list that is not performant in FlatList and make it performant using FlashList with minimum effort. We will use tools like Flipper, our own benchmarking code, and teach you how the FlashList API can cover more complex use cases and still keep a top-notch performance.You will know:- Quick presentation about what FlashList, why we built, etc.- Migrating from FlatList to FlashList- Teaching how to write a performant list- Utilizing the tools provided by FlashList library (mainly the useBenchmark hook)- Using the Flipper plugins (flame graph, our lists profiler, UI & JS FPS profiler, etc.)- Optimizing performance of FlashList by using more advanced props like `getType`- 5-6 sample tasks where we’ll uncover and fix issues together- Q&A with Shopify team
React, TypeScript, and TDD
React Advanced 2021React Advanced 2021
174 min
React, TypeScript, and TDD
Top Content
Featured Workshop
Paul Everitt
Paul Everitt
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.