Don't Solve Problems, Eliminate Them

Rate this content

Humans are natural problem solvers and we're good enough at it that we've survived over the centuries and become the dominant species of the planet. Because we're so good at it, we sometimes become problem seekers too–looking for problems we can solve. Those who most successfully accomplish their goals are the problem eliminators. Let's talk about the distinction between solving and eliminating problems with examples from inside and outside the coding world.

39 min
22 Oct, 2021

Video Summary and Transcription

Kent C. Dodds discusses the concept of problem elimination rather than just problem-solving. He introduces the idea of a problem tree and the importance of avoiding creating solutions prematurely. Kent uses examples like Tesla's electric engine and Remix framework to illustrate the benefits of problem elimination. He emphasizes the value of trade-offs and taking the easier path, as well as the need to constantly re-evaluate and change approaches to eliminate problems.

Available in Español

1. Introduction and Wake-up Exercise

Short description:

Hello, everyone. I'm Kent C. Dodds, a software engineer, and today I'll talk about how we can eliminate problems instead of just solving them. But first, let's wake up and do some exercises together. Stand up, put your arms out, squat down, and come back up. Let's do 12 reps and stretch afterward.

Hello, everyone. Yes! My name is Kent C. Dodds, and I'm a software engineer, and I'm going to talk about how we should avoid solving problems and instead try to eliminate them.

But before we do that, I'd like to have everybody wake up. So please stand. We just had lunch. Your body is like, oh, it's time to sleep. No, it's not. It's time to stand up. Stand up. Come on, come on. Put your arms out in front of you like this and squat down and come back up. This is exercise, you know. We didn't have to do that when we were locked in our rooms.

So we're going to do 12 of these together, and I want you to count out loud. Ready? One, two. You're not counting. Three. There you go. Four. Five. Six. This is so great. Seven. Your legs are like, what are you doing? Nine. Ten. Is that 11? Should we start over? 12. No, just kidding. Stretch up as high as you can and stretch over and to the other side. All right.

2. Introduction and Site Relaunch

Short description:

Now, before you sit down, just introduce yourself to the person next to you and thank them for coming. I rewrote my site and relaunched it recently. When I was building is when I started thinking about how we want to eliminate problems rather than solve them. This talk is about problems, solutions, and trade-offs. It's not about code necessarily. It's more about life in general and problems.

Now, before you sit down, just introduce yourself to the person next to you and thank them for coming. And if you're online, you can talk to your cat. Thank you. For that.

Okay. First I just want to mention that I rewrote my site and relaunched it recently and it's really great and I want you to take a look. And in fact, I've even got the logs running right over here. So if you want to make these logs go nuts, go to right now and we'll see like crazy stuff. Please. No? All right. Fine. I have a little bug in the server, so that's good. Yeah, there we go. That's what I'm talking about.

So when I was building is when I started thinking about how we want to eliminate problems rather than solve them. And I'll get to that a little bit toward the end. So that's where the idea for this talk came from. My clicker's not working. It's mine. It's not theirs. It's my fault. So I will just use the keyboard.

So what this talk is, I'm going to talks about problems, solutions, and trade-offs and how solving is great, eliminating is better, and avoiding is even better if you can manage it. I'm not going to be giving code examples. This isn't a live coding thing. As much as I enjoy those talks, yeah, in fact, it's not even about code necessarily. It's more about life in general and problems. And yeah, not domain-specific. So I know that we're at a React conference, but this doesn't have a ton to do with React except toward the end where we try to apply it. So this is a problem tree.

3. Problem Tree and Simplification

Short description:

The blue icon represents the core problem you're trying to solve. Each node represents a solution, but sometimes solutions lead to more problems. Eventually, we reach a terminal solution with no more problems to solve. This is a simplified version of a problem tree that we'll reference throughout this talk.

You're not supposed to be able to see what's inside of those little squares. But the blue icon right here represents the core problem that you're trying to solve. So whatever the mission of your company is, that's what this core problem is. Or what the core goal is. And off of that, we have different problems that we need to deal with. And each one of those extra nodes is another solution. And sometimes the solutions that we develop lead to more problems. And so eventually we get to the terminal solution that doesn't have any problems that we care to solve. And these are way bigger in real life. If you were to try to map out all of the problems that your company has, or whatever it is in life, then yeah. You would have many. So here's a simplified version of a problem tree. And we're going to be referencing this a couple of times throughout this talk.

4. Problem Solving and Avoidance

Short description:

It's important to acknowledge that you are a problem solver. We often become problem seekers, looking for problems to solve. When the pandemic hit, my sister asked me to build an app to solve a problem for professional musicians. I suggested manually working through the tools instead of automating everything. It's easier to solve a problem when you know what the problem is. Avoid creating solutions prematurely. Elon Musk said it's better to avoid problems than to solve them.

So first off, I think that it's important to acknowledge that you are a problem solver. That's part of why humanity is the dominant species on the planet, because we solve problems and we have, I guess, dominated the planet. But we're so good at it that we also become problem seekers. Where we're looking for problems to solve. And this, I have a bit of a story about this. And maybe you can relate to this.

So when the pandemic hit, my sister, who's a very accomplished violinist, saw all of her professional musician friends totally out of work, and they weren't sure what to do. And so she came to me and said, hey, can you build me an app that can help solve this problem? And I won't go into the details of it. But she basically needed me to build a Google calendar and Zoom in a single integrated thing. Not integrate those, but build them all. We always underestimate the amount of work these things will take. And she said she'd done tons of market research and looked at what solutions were out there and everything, and she felt like she was willing to hire somebody to work on this problem. And I told her, you know, like, maybe you need to actually just manually work through these tools and be the one facilitating what you're trying to do here, and she said, no, I just want to automate all of this stuff and scale it and everything. And I just said I just don't know. And so ultimately what she ended up doing was nothing. She decided she didn't want to invest into it. And I think that was a wise decision. One thing that I have learned is I've been living, I guess, is that it's way easier to solve a problem when you know what the problem is. And we kind of assume that we understand what the problem is on the outset, and so, like, we assume that we're going to need a ticketing system and we're going to need a calendaring system and a video chat thing, and we have all these assumptions. And maybe you do, but you don't know all the intricacies of what features those different things are going to need. And so, I suggest that you first feel the pain of the manual solution and then you solve those pains as they come. And so, problem avoidance is this. You avoid solving or avoid the problem all together by not creating the solution prematurely. And Elon Musk recently had an interview and I just really love this quote. He said, possibly the most common error of a smart engineer is to optimize the thing that should not exist. And I thought he was talking about me. So, it's better to avoid problems than to solve them. So, here's our problem tree again. If we're avoiding a problem, let's say that we want to avoid the problem in solution 1B here. And we just decide we're not going to solve it.

5. Problem Avoidance and Re-evaluation

Short description:

That's what problem avoidance is. Often we get down in this problem tree and we get down to like one node. And we're working on this solution right here. And it is a beast of a solution. Like this problem right here is just super duper difficult. And as we're working through this solution, we're like, man, this is hard. And sometimes you might even say to yourself, if I'd known it was gonna be this hard, I never would've done it. Do we really need to solve this problem at all? Maybe this whole thing doesn't need to exist either. Re-evaluating our problem tree can save you a great deal of time and ultimately be better for your users. It's totally cool to just say, you know what? We're not gonna solve that problem, because we have other things to deal with right now. Problem avoidance is fantastic. I recommend it if you can avoid problems, but sometimes you can't avoid the problem, so in this situation, before you try to solve the problem, see if you can eliminate it.

That's what problem avoidance is. You don't solve it. And here's the takeaway that I want you to come away from this talk. Often we get down in this problem tree and we get down to like one node. And we're working on this solution right here. And it is a beast of a solution. Like this problem right here is just super duper difficult. And as we're working through this solution, we're like, man, this is hard. And sometimes you might even say to yourself, if I'd known it was gonna be this hard, I never would've done it.

And so, that's the moment where you think, you know, do we really need to solve this problem at all? And often, you do. Like you're absolutely... This whole thing doesn't even work if we don't solve this problem. But maybe this whole thing doesn't need to exist either. And so, you can go up in the problem tree until you get to one solution that you're like, you know what? We don't actually need that. So, the users don't even use this feature very much. So, like, we can just get rid of this feature altogether. If I'd known how expensive it would be to solve this problem, I never would've added this feature in the first place.

So, re-evaluating our problem tree can save you a great deal of time and ultimately be better for your users, because every minute of every day that you spend, or, like, everything that you can do has the same currency, and that's your time. And every minute that you spend doing one thing is a minute that you can't spend doing another. And so, it's totally cool to just say, you know what? We're not gonna solve that problem, because we have other things to deal with right now. This is why I tell people that, hey, like, I don't test everything that I write. Lots of people think of me as a testing guy, like, 100% code coverage and test-driven development. That is not me. I see testing as a mechanism for automating code quality and confidence, but that's not the only thing that I'm doing. The code doesn't exist for itself, so you have to be practical about the sorts of things that you spend your time on. Problem avoidance is fantastic. I recommend it if you can avoid problems, but sometimes the house is on the cliff, I guess? I don't know how this happened, but I'm glad somebody was there to take a picture at least and maybe they dropped their camera and went and helped. I don't know, but sometimes you can't avoid the problem, so in this situation, before you try to solve the problem, see if you can eliminate it. I don't know, blow up the house. This is a bad metaphor, I guess.

6. Eliminating Problems: Tesla's Solution

Short description:

Solutions hold you captive to their maintenance forever. Internal combustion engines have solved some problems but not exhaust, brake pads, car fires, and sustainability. Tesla's electric engine has eliminated exhaust and reduced the impact of brake pads. Electric cars are also less likely to catch fire compared to internal combustion engines.

So here's the reason. Solutions hold you captive to their maintenance forever. And I'll give one example in the real world. So here's an internal combustion engine, and there are a lot of problems that we've faced over 100 years that we've been working on internal combustion engines that have been solved in remarkable ways. So first off, we have exhaust. When you burn gas, there's exhaust, and that exhaust is not good for our lungs, and so we don't want it coming into the cabin, so we have all this piping going to shoot it into the back of the vehicle where certainly it will do no harm. That was sarcasm. So that's as far as we've gone on solving that problem. Stopping also, we have brake pads, they squeeze the disc brakes, or the discs, and we can stop the vehicle. And that's worked, except we also, those disc brakes don't just magically disappear and you have to replace them, right? That rubber is going into the air and we're all breathing it, but that's as far as we've gone to solving that problem. Cars will actually catch fire, like that's amazing that when you're literally burning stuff and exploding things to make you move that maybe it'll actually catch fire. But they've put a lot of work into avoiding this problem or kind of trying to solve this problem as much as possible. And then sustainability, well, this is the problem that we just decided we will not solve with internal combustion engines. It is not possible to make this sustainable. So what if we look at our problem tree and we say, you know what, this sustainability problem or the car fires or whatever else, this is just a really difficult problem to solve. Let's go up the problem tree and get all the way back up to mobility. Now of course you can ride bikes and you can jump on the subway or whatever, but at some point people need to have individual mobility. So how are we going to solve that problem? What if we totally changed the approach altogether? And this is the Tesla electric engine, this is the engine that powers the fastest mass production car in the world, the Tesla Model S. And here are the problems that they've pretty much eliminated. Exhaust is absolutely eliminated. There's no exhaust. Now people talk about the long tail pipe, but the fact is that eventually all of us are going to be powered off of sustainable energy so that long tail pipe is cut off. We have no exhaust problem, period. I do have a Tesla and my home is solar powered so I'm driving on sunshine and it's awesome. When we got the system turned on just last week, I started driving my car and singing, I'm driving on sunshine. It's just like, so, so, such a great victory. And then stopping, the cool thing about electric is that you can actually turn that kinetic energy into actual electrons and stick it back in the battery and so yes, while we do still have brake pads on electric vehicles, we probably never actually need to replace them because most of that energy is going back into the battery and so we haven't eliminated that problem altogether but we've drastically reduced the impact of that problem. So that's super awesome. Car fires, as far as, I know that like electric car fires get in the news a lot but as far as the data is concerned, you're 11 times less likely to have your car catch fire if it's a Tesla model or yeah, a Tesla. I don't know about the other manufacturers but the data I have seen is a Tesla.

7. Sustainability and Tesla Case Study

Short description:

Sustainability is the ultimate reason for making changes. By reevaluating and changing our approach, we can create a smaller problem tree. Tesla's case study showcases the benefits of problem elimination.

That's pretty significant. And then sustainability, ultimately we can make this sustainable and that's like that should be the only reason that we do this. If if all the other things were fine, this is reason enough for us to make this change. And so like by going up the problem tree a little bit and saying, hey what if we don't actually need to solve this or what if this is too hard of a problem to solve and we go back up the problem tree a little bit and say, hey what if we change our approach, and now we have a new solution, so we haven't eliminated it, we haven't decided we're not going to solve this problem of personal mobility, we're just going to change it so that we have a smaller problem tree. Now certainly there are many problems with electric vehicles as well, but the problem tree is smaller and the problems are smaller and that's why this elimination is so great. Tesla is actually a really great case study for problem elimination so if you ever want to see the amazing things they're doing with manufacturing, it's really phenomenal, very interesting.

8. React Components and Code Reuse

Short description:

In React, class components had problems with code reuse due to concerns spread across multiple life cycle hooks. Higher-order components and render props were attempted but had issues with composition. Hooks came along and co-located all concerns into a single snippet of code, enabling easy code reuse. This drastically reduced the amount of teaching needed for React components patterns workshops.

Okay, so let's talk about software now. In software, we have some examples, particularly in React, of problem elimination. So how many of you all have written class React components? Any React Create Class folks out there? Got a handful of you. Yeah, that was fun. Yeah, and then we got class components. And this screenshot here comes from Amelia Weittenberg's React hooks blog post which is very good. I recommend you take a look at it. But one of the big problems that we had with class components was code reuse. And you would have a single concern in your class component that would be spread between these three life-cycles. You would have your componentDidMount, componentDidUpdate, componentWillUnmount. If you wanted to subscribe to Firebase or you wanted to update the document title, you had to spread all of this stuff up in your component. And so reusing that was a little tricky. Did we use a higher-order component so that we could make a component that does all that stuff, and then we just pass our component to that so that we can accept that as props? Well, there were a lot of problems with that. You had namespacing issues, it was very difficult to type, and so we started doing render props. And those were fun. Really powerful. But then we have, like, these giant trees, or a pyramid of doom, trying to get all of these things composed. They just didn't compose very well. And so it worked, and it wasn't bad. Like I lived through that, and it was a good time. I had a lot of fun with that. But wouldn't it be great if we just didn't have the problem in the first place? So hooks came around and co-located all of the concern into a single bit of code. So it could be like a use date and use effect and a couple other things in there. But it could all be in this same snippet of code. So what do you do when you want to reuse code? You can create a function out of it, and you couldn't do that with our cost components because the concern was spread through multiple life cycle hooks. But with these hooks, you can just take that and stick it into another function. That was brilliant. It made an enormous impact on the ability for us to reuse code. It drastically reduced the amount of stuff I need to teach in my React components patterns workshop. Things became so much easier when we just went up the problem tree, decided, hey, what if we did things differently and then went down that direction.

9. Introduction to Remix

Short description:

Now, there are problems with making those sorts of migrations. I'm really grateful to the React team for creating hooks. It's made my job a lot easier. Remix is the reason that I started thinking about problem elimination. Remix has nested routing, which allows for awesome optimizations. It also provides seamless client and server interaction, eliminating the need for tools like React Query. Additionally, Remix is based on the web, allowing for easy transferability and compatibility with web APIs.

Now, there are problems with making those sorts of migrations. We all felt the pain of having to move over to classes and, like, should we even bother all that? By the end of it all, we're much better off. And I'm really grateful to the React team for creating hooks. It's made my job a lot easier.

So now it's my favorite part, and I want to talk to you about Remix. How many of you have heard of Remix? How many of you who are raising your hands heard of it because I tweet about it nonstop? Yeah, so most of you. So yeah, I tweet about Remix nonstop because I love it. So full disclosure because people always want that. There has been a transaction between me and the Remix team, so I had to pay them money to access Remix. But that is not going to be the case. They say in a few weeks, Remix will be open source completely and free, and so you will be able to use Remix as well. So let me sufficiently hype you up about this. I don't have a ton of time to go through everything, but I want to just give you a high level because Remix is the reason that I started thinking about problem elimination in the first place.

So the first thing that Remix does that just makes it phenomenal is nested routing. One nice thing about this is you no longer have like a route that's like slash users, slash IDs, slash contacts or something. Now you have in that route file, whatever framework you're using, you probably have to render your layout route. And that will include your header and footer and everything. With Remix, you have nest routing. So each one of those is going to just be the component that cares about the part of the route that this part of the route URL cares about. That's really nice. But to take it even further, that's just like a nice developer experience sort of thing. But because of nested routing, Remix can do a lot of awesome optimizations as far as loading your data and validating the cache and loading the right data so it doesn't load more unnecessarily. That's a really cool thing, because Remix has nested routing built in.

Another thing that I love about Remix is the seamless client and server interaction. Just like Next has the Git server side props, you've also got a loader with Remix. But Remix does a really great job of making that connection very seamless, as I say here. So you've got a can be fully typed. You can go make all of your requests to database or GraphQL or whatever it is, and then all of that data is just available in your component and they have really nice declarative error handling and so as far as your component is concerned, the data is there and you never have to even worry about error states or loading states, because all of that is declaratively handled for you, so by the time it gets to your component, you just you don't use use use effect, maybe that's all I need to say, like whoo! Yeah, I don't use effect, all right, and you don't need a tool like React query, if you're not using remix, you should use React query, but if you are using remix, you don't need it because React query solves a big and awesome problem, thank you, tanner, for creating it and those who are maintaining it now, but wouldn't it be great if we didn't have the problem to begin with, and that's what remix gives us with its awesome client-server interaction.

The other thing I love about remix is that it's based on the web, so everything is fetch API stuff, even on the server, you have a request and a response, and if you need to learn something about that, you're not going to the remix docs, you're going to MDN to learn about how the web APIs work for that. And aside from the transferability of knowledge, you also get the fact that, because they're the web APIs, we can run this in a Cloudflare worker, or in a service worker, and Cloudflare workers are currently supported, service workers eventually, they'll support that.

10. Remix: Opportunities, Mutations, and CSS

Short description:

Remix simplifies coding by allowing you to work with a familiar web-based environment. It handles requests and mutations seamlessly, even when JavaScript fails to load. CSS management in Remix is straightforward, with each route defining its own link tags, eliminating the risk of unintended impacts on other pages.

And so just nailing that abstraction has opened a lot of really awesome opportunities with remix. And what's cool is that you don't really have to change any of your code. Now if you're going to work in certain environments, some of them like serverless, you can't connect to have a long connection to a database or something, but as far as the remix-specific code, none of that needs to change because it's all based on the web and remix smooths out everything for you. It's kind of like jQuery for the server. I've never said that before, but, yeah, kind of like that.

Other thing I love about remix is it's simple mutation. So all mutations in remix you have a form, so even like your delete button, the way we do this is we have the little trash icon. We have an on click handler that will do the request, to delete the item. With remix you use a very declarative here's my form, here's the delete icon, and you click that, that submits the form, and then remix takes care of all of making the request and what if I make another request and we're loading data and remix will cancel the right one, make sure everything is loading in order. Even if JavaScript fails to load, which that does happen sometimes, most people don't disable JavaScript but failing to load JavaScript does happen, or JavaScript that takes a while to load, which that happens even more, all of your mutations still work because you're using regular forms and they're doing regular posts or regular deletes and you'll end up with a full page refresh so it's not as awesome of an experience. But this is what we call progressive enhancement. And so your app still works even without JavaScript and it doesn't take a great deal of effort to make that happen, because it's just the way that it works.

And then also I just love the CSS story with Remix. Here's the big secret about how CSS works with Remix. It blows my mind how simple this is. So to get CSS on the page, you have a link tag and you point to the style sheet. All of us, we're using Webpack and bundling it all, or using styled components and having it part of our components, and it's really nice to have that co-location or whatever it is. But in every app that I've ever used, if you've got regular CSS, it's all going to be bundled and it's going to be available on every page. In Remix, each route can define the link tags that it wants to have active when that route is active, or wants to have on the page when the route is active. And when you navigate away from that page, then those link tags are removed. And so if I want to have some special CSS that's applied to only this particular route, then I can say, hey, here's the link tag for that. And I say, here's the CSS file that I want on this route. And when I navigate away, Remix removes the link tag. And that's it. That's the whole secret. But here's why it's so cool. It's because that when I'm in that CSS file, I know exactly which routes that CSS file is going to impact. And so normally at any other company that I've worked at, any other significant project that I've been at, any CSS file you were working in, or SaaS or whatever, you just knew that this CSS would apply to every single page. And so you were always worried about removing something, because something might break. You're developing, of course, you're looking at what's happening here.

11. CSS and Problem Elimination

Short description:

With Remix, you can make changes to CSS on a single route without worrying about impacting other pages. It eliminates the problem of unexpected CSS clashes, making CSS development predictable. Remix simplifies the process by allowing one-off CSS for specific routes without the need for additional tools. There's much more to learn about Remix, but due to time constraints, I'll wrap it up here. Problem elimination involves trading big problems for smaller ones, and Hooks exemplify this approach. The React team took a different approach to solve code-sharing problems, and it worked.

And so you're worried that you might break something that you're not looking at. But with remix, you know exactly which pages this is going to be active on. And so you know exactly which ones to look at. And in practical terms, it's normally just on a single route. And so as you're developing it, you can make any change you want to the CSS, you look at the page, and if it looks the way that you want, then you know that your CSS file is good. And you don't have to worry about it impacting other pages on the rest of the app.

This is another great example of problem elimination. Eliminated the problem of unexpected CSS clashes. It's just phenomenal. All of the work that we've been doing for all of these years to try to make CSS easier for us to use, especially as React developers, with CSS and JS and CSS modules and everything in between has been to help us avoid CSS clashes and remix doesn't completely eliminate the problem. But it makes it predictable, and I love that about remix. Side note, just skip to the end and use tailwind for everything cause it's amazing. But it's really nice to know if I wanted some one-off CSS that I could add it to the single route and not worry about it impacting any other page. And I don't need any runtime or any funny extra build tools or anything. It's all just it just works and it's the web. It's fantastic.

There's so many more things I want to tell you about remix, but I just don't have the time so we're gonna wrap this up. And actually if you do want to know more about remix, I am more than happy to talk your ear off for the rest of the conference about it, and I've got a billion stickers that I got myself. So again, remix is not paying me for any of this stuff. I asked them, can I print stickers? They're like we can't send you stickers. I'll buy them myself. Because I am so jazzed about this framework. So a lot of you might be thinking, well, problem elimination sounds like choosing trade-offs. And yeah, that's what it is. That's what problem elimination is. So the idea behind problem elimination is to eliminate big problems in exchange for smaller ones. And the reason why this is talk-worthy for me is that I don't know about you, but when I'm involved in a problem, I am not thinking about whether or not that problem needs to be solved or if I can go back up the problem tree and rethink the problem back at the top. That's why Hooks was so phenomenally awesome was because we're all working, how can we solve this code-sharing problem down at the bottom of the problem tree? And the React team just went up a couple of levels and said, hey, you know what? Maybe we could just take a completely different approach. And it worked. Right? We all love it.

12. Conclusion and Cody the Koala

Short description:

Solving problems is great, but eliminating problems is even better. Find tradeoffs and take the easier path. If you can't avoid a problem, try to eliminate it by changing your approach. Before I wrap up, let me introduce Cody, the koala. You can get your own at Epic Thank you all for being here.

Most of us do. I do. So in conclusion, solving problems is great. Please keep solving problems. There's so many problems in the world, and I want to see you all being problem solvers. Eliminating problems is even better. Find different tradeoffs and take the thing that's easier. Avoiding problems is even better. So if you can't avoid the problem, then try to eliminate it by changing your approach, and only if that fails, then solve that problem.

One last thing before I go to my last slide, I forgot to introduce you all to Cody the So this is Cody, and that's people often ask me what's with the koala? So when people ask me that, I know they haven't been to my workshops, because Cody helps you go through my workshops, all the workshop material. So anyway, I felt bad having this random koala next to me, and I forgot to introduce him. So that's Cody. You can actually get your own stored at Epic and get your own, and it's adorable. Kids love it.

Thank you all very much. Thank you. Thank you, Mr. Kent C Dodds. Hot seat, please. Oh yes. Oh yes. We've got a lot to talk about. Only solutions though. No problems. Well, actually, one of our first questions was what's the story with the koala? So I guess we solved that. Oh, there you go, yeah. That's Cody. I didn't know you had a merch shop. Yeah. It's very exciting.

13. Merchandise and Comfortable Jacket

Short description:

They have shirts and jackets, including the most comfortable jacket I've ever worn. I got a similar jacket at React Rally and loved it so much that I added it to my merch store. It's soft, super comfortable, and definitely worth checking out.

So they've got shirts and jackets, the most comfortable jacket that I've ever worn. In fact, quick story on the jacket, I got a jacket like it at React Rally a few years ago, and I tore it up really bad when I crashed on my one wheel. Like the entire shoulder was just ripped up. And I was so sad that I found – I asked the conference organizers where they got the jacket and I found the company, and I created it on my merch store so I could buy it. That's why it's on the merch store. Because I like the jacket so much. It's soft. It's super comfortable. We're going to have to check that out. Do you know if it ships to London? Yeah. I'm not sure how much it costs, but it's probably too much. You heard it here first, folks.


Remix Workshops and Sunk Cost Fallacy

Short description:

Adil asks about upcoming remix workshops. Kent has two workshops scheduled and a TypeScript with React workshop coming up. Mac asks about the sunk cost fallacy and when it's too late to eliminate a problem. Kent explains that it's never too late and advises evaluating the current situation and the benefits of solving the problem versus changing the approach.

Sorry. All right. Adil asks, any remix workshops coming? Oh yeah. In fact, if you go to slash workshops, you'll find I have two scheduled already, as well as a TypeScript with React workshop coming up. Incredible. Yeah. Fun stuff. All I'm going to be talking about for the next I don't know how long is remix. I'm going to teach you all how great remix is. Mac asks, how do you approach the sunk cost fallacy? At what stage would you say it's too late to eliminate the problem you're working on? I mean, it's never too late unless like the sunk cost fallacy is basically, oh we've sunk so much into this, we can't quit now, whatever. But if you just evaluate it right now as it is, the work I need to do to solve the problem and the benefit I get from that and the work I need to do to change my approach and the benefit I get from that, you just do the cost benefit analysis of that. Yeah. I wouldn't say that it's ever too late to solve a problem. It's just like, how are things now and let's go with the better direction. That makes sense.

Leveraging the Unknown and Manual Evaluation

Short description:

When you eliminate a problem, how do you leverage the unknown? That's kind of my story with my sister, who is trying to solve the problem for musicians who are out of work. Do it manually first and evaluate as you go. If it's not worthwhile, don't go forward.

When you eliminate a problem, how do you leverage the unknown? You don't know the problems you're going to face down the other path. Yeah. That's actually great. That's kind of my story with my sister, who is trying to solve the problem for musicians who are out of work. And this is where I say, do it manually first. Like, just go on forward and then just make sure that you're evaluating as you go and you realize, you know what, if I had known this, I never would have done it and I don't feel like it's worthwhile going forward, or whatever. That's good advice.

Remix and Microfrontends

Short description:

Remix is a new framework that is highly abstractable and has the potential to work well with microfrontend approaches. While I don't have experience with microfrontends, I believe Remix can be integrated effectively. My website, which is the largest Remix deployment, consists of 27,000 lines of code, highlighting its popularity and potential.

A little bit related to our previous speakers, from our last slot, how does Remix play with microfrontend approaches? So Remix is pretty new, so it's hard to say. And I have basically no experience with microfrontends in a practical sense, so I can't actually answer. But Remix in general is very abstractable. That's one of the things I like about it. So I am guessing it would actually be quite possible to make it play nicely, but nobody has done it yet. My website is literally the biggest deployment of Remix, and it's not small, but it's 27,000 lines of code, and it's the biggest one, so it's still pretty new. Kind of a popular one in a nutshell.

Remix: Framework Overview

Short description:

Remix is a framework that helps you build better websites. It's based on React and leverages your existing knowledge of web development. You can bring all the nice things you've learned about the web platform to Remix, and it will teach you more. While you may not use React Query with Remix, it's not because of a different approach or API, but because Remix doesn't require an additional API to learn.

What is Remix? Remix is a framework to help you build better websites. It's comparable to Next. Server rendered. Do you think Remix will get rid of everything we learned so far? React, query, etc? Well, not everything. One of the things I love about React in particular, and Remix uses React to be clear, but one of the things I love about React in particular is that the better you get at React, the better you get at JavaScript. Yeah, I love that coming from other frameworks. With Remix, one of the things I love is that the better I get at Remix, the better I get at web development. Because it's based so much on the web platform. And so I think that all of the nice things that you've learned about the web platform with whatever framework you've been using, you bring all of that with you to Remix. And Remix will teach you more. Any of the other things... Yeah, you're not going to probably be using React Query with Remix. You could. There are potentially use cases for it. So yeah, any React Query specific thing that you know, that won't carry over, but it's not because you... There's a different approach or a different API you need to learn. It's because there is no API that you need to learn. And that's even better.

Comparing Remix to Next, Recoil, and Gatsby

Short description:

There are questions about comparing Remix to Next and Recoil. Next is not used together with Remix in a finished app. Recoil can be used with Remix for specific problems. For CRUD applications, Remix's server cache management and context work well. Gatsby also has server rendering capabilities, but Remix offers a different approach and better user experience.

There's a couple of questions about comparing Remix to different things, like Next or Recoil. Do you have any rough thoughts on that? Yeah. So Next compares most of that. In an app that's like quote-unquote finished, not in the process of migrating, you wouldn't use them together. Recoil is a state management solution produced by Facebook to solve a very particular problem and you could absolutely have that problem when building an app with Remix. And so then you could use them together. But the typical CRUD application that you're building, you don't need a state management library certainly because Remix manages the server cache for you and everything else works nicely with context. It compares well. And then also another big one is Gatsby. Remix is server rendered and I know that Gatsby now can also do some server rendering as well. But, yeah, Remix takes a drastically different approach and I think that leads to a better user experience.

Remix: Production Readiness and Solid Foundation

Short description:

Remix is not officially open source yet, but it will be in the next couple of weeks. It's missing some things, but it's built on a solid foundation. I bought a test subscription for it and believe that the remaining holes will be filled due to the abstraction layer it operates under.

A lot of Remix questions. Remix is the best! I love it! Do you think it's ready for a wide scale production app? Well, they're not officially open source and there's technically no way to get access to it until they do become open source. Because they closed down new subscriptions and stuff. So if you want to work on it today, then yeah, no. But in the next couple weeks, then certainly. I think that it is definitely missing some things. I don't want to make it seem like it's the perfect solution for everything, especially now. But those things will come. I got excited about Remix when it was first released, in fact, even before. In fact, I bought the test subscription because I was so eager. And I accidentally bought a test subscription for a dollar. So I have two subscriptions to Remix, actually. But yeah, I knew from the very beginning that Remix was based on a really solid foundation. And that all of the holes that were in Remix at the time, and some holes that are still there, will easily be filled in because the abstraction layer that they're operating under.

Integrating Remix and Identifying Problems

Short description:

There are various approaches for integrating Remix with a legacy code base. One option is to start using Remix for specific routes and have redirection for a separate app. Another possibility is to integrate PHP rendering with Remix, allowing PHP to render some content while Remix handles server rendering. This provides a lot of flexibility. Regarding the stretch exercise, it is not part of my daily stand-up since I work alone. I learned the air squats from Ben Ornstein's talk on how to talk to developers, and they help me loosen up before giving presentations. Identifying a problem that needs eliminating without going through multiple iterations of solutions can be tricky. Time boxing and research can help, and funding can provide the opportunity to try different solutions. I don't have specific criteria for evaluating problems, but regularly re-evaluating the problem space and taking a step back can help determine if a problem should be tackled or eliminated. As for pets, Cody the koala is my favorite, but there are Emoji pets in my workshops. After the talk, there will be a speaker room and a hybrid discussion room for further interaction. Thank you.

And having worked on it now for your site, how do you feel it would integrate with perhaps a legacy code base? I think there are various approaches that you can take for integrating Remix. So, like, one thing you could say, let's start doing Remix for these routes, and then we'll just have some redirection there, and it will be, like, a separate app. That would be a really easy way to do it, but there are also ways ‑‑ I was talking with somebody recently about integrating their PHP rendering with Remix, and you could totally do that. Have PHP render some stuff. Remix will server render some stuff along with that and send all that HTML to the client, and that would be possible, too. So you've got a lot of flexibility.

Awesome. You heard it here first, folks. Before we switch to a couple questions about problem solving, Alex asks, is the stretch part of your daily stand‑up? No. I don't have daily stand‑up, because I work for myself and by myself, it's very lonely. But ‑‑ We're here for you, Ben. I got the air squats from Ben Ornstein. Years ago he gave a talk called how to talk to developers, back in 2013, I think, at RailsConf. And it was a phenomenal talk. I recommend it if you want to get better at talking to developers. And that was one thing that he did. And I, yeah, borrowed that from him. Wonderful. There you go. You should all give it a try. I get ‑‑ I've given almost a hundred talks now, and I get nervous before every one. Which makes you wonder, like, why do I even do this? But the air squats helped me loosen up a lot. So thank you for indulging me.

Let's talk about problems. Hastu asks, how do you identify a problem that needs eliminating without having gone through X iterations of solutions and associated problems before deciding we might need to rewind? Yeah. That's tricky. That's kind of related to the sunk cost problem. So this is where the term spike comes from. So like you time box a certain amount of time you're going to spend researching a certain solution or finding solutions to a problem. Yeah, sometimes this is why, like I think this is where funding can actually help the entrepreneurs where they're like we're not sure this is going to work but we think it will. So give us some money to let us try and there's risk involved in that. And so hopefully it does end up working or you learn enough to find another way to do it. And sort of related is do you have a set of criteria or heuristics that you use to evaluate a problem when deciding whether to tackle it or eliminate it? Not really, I typically I think it just needs to become a part of your regular routine where you just re-evaluate your problem space right now and think well, man, I worked really hard on that solution and I'm still not done with it and just think like take a few steps back, why do we have this problem? Well, because of this. Well, why do we have that problem? Because of that and just keep going backwards. Now, we're out of time for some of the questions, but a couple of things, first, any other pets coming up or will it only be Cody? Well, there are a lot of Emoji in my workshops, we have Marty the money bag, that one might be fun. Just like bags of money for you, but I don't have any plans for extras, Cody is my favorite. Right after this, Kent will have a speaker room for folks at home, you can join on spacial chat for folks here, if you want to keep chatting to Kent, follow him after this talk. Right after, we will also have the hybrid discussion room right in the discussion room. Thank you.

Check out more articles and videos

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

React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Top Content
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Top Content
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Advanced Conference 2021React Advanced Conference 2021
47 min
Design Systems: Walking the Line Between Flexibility and Consistency
Top Content
Design systems aim to bring consistency to a brand's design and make the UI development productive. Component libraries with well-thought API can make this a breeze. But, sometimes an API choice can accidentally overstep and slow the team down! There's a balance there... somewhere. Let's explore some of the problems and possible creative solutions.
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Top Content
Remix is a web framework that gives you the simple mental model of a Multi-Page App (MPA) but the power and capabilities of a Single-Page App (SPA). One of the big challenges of SPAs is network management resulting in a great deal of indirection and buggy code. This is especially noticeable in application state which Remix completely eliminates, but it's also an issue in individual components that communicate with a single-purpose backend endpoint (like a combobox search for example).
In this talk, Kent will demonstrate how Remix enables you to build complex UI components that are connected to a backend in the simplest and most powerful way you've ever seen. Leaving you time to chill with your family or whatever else you do for fun.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Top Content
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
React Summit 2022React Summit 2022
136 min
Remix Fundamentals
Top Content
Featured WorkshopFree
Building modern web applications is riddled with complexity And that's only if you bother to deal with the problems
Tired of wiring up onSubmit to backend APIs and making sure your client-side cache stays up-to-date? Wouldn't it be cool to be able to use the global nature of CSS to your benefit, rather than find tools or conventions to avoid or work around it? And how would you like nested layouts with intelligent and performance optimized data management that just works™?
Remix solves some of these problems, and completely eliminates the rest. You don't even have to think about server cache management or global CSS namespace clashes. It's not that Remix has APIs to avoid these problems, they simply don't exist when you're using Remix. Oh, and you don't need that huge complex graphql client when you're using Remix. They've got you covered. Ready to build faster apps faster?
At the end of this workshop, you'll know how to:- Create Remix Routes- Style Remix applications- Load data in Remix loaders- Mutate data with forms and actions