Lessons To Outlive React

Rate this content
Bookmark

There was a time before React, and there will be life after. If you tie yourself too closely to any technology, you might trap yourself and miss the next wave. Let's zoom out from the state management library du jour — what timeless lessons can we learn from React? In the talk I'll discuss lessons I've learned from studying React that I will take with me for the rest of my career.

34 min
14 May, 2021

AI Generated Video Summary

The Talk focuses on the lessons we can learn from React's success, including API design, optimizing for change, testing, and community engagement. The idea of a DX UX mullet, with immediate mode in the front and retained mode in the back, is observed in various areas of software development. The importance of naming and optimizing for change is emphasized, as well as the significance of DevTools and building a community. The principles behind the Temporal framework and the importance of good naming in API design are also discussed.

1. Lessons to Outlive React

Short description:

React is older than jQuery when it was first released. jQuery still powers a significant portion of the Internet, but it's no longer as cool. React will also face a similar fate. The talk focuses on the lessons we can learn from React's success. The seven lessons cover the reconciler, API surface area, API design, optimizing for change, testing, dev tools, and community. React's reconciler and scheduler pattern is a good idea for various jobs. The scheduler is seeing implications beyond React, and the React core team has split it into its own package. They are also working with the Chrome dev team to potentially build it into the browser.

Hey, React Summit. I'm here to offer seven lessons to outlive React. So, the premise for this talk is that React is older than jQuery was when React was first released. And jQuery isn't dead. It's still powering a huge amount of the Internet, but it's no longer as cool as it once was. And that fate will come for React someday as well. We should try to think about what will last beyond React.

So as we look at React on its ascendancy and coming into its very mature phase, we should think about what lessons we learn from this enormous success. So hello, I'm swix. I work on a bunch of different things. And I do a lot in the React community. But mostly I give React talks, which is the most relevant qualification for this conference. And a lot of these talks are focusing on individual elements of React. But this is the first talk to really cover the overall philosophy, which I think can take away from that. If you want to dive into individual details, these talks are really good to cover about cover the technical foundations from which I draw a lot of these principles.

So the seven lessons up front are presented here. We'll talk about the reconciler, API surface area, API design, optimizing for change, testing, dev tools and community. So the first part is that the reconciler and scheduler pattern is probably a really good idea for a bunch of different jobs. And this actually comes from Jordan Walk, which is his original insight. That whatever it is your program produces, pixels, files, anything, just make your program regenerate the whole thing every time, add caching and structural sharing to make it fast and that's it. And obviously that's a lot of the original pitch, which I captured from the original JSConf talk. And that's the way that React sort of differentiated itself from the beginning.

But maybe it's also overlooking the other MVP of React, which is scheduling. Right? Which is the other part. And we are seeing a lot of innovation now, when you switch over from old React to concurrent mode React, you start to get the benefits of time slicing, which is talked about a lot. If you want a further primer on scheduling in React, definitely check out Philips Spice's blog post, which I featured here. This scheduler is actually starting to see implications beyond React. So the React core team actually split out the scheduler package into its own package in hopes that other frameworks might be able to use it. And they're working on the Chrome dev team, that should be from the Chrome dev team, to maybe build it into their browser. So if you want React built into the browser, this is the start.

2. DX UX Mullet: Immediate and Retained Mode

Short description:

The idea of a DX UX mullet encapsulates the concept of immediate mode in the front and retained mode in the back. Immediate mode involves rerendering the entire system every time, while retained mode retains the state. This pattern is observed in various areas like build systems, GraphQL, ETL pipelines, and Nullify, where developers aim for speed and simplicity.

But overall I think this actually encapsulates the idea of a DX UX mullet. That's my term for it. Where you have immediate mode in the front and retained mode in the back. Immediate mode, just rerender the whole thing every single time for both the frontend, the user, as well as the developer. And retained mode, which is the system in the middle which actually retains the state. And this is actually true for build systems. So Jared Palmer is actually working on a build system where he has the exact same pattern. And he starts to see this pattern over and over again in GraphQL, in ETL pipelines, and Nullify. And a lot of other different aspects of life where you have a developer working with a system and you want to make it fast, but also easy to reason about.

3. API Surface Area and Design

Short description:

Minimal API surface area is the second lesson from Sebastian Markburger's talk. Library patterns with too much API are not sustainable. React has reduced its own proprietary class format, collapsing APIs over time. However, this approach comes at the cost of giving up routing, state management, and styling, which other frameworks provide. Lesson number three highlights that API design is language design, with a focus on naming and how people talk about React.

Okay. Second lesson. Minimal API surface area. This one, of course, comes from the seminal talk by Sebastian Markburger actually laying out this philosophy. And he basically, based on his experience working with Mood tools, says that a lot of library patterns are just too big. It's just too much API and they're not going to last and it's actually hard to undo once you've actually created that API. So his solution is to just never try it in the first place. And you prefer an explicit and repetitive API rather than an implicit one.

The tradeoff, of course, is that we'll have a lot more... Spoiler! Plate. You see a lot of these examples in how React grows over time. React has voluntarily removed its own proprietary class format for ES6 classes. You can actually see that React's design use... Like, for example, with hooks, where you can see the third party hooks, like, the user-defined hooks, are on the same level with the first party core hooks. And that's a concept that comes from Guy Steele's talk Growing a Language, which I highly recommend. And you can see that React tries to collapse APIs. They'll have these three very common component class APIs, and collapse it into GDSFP, and then also write a blog post to remind you that you may not need it, especially if you use functions. So just less and less API over time, and I really appreciate the React core team for that. But there is a cost, which is that you give up... There's no routing solution, no state management solution, no styling, and all that that comes with React. And this is stuff that other frameworks take for granted, and that React developers struggle with. So there is a cost to that. We'll comment on that in a future lesson.

But lesson number three is that API design is language design. And this is very similar to the previous point, but distinct. And the point in this stuff, and the emphasis here is naming, and the way that people talk about React. So Lee Byron actually had a huge contribution to this, even before he co-founded GraphQL. By sitting down and actually nailing the concepts, the actions, the operands, and the notifications, you can see the result of that in the design API choices of React. And these are the ones that we're familiar with. But they've changed a lot over time.

4. Naming, Hooks, and Optimizing for Change

Short description:

Naming helps to shape our thinking in React. Hooks provide a common naming syntax and a one-syllable API for humans. The principle of UI before API and the willingness to let users hack around existing solutions. The struggle with wrapper components and the pyramid of doom. Attempts to fix the issue with higher-order components, render props, and React.headless component. The realization that hooks are a better option. Lesson number four: optimize for change in API design.

But there's still a grammar that's been established that we can come to expect, and recommend. And it makes sense to us as React developers. It helps us think in React based on the language. And that's a very part of this appear-worth hypothesis, which is that naming actually helps to shape our thinking. The words that we use help to shape our thinking.

You can also see this in hooks. The way that use whatever is a very common naming syntax for hooks. Or they recommended naming syntax for hooks. And just the name of hooks itself. These are the other 50 other names that were considered for hooks before they landed on hooks. And partially, it's with a consideration that, yeah, you want something that's one syllable, so you can refer to it in daily conversation. But it's also an API that humans use instead of computers. And overall, I think maybe Dan put it the best. He says UI before API. You want to start with the end result, and then you work backwards to create the APIs that help you get there. But his other principle is really interesting as well. Hacks and then idioms. Which means that he's willing to let users hack around whatever you have, rather than building in an extra API just to accommodate them.

And here, it's very clear what it is, if you're of a certain generation in React, where you have a lot of wrapper components just to inject something with redux or GraphQL. And this pyramid of doom, I love adding in a little Hadoop in there, just to symbolize how deep it really goes. There are a lot of solutions that try to result in fixing this. There are a lot of solutions that result in this, and you just don't have a choice because React didn't really give you another way. So, if you wanted to inject state, you needed a higher-order component. There was a brief revolution for render props, again, from the same people that were recommending higher-order components. I was trying to resolve this big pyramid of doom thing, I introduced a React RFC called React.headless component. And all of these were just ways in which to inject behavior, which were just not really right. And we all realized that hooks were just a much better option towards the end.

Lesson number four is to optimize for change. So, this is the final point on API design, which is that you shouldn't optimize for, you know, don't repeat yourself, or you shouldn't optimize for minimal lines of code. Optimize for change, and here's why.

5. First-Order Design and Optimizing for Change

Short description:

The first-order design is that your code should be easy to read and write. You want to make the right thing the easy thing. Once you've written the thing, requirements start to change. A great API not only lets you fall into a pit of success but helps you stay there. The React team's solution is to enable local reasoning to optimize for change. Optimizing for change is a fundamentally important idea that will last longer than React. Lesson number five: test the public API.

So, the first-order design is that your code should be easy to read and write. You should have all these characteristics. I really like the pit of success one. It's pretty commonly stated that you want to make the right thing the easy thing. You want to be memorable, like Lee Byron making the grammar for React. That's very memorable. You need to be guessable. That's a really good tip from Jon O'tander. And you also want to encourage performance, accessibility, safety, and user experience. These are all, you know, equally important.

But once you've written the thing, then requirements start to change. And that's where second-order design comes in. You want to also make it easy to change. So, if you have very brittle code, then a slight change in requirements will make your code fall apart. So, a great API not only lets you fall into a pit of success, but helps you stay there. And that's a really, really good observation. And that's something that you see a lot in other formats. So, two references I would like to point you to if you want to look more into this, is the Stack Overflow blog, where they call this requirements volatility, as well as Hillel Wain, who calls this requirement perturbations. Same idea, different takes. The React team's solution to solving this is to enable local reasoning, to try to reduce as much global context as you need, and just to focus on the code in front of you, and that should allow you to change whatever you need. Because then you actually don't have to have spooky action at a distance. You see this in Dan's blog posts, in Sophie Alpert blogging about Data Loader. You can see this in Style Components, Tailwind, or the Relay Compiler design. There's a lot of different ways in which you can enable local reasoning that helps to make things optimize for change.

I have a lot more slides than this. I had to cut out because I don't have time, but feel free to hit me up because optimizing for change is a fundamentally really important idea that will last way, way longer than React does. Okay, lesson number five, test the public API.

6. Testing, DevTools, and Building

Short description:

I have a lot more slides than this. I had to cut out because I don't have time, but feel free to hit me up because optimizing for change is a fundamentally really important idea that will last way, way longer than React does. Lesson number five: test the public API. Very, very simple one. You should write tests, not too many, mostly integration. Don't test implementation detail. Lesson number six: DevTools are not optional. React emphasizes DevTools. React also uses Codemods. The React Dev Warnings is something that is really taken to the limit with React. You can't automate everything, so it's nice to introduce some fixtures. The last tip is a meta-tip: DevTools to help you build DevTools. We should be aware of what we're building and shipping and should be aware of big regressions.

I have a lot more slides than this. I had to cut out because I don't have time, but feel free to hit me up because optimizing for change is a fundamentally really important idea that will last way, way longer than React does.

Okay, lesson number five, test the public API. Very, very simple one. You should write tests, not too many, mostly integration. Don't test implementation detail. This is obviously very, very important for React because React undertook a huge rewrite of the whole codebase, but kept the tests and the tests actually outlasted the codebase, and that's not something that's very insightful for your apps. Obviously, they also implemented this little tracker thing for IsFiberReadyYet, where they actually tracked the completion towards the rewrite. And it's just a really motivating thing to see for the React codebase, that it's actually spread as a movement towards React apps, right? So we've seen enzyme sort of relatively declining compared to the React Testing Library, and that's as it should be, because our React Testing Library has this focus on testing only the public API of components. And that's what your users will use, and that's the only thing that you should really care about for your tests. And it makes it so much less brittle compared to what was there before.

Okay, lesson number six. We're moving along to DevTools. DevTools are not optional, and you can see how much React emphasizes DevTools. So of course, the React official DevTools, the Chrome plug-in, is maintained by Brian Vaughan on the React core team, and he does an amazing job. Like, I don't know how much I'd pay for this, but I would pay for this. And you should learn all the intricacies if you want to debug. React also uses Codemods. This is not optional for React basically because the React team actually has to maintain the tens of thousands of components that are in the Facebook codebase, and you have to upgrade all of them whenever they change the APIs, so of course you have to automate these things. And we, as the React community, get to benefit. The React Dev Warnings is something that is really taken to the limit with React. So you can see the React error overlay, or you can see lint warnings, or you can see it in the console. We even have error codes, so you can see nice errors in production, but not have extra weight in the final build artifacts, and it's a very nice decoder experience, which I wish that more developer tools copied. You can't automate everything, so it's nice to introduce some fixtures. I really like this as a way to learn React as well, because you can start to toggle on feature flags and change different browsers and see how the behavior changes. It's just a really nice way to manually test things by having everything in place so you don't have any time setting it up. And finally, the last tip is kind of like a meta-tip. DevTools to help you build DevTools. For React, because it's building a library that's going to be embedded into millions of other applications, they need to keep the bundle size small and to never increase them unintentionally, and it's something that we can actually borrow for our apps as well. We should be aware of what we're building and shipping and should be aware of big regressions.

7. Importance of Community Engagement

Short description:

DevTools are not optional. Building a community is crucial. React's early core team listened to feedback and engaged with the community, which paid off in bringing over users. We should learn from this and prioritize community engagement in our own projects.

So DevTools are not optional. The last lesson is that we should not neglect community. We want to build a community as well. This obviously goes back to the right to the beginning of open-sourcing of React. Actually, Jordan Walk actually had to introduce JSX because he was being ignored internally within Facebook. And once he introduced JSX, they really liked it a lot better. But then, the exact opposite happened when they open-sourced to the public. This is Jordan during the headlights trying to introduce JSX to a very bad reception, and here's Pete Hunt trying to rescue it by saying, hey, it's optional, guys, don't worry so much. And I think we eventually came around to the idea. But the core of it is that the whole early core team really listened to feedback. They were in IRC on Stackoverflow 24-7, and they replied to every single piece of criticism viewing them as their fault. And that work in the community paid off. They started to bring over a lot of users, in particular David Nolan from the ClojureScript community who built Omen, really started to hype up React quite a bit. And I think that's a lot of legwork that is maybe forgotten to time. But I think if we're starting to create our own projects that we want to be as popular as React, we need to start to pay attention to community just like they did. And that's a lesson that we take along with us.

8. React's Distribution and Lessons

Short description:

React's distribution has led to a cooling down in the creative destruction of frameworks. The contract for React has shifted from focusing on features to stability. The seven lessons covered in this talk include having a core idea, working on the API design, productionizing it, and humanizing it. The metal lesson is to fall in love with problems because solutions come and go, but problems remain. Check out the book at learningpublic.org for more principles.

Also, we need to start solving pain points. So, one of the big pain points was React is so small that it doesn't solve the rest of the other applications and people started making memes and jokes about it. So, Dan Abramov actually went and created Create React App. And that's a story that I tell in a separate talk called Create React App.

But in general, the story of this is basically that it's a distribution of React, right? You bundle React with other things, Next.js and Gatsby bundle it with routing and Blitz and Redwood bundle Next.js and so on and so forth. You can bundle and bundle and bundle. And what we're really seeing here is a cooling down in the creative destruction of frameworks and the maturation and deployment of React and we're starting to build on top of React rather than trying to compete with React. And the main thing that React, the contract for React starts to shift, right? Now the main thing that React shifts, it's not features. It's stability. Of course, the S curve is not an end. It can start to S again when concurrently React is fully out.

So the seven lessons that we covered are all of these. I think it's going to be a bit hard to remember if you're seven. You know, working memory is only three to five. So here's my breakdown. First, you have a core idea of whatever your library or framework is going to do. Then you want to work on the interface between the developer and your core library. So that's your API design. Then you want to productionize it, you know, by working on the testing, by working on dev tools. And then finally, you want to humanize it to make sure to meet people where they are. And that's the seven lessons. That's not the only seven lessons that you can learn from React. And there's more on the way. The React team is very generous in sharing their lessons on concurrent React. And so you should pay attention to those. But overall, the metal lesson I want to leave you with is that you should fall in love with problems because the solutions come and go, but the problems will always remain. That's it. If you want to learn more about these principles, which I think will last our entire careers, you should check out my book at learningpublic.org. But otherwise, thank you so much for having me and see you in the rest of the talks. Bye.

QnA

API Surface Area and Optimization

Short description:

Most people say minimum API surface area and optimize for change. The speaker shares their current role at temporal.io, a back end microservices orchestration startup. They explain their motivation to join a small company at an early stage. The speaker also mentions a question from Juan Segebre about common pitfalls and mindsets that hinder optimization for change.

Looks like most people say minimum API surface area and optimize for change. We get a lot of ties on these, like 36%, 36%. So split down the middle, was that what you were expecting from this question? The API surface area? I think so. I think it tracks with what people respond to very well. Yeah. Cool. Awesome.

Well, we've got a bunch of questions for you, but I wanted to start with one. And that is, what are you up to now? So in your introduction, I was like, you were a senior developer advocate for AWS, but I know that you've moved on because that's the team that I'm on. So what's up? What are you up to now? Oh, they put you in charge and I had to peace. That's a joke, everybody. He left before I became the manager. No. Yeah, of course. No, I really. Anyway, so, yeah, I just joined temporal.io. It is a back end microservices orchestration startup. So very, very different to what I normally do. And I wanted to, I guess, broaden out. But then also take my bets on a small company. You know, where is Series A, very early stage and hoping to be the next big, I guess, you know, back in orchestration startup. And if you ever have worked on long running tasks like, you know, like sagas for the back end, this is something that you should really check out. But I'm not going to plug it at a React conference. So I had to come up with a different talk for this one. No, that's awesome. That's really, really cool. We have more questions, too. So this one's from Juan Segebre. What are the common pitfalls and mindsets that avoid us to optimize for change? That avoid? I'm sorry. I would guess that it's help us to optimize for change? Or that make us avoid change? One of the two.

Optimizing for Change and Writing Blog Posts

Short description:

There are various ways to optimize for change in software development. One approach is to avoid relying on the order of arguments and instead use options objects. Another strategy is to co-locate data and make it easy to delete, as append-only code can lead to technical debt. The speaker plans to write a more detailed article on this topic in the future. They also discuss the importance of following the three strikes rule when it comes to writing blog posts, finding a balance between publishing too much and too little.

Because that's supposed to be good. We're not trying to avoid it. Hang on. I'm pasting my slides and my links in the Discord. That's where I have it. And I don't know if there's any other channels that should be posting it. But if anyone wants to follow up on all the resources I pasted, you can follow up there.

But, yeah, essentially there's so much, right? I think just thinking about your design by thinking about what changes could come in and wreck your day is essentially the idea. And so it can be as small as things like relying on the order of arguments. So if you notice in React, props don't really care about the order of arguments. And that's because it basically is an options object. Which is something that if you look at one of my favorite talks, Simple Made Easy by Rich Hickey, relying on the order of something is actually complexity. It actually makes you need to remember, like, what comes after what? Whereas if you put things in independent order, you free yourself up. But then it goes as big as sort of like are you co-locating data and making things easy to delete. Right? Because append only code is a major source of technical debt. If you're scared to delete stuff because you don't know what global effects it's going to have, then you have essentially what I call tentacle mummification. Because you're just slapping bandage after bandage after bandage and you just end up with a mummy of technical debt. And yeah, so there's a lot of ways to optimize for change and I plan to write a bigger article on this in the future, but I wanted to stick it in there.

That's awesome. And people should definitely follow you on social media to see all your blog posts because it's so, so impressive how you just write about things. And you get articles out and you see a topic a couple times and you write about it. And I think that's awesome. Yeah, I call it the three strikes rule. I think people have a barrier towards when they should write about something because they feel like they need to be an expert on it to write about it. Or they have the complete opposite. They spam out every single waking thought. And those two extremes are not very ideal, right? Because you're either publishing too much or you're publishing too little. So, my three strikes rule is once you've referred to an idea three times, you should try and blog about it. Because that's stuck around just long enough to prove that it's probably going to stick around a bit longer in your mind. But it's not too long that you've sort of gotten bored with the idea or it's starting to lose relevancy.

Blogging Pressure and New Frameworks

Short description:

To be less pressure with your blogging, just get it out after three strikes. Find a different outlet where you can experiment more. Use different outlets for different purposes. Consider the digital garden idea. Svelte is a framework that might replace React in the future. React's success has inspired others. Temporal is implementing these ideas.

So, I'm trying to promote this concept that to be less pressure with your blogging and just get it out after three strikes. I love that idea. I'm such a perfectionist that it's so hard for me to actually press publish on anything like I take notes on everything. But that's a great point.

You're a very polished writer. And I think that's something that we have to understand as content creators. Your blog conveys an expectation of the amount of work that goes into it. And now, I think if you deviate it from that people would be a bit… feel uncomfortable with it. So, I think you need to find a different outlet where you can experiment more and where people don't expect you to have that level of polish. So, I'm a fan of actually using different outlets for different purposes.

Oh, I love that. I love that. You're giving me all the advice here. I love the digital garden idea too. People seem really into that especially in the egghead community. So, I should dive more into that. You did already post all your resources which is incredible. That was our next question. Then the next one is from Sasha.

Are there any specific frameworks new and improved based on these lessons on the that you foresee might replace React in the future? Wow. I didn't want to go there but I really like Svelte. We are holding a conference in two weeks. So you can come check out Svelte Summit. It's on YouTube. I think it's general for open source. If you are working in dev marketing or starting an open source project or you want to bet early on open source, these are the things to look out for. These seven lessons are not the only lessons and I am interested in other people understanding what they can draw from React. React is one of the most successful open source frameworks in the world. Everyone is interested in replicating success for their own thing. My company, we're implementing these ideas at Temporal.

Temporal Framework and Learning Principles

Short description:

Temporal is an open source framework that came out of Uber. It's useful generically and can be applied to various areas. The principles behind the framework are more important than the specific API. Learning and applying these principles will have a lasting impact on your career.

Temporal is an open source framework that came out of Uber and we're trying to commercialize and popularize that. I think it's just useful generically, the only front-end specific observation was the first one which is more about reconciliation and scheduling, which is a very front-end framework focused thing. But then you realize you can apply that to other things. I featured a tweet by Jared Palmer saying he's using the exact same ideas for the build system. And that's nothing to do with the DOM or the front-end, but that's great. It's the same software engineering principles that you can reuse again and again. And I think that's my ultimate point, which is anything that you learn, you're not learning the API. You can learn the API, but really the thing that will stick with you even after that framework is gone is the principles. And we should try to learn from that because that will stack and last our entire lives. So really, really valuable thing to learn.

HyperApp and Naming Systems

Short description:

Have you tried HyperApp? It's a lightweight framework that mirrors the Elm architecture. I find the Elm programming language hard to use. How do you come up with a good naming system? I have a blog post on that topic. It's important to have some perspective on naming things and not give up before trying. Your first blog user is yourself.

That's awesome. That's awesome. Have you tried any of the other like newer frameworks that you talked about, but have you tried HyperApp by any chance? No, what is it? It's a super lightweight framework that allows you to use JSX as well, but it mirrors the Elm architecture, which I really enjoyed. Do you know Elm, like the front end? Yes. I actually, I have read Evan Czeplicki's freshman, sorry, undergrad graduation thesis, which is like the basis for Elm.

That's awesome. And it is the most impactful undergrad. Like I don't remember my own undergrad thesis. I remember mine. I script a ton of tweets and it was all about how people discuss different politicians on social media, but yeah, that's a super, super interesting insight, but yeah, HyperApp. It's written in JavaScript, but it has the Elm architecture. I really like it because it's lightweight. I like the Elm architecture, but I find the programming language kind of hard to use, so I don't know. That's a fun one.

This one is from Katre. How do you come up with a good naming system when that's not your strong suit? How much time should be spent on that? I have a blog post on how to name things. I've actually tried to answer this question because it's one of the known hard problems. We should have some perspective on naming things. If you say that you're just not good at it and you don't try, then you're essentially just giving up before you start. I don't think that's a very productive way of handling things because you're going to have to name things. That's a lot of what we do as part of Coders. I don't know. What was the question again? Did I answer it? A lot of my answers are just like I have a blog post for that. And that's a good way to live because that's a good leverage of time because I spend hours on that thing. I'm not going to give it in this little chat. If people are really interested, they can go look it up. Yeah. It's almost like your second brain leak. You don't have to remember all these things because you've written about them in the past. Your first blog user is yourself.

Importance of Naming in API Design

Short description:

The React team puts a lot of effort into naming because it's crucial for human communication. Good API design involves considering naming carefully. The React team considered multiple names before settling on hooks, which is a simple and effective name.

So the question was about coming up with a good naming system and how much time should be spent on it, which I think you answered. Yeah. I mean, I'm really inspired by how the React team thinks so hard about naming. And that means nothing to the computer, but it is everything about communicating between humans. That's a lot of what good API design is about. And when you see so I posted a screenshot in my slides of how many names they considered before landing on hooks. It's not an accident that it's such a simple single syllable name that vaguely like a lot of people have problems with the name hooks.

Naming and Optimizing for Change

Short description:

Okay. And I had some problems with it, but it was good enough. And it conveyed the message and it was useful. And that's what they're aiming for and that's something that I think with some practice, you can at least avoid bad names. Which is good. I don't know how to name things. That's a hard one. So, going back to that first question, they change their wording. So, we want to optimize for change what things prevent us from doing this. What misconceptions. That way we can try to move away from them. So, this is I think this comes to API design and coupling and how when you when you make certain choices. There is a table of like fundamental choices API design choices that lead to simple design and more complex design. And I think it's just the real truth that if you just avoid the more complex ones, that helps to, you know, understand what leads you towards optimizing for change. Honestly, there's a lot of truth in the fact that you're relying on order. And order can mean sort of hierarchical order as well as sort of sequential order.

Okay. And I had some problems with it, but it was good enough. And it conveyed the message and it was useful. And that's what they're aiming for and that's something that I think with some practice, you can at least avoid bad names. Which is good. And I think probably step number one is to avoid multiple names for the same multiple very different names for the same concept. And you can just understand what the more generic abstraction you're trying to name is as well.

I don't know how to name things. That's a hard one. Yeah, definitely an unsolved problem. Okay. So, going back to that first question, they change their wording. So, we want to optimize for change what things prevent us from doing this. What misconceptions. That way we can try to move away from them. Ooh, thanks. Got it. What could prevent us from doing this? What misconceptions. Ah, interesting. I haven't really thought about this. I don't know. I don't know if there's anything like doing the opposite essentially of everything I recommended. Yeah.

So, this is I think this comes to API design and coupling and how when you when you make certain choices. So, a lot of this is contained in the simple made easy talk because he actually has a table. I had to cut this out of my talk because I had to cut it for time. But there is a table of like fundamental choices API design choices that lead to simple design and more complex design. And I think it's just the real truth that if you just avoid the more complex ones, that helps to, you know, understand what leads you towards optimizing for change. Honestly, there's a lot of truth in the fact that you're relying on order. And order can mean sort of hierarchical order as well as sort of sequential order.

Optimizing for Change and Scoped Styling

Short description:

Making your asynchrony, data fetching, rendering, and styling independent of order enables local reasoning and optimized for change. While avoiding globals is ideal, limited use can be acceptable. Scoped changes to specific elements, like with tailwind, offer a more localized approach to styling. Tailwind's direct styling to elements is a fascinating technology that deserves further exploration.

And I think once you make your asynchrony, your data fetching, your rendering, your styling, independence of order, then you allow, then you enable local reasoning. And that is ultimately what the Facebook team and ultimately something I agree with, ultimately what they think helps enable optimized for change. Avoiding globals is one of those very cheap answers. But sometimes globals are really nice. I don't know how I feel about globals. I think limited use of globals is probably the right way to phrase this. And then everything else, you know, just try to make, try to keep things scoped to the locality of where you change it, which is, by the way, one reason I really like tailwind, because tailwind scopes styling directly to the element, as though you're using inline styles. That's a fascinating technology, which I hope more people are exploring. That's awesome. That's awesome.

Career Advice for Developers

Short description:

I want to pivot to your book instead of your talk. Three favorite pieces of career advice: open-source knowledge, good enough is better than best, pick up what they put down.

Okay. We got about a minute. I want to pivot to your book instead of your talk. What are your three favorite pieces of career advice for a junior to senior developer? I'm still on the side here. Oh, my God. For what it's worth, I have 40 chapters. You're asking me to pick my favorite among you. This is going to be hard.

Okay. So let me try to talk about, so I think one thing is to open-source knowledge, essentially. I actually have a talk on this on my YouTube where it's a variant of what I'm known for, which is called learning in public. But this is really laying out your raw materials in the open and letting people contribute and evolving it over time. Whereas a lot of people, when they try learning in public, they tend towards finished articles like a YouTube video, a blog post. That's kind of like a one and done type of thing. I want people to try doing more build stuff up over time and just go and build something substantial and something useful to yourself and everyone else around you. So that's how I got involved in building the React and TypeScript cheat sheets project which is literally a reference for me to learn React and TypeScript. That's open sourcing your knowledge.

Another one I really like is it's this idea of good enough is better than best. Stop pursuing the best because you'll never be happy. You have to stay on top of other people's news announcements and you have to care what other benchmarks people think and focus on what's good enough, what you need and what you know best. Finally I guess one more to just throw out there is pick up what they put down. So if you want to a lot of people ask about the cold start, trying to get started in writing and learning in public. And they find that they don't have any traction or no readership. Respond to other people's work. If I just dropped a new book, review it or engage with creators and you'll find that you'll have a much higher chance of responding and becoming a collaborator and eventually a friend. That's my three tips.

That's amazing. Those are great pieces of advice. Well thank you so, so much. It's been fun to catch up and also so great to hear your advice and your talk. Awesome. Yeah.

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 Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Summit 2022React Summit 2022
27 min
Impact: Growing as an Engineer
Becoming a web engineer is not easy, but there are tons of resources out there to help you on your journey. But where do you go from there? What do you do to keep growing, and to keep expanding the value you bring to your company? In this talk we’ll look at the different kinds of impact you can have as a web engineer. We’ll walk through what it means to take on bigger, more complex projects, and how to scale yourself, and grow the community around you. By driving our own development we can all grow our impact, and in this talk, we’ll discuss how to go about this.
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.

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 Advanced Conference 2021React Advanced Conference 2021
132 min
Concurrent Rendering Adventures in React 18
Featured WorkshopFree
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?

There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.

Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
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
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
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