Noel Minchow: Hello, welcome to LogRocket. My name is Noel. I'm a software engineer at LogRocket, and today we're joined by Addy Osmani and Lydia Hallie. How's it going? Addy Osmani: Good. Thanks for having us. Noel Minchow: Yeah, of course, of course. Addy and Lydia are here specifically to tell us about their Patterns.dev book. Lydia is a dev relations engineer at Vercel. Addy's CV is a bit more complex, but he's currently an engineering manager at Google working on Chrome speed and dev experience efforts. Did I get all that right? Addy Osmani: Exactly. Noel Minchow: Perfect, perfect. Awesome. So, yeah, again, I want to start talking about Patterns.dev. But before we get there, can you guys give us a little bit more info on your backgrounds and what are you're working on, your current roles? I want to start with you, Lydia. Lydia Hallie: Sure. Yeah, so currently I work at Vercel. But before joining Vercel, I used to be a software engineering contractor for many years also for startups, mainly. On this side, I also created just a lot of content on social media about my journey, traveling the world while being a software developer remotely and not going to college, all that stuff. And also, creating visualized posts on technical articles that people seem to enjoy, more the in-depth articles and like, "Okay, what's actually going on under the hood?" And that's kind of how it bridged to Patterns.dev because we, of course, also use some of those visualizations in patterns. Noel Minchow: Nice. Awesome. Awesome. Yeah. How about you Addy? Addy Osmani: Oh, how about me? I've been working on Chrome for about 10 years. A lot of my focus has been on trying to improve performance speed of the web, user experiences, that type of thing. And while we put a lot of focus on trying to speed up the browser, of course, how developers architect their pages is a huge part of how quickly things load or how maintainable things are on the web. And so, I've spent a little bit of time thinking about architecture over the last while too. And part of this project was born from wanting to rethink some of the older books I'd written around this topic and bringing a fresh perspective. Lydia has got a very fresh perspective on a lot of these ideas and it was really fun collaborating with her on this. Noel Minchow: But yeah, I guess when dev, maybe we should define some terms. I feel like when devs say "patterns", lots of people mean different things based on the context they're in and who's using it. So, specifically, what patterns is Patterns.dev focusing on? Addy Osmani: I guess, stepping back, we know that design patterns give us this common vocabulary to talk about software design and Patterns.dev is all about trying to give people a perspective on design patterns through the lens of modern JavaScript. JavaScript has changed heavily in the last ten years. We've got baked-in modules, we've got promises, we've got async, we've got all sorts of things. And so, we wanted to rethink a lot of classic patterns through that lens. And as we started working through the content, we realized, oh wait, it's not just about how you structure your code. How you structure your code can have an impact on how things are rendered on a page or how things load on a page. And so, patterns take this almost holistic view of architecture rendering performance. And we try to tie it all nicely with a bow. I don't know, Lydia, what is your perspective on it? Lydia Hallie: No, I think you explained it perfectly. To me, when I started the project, I knew it was going to be about patterns. And I knew about the books that Addy wrote many years ago and I wanted to read it, but I felt like, "Okay, it's written in 2012. I don't know if it's still relevant. But even then, I was like, "Okay, but what do patterns actually mean?" I've been writing JavaScript for the past, well, when I started, past six years, I've never really even thought of patterns before. But as we were writing the articles, it made more sense to me in my head like, "Oh, it's more just like reusable thought patterns almost, that it doesn't always fit in the exact same context. It's more of like, "Oh, this is a solution to this type of problem." So, in the future, if I ever come across something similar, I know what the solutions are and maybe I could potentially change it a little bit, take small pieces of it. And so, yeah, for me, Patterns, it's more of a thought process in your head that you have to teach yourself. Noel Minchow: Yeah. That's an interesting thread. I feel as developers grow, that's kind of a skill that isn't typically articulated very cleanly in that, devs who have seen a lot and have solved a lot of problems implicitly know what patterns may be useful to solve certain types of problems, right? And that intuition is a hard thing to, I think, force oneself to learn. How do you guys try to instill that knowledge via your work? Addy Osmani: I think that a common critique, that patterns just in general have, is that people feel like, "Oh, hey, we're cramming them into every possible case where they may not necessarily have value. One of the things we tried to get across with this book and that was really important was, patterns are useful for solving very specific problems. They are descriptive, not prescriptive. And if you don't have those problems, there's no reason to be applying them. And so, one thing that Lydia has done a really good job of in many of our articles is talking about what are the specific use cases where patterns should be used and what are the places where maybe you shouldn't consider them. Or maybe, they're actually no longer relevant and we try to take a very pragmatic view to this problem. Noel Minchow: I guess, how is the book laid out? How is it formatted, structured? How do you guys present them and help readers figure out what pattern may be applicable to problems that they are solving? Lydia Hallie: I find that a difficult one to answer actually. Now, I think, well, we want to make all the articles first relatable versus okay, what is a problem that people might be facing without just immediately showing a solution to it? Of course, we have design patterns, we've got rendering patterns and we've got performance patterns. So, in Patterns, I think we also just explain like, "Hey, these are the patterns that exist." Whether you go to college or not, I mean, then you probably have heard of them just because you have to know about them. So also, don't try to reinvent the wheel if you ever come across any of those problems. People have already had decades, probably have thought of this for decades and have come up with really good and reliable solutions. At the same time, of course, I think also a lot of JavaScript developers nowadays, they might take things for granted, like, "Okay, I'm using these tools, but why do you have to use these tools?" And I feel we've also tried to explain because these are still problems that the web is facing today, that JavaScript is facing today. But luckily there's just, the community is so great nowadays that we have so many tools that luckily take that pain away from us, but they're still there. So, it's also just sparking that curiosity in people, like, "Okay, what am I actually working with?" Noel Minchow: Got you. Got you. That makes sense. So, you touched on three different kinds of patterns that you guys are covering there with design, rendering, and performance. Can we maybe go into an example of each of those, starting with, I guess, whatever you guys think would make the most sense to start with? Addy Osmani: Sure. So, there's design, rendering, performance. In design, we have a lot of classic patterns. So, things like the module pattern, how do you modularize your code, your components in a way that is reusable. And through lens of modern JavaScript, we can talk about things like static imports, dynamic imports, all of that fun stuff, tree shaking, all that fun stuff. That's an example of a design pattern. One thing we've tried to do with this book that I don't think has been well covered in other places is acknowledging that in the last couple of years, especially the way people are building for the web often involves using a set of libraries or a JavaScript framework and frameworks can have their own design patterns. It's very often the case that what, I love writing Vanilla JavaScripts, but a lot of folks today are using React. They're using Next.js, they're using Angular and Vue and all these other things. And so, again, being pragmatic, we need to make sure that we're giving people patterns and concepts that are very, very relevant to the types of apps they're building and structuring today. So, we think about design patterns at an app level. Rendering, it has only become more complex and more powerful a space. So, these days it's not uncommon to hear folks not just talking about server-side rendering or client-side rendering, but also, static site generation and incremental and all of these other way, progressive hydration. All of these other ways of rendering your page, your content, attaching event, listers hydrating your page. And it's difficult, I think, especially for beginners and even intermediate developers to keep up with all of these concepts. So, we try to go into a little bit of depth on that. And then for performance, it's still really difficult for folks to build a fast site these days. And there's a lot of great work that's been put into stacks like Next.js and many others to improve how fast things are out of the box. But at the same time, understanding how the decisions you're making about the structure of your application can influence how quickly users see what's on the page. I think that's really important and is an area that still has a lot of opportunity for growth for a lot of engineers. Noel Minchow: Enjoying the podcast? Consider hitting that follow button for even more great episodes. Got you. Got you. So, going back through these linearly as you listed them. Starting with design, you talked about module patterns and imports and tree shaking. And I guess my, I don't know, my experience has shown me that I feel a lot of front end devs that specifically have spent most of their time in the front-end space, they end up writing an app, they're using a framework like React or something. And those kinds of patterns just end up being emergent because the framework is encouraging them to write that way. I guess, do you guys share that perspective or do you think that is less common than one might think it is? Addy Osmani: I would say that, if you think of front end as a set of layers, you can have different opinion based on which layer you're talking about. React tends to slice patterns like MVC a little bit vertically by concern instead of doing it horizontally. And that can sometimes mean that you have views as this thin layer on top. Components in React started out as this very small vertically sliced encapsulated MVC. You had state contained in your model, you're rendering, which is your view. And then, you had this control flow logic, which is almost like a mini controller. These days, people will abstract a lot of their logic into Hooks and you could see components more as your views, Hooks as your controllers. And so, I see libraries like React, giving you a little bit of opinion here. There's a little bit more opinion that go into Meta frameworks like Next.js, but they don't try imposing too much convention on you. And so, we end up with a little bit of alignment on the patterns that we use. So, you'll see a lot of developers now using Hooks, some folks using higher order components. But there isn't a whole ton of alignment around what we should be doing otherwise and that can lead to people very often accidentally aligning on the same ideas, which is totally fine. One of the things we're trying to do is just socialize. What has worked well, what have people landed on the last couple of years, hopefully in order to save you a little bit of time on that journey. Noel Minchow: Yeah. Yeah. I think so too. I feel especially now, again, now that we have like Hooks and HOCs and stuff. Yeah, there's a little bit more maybe fracturing than there was historically in how apps are built. So, I think, yeah, if nothing else, it's good to reflect and understand why people are doing, why people are doing what they're doing. I would postulate that new devs jumping in probably don't have all of the context on why Hooks are helpful and can help pull out logic that was harder to abstract before. So yeah, I think that is still an interesting space to talk about for sure. Was that design piece, of the three I know we talked about design, again, rendering and performance. I guess, which one is the hardest to articulate for you guys and write content about? Lydia Hallie: For me personally, it probably would've been the rendering patterns just because there are so many different approaches and so many different tools that you can use nowadays to achieve a better rendering experience or a better user experience through rendering. At the same time, I feel performance is just getting more and more important because more users are using the mobile browsers. Internet is almost everywhere now, even in places where the internet connection isn't as stable and frameworks like Next.js, of course, their motto is great performance. So, they've made more people aware that performance is important, which is great. But at the same time, there are just so many different ways nowadays to achieve a great performance, which is of course a very good thing that at the same time it's tricky. It can be a dilemma sometimes. Noel Minchow: Yeah. Yeah. So, I do want to talk about rendering. Let's hone in on that a little bit. So, like you're saying, there's a lot of tools out there and a lot of people telling you this is, be the end, all this is how we write more performing apps. And we listed some before Addy, I think you went through a bunch. You've got full backend rendering or partially rehydrated static sites and all this crazy stuff. How do you recommend devs that are newer in the space or thinking about performance patterns for the first time? How do they jump in? How do they get started? Addy Osmani: I think that it's, one thing I think is really useful for beginners and intermediate developers to think about is, understand what the user experience you're trying to deliver looks like, and then work backwards from that to the technology that you need. Very often, we don't do that. And sometimes it's for understandable reasons, right? So, I've come across lots of teams who will choose what to use just because it's popular or because it happens to have a ton of training around it or it's on Hacker News this week. So clearly, it's the next big thing, so I should be using it, right? And I think that just understanding what your constraints are, what your user experience needs to be, that's really important. Lydia was mentioning earlier a lot of people are currently trying to build experiences for mobile. What does that actually mean? Are your users on a super constrained mobile device that might influence the choices that you make technically? Are they in parts of the world where there isn't necessarily great internet, 4G, 5G, and so on. All of those things are factors worth keeping in mind. And then, when we come back to being pragmatic, I think it's useful to take a look at what are stacks that try to set you up for success. And can you validate that those stacks are actually doing what they say they're doing. So, it's very easy for anyone to put up a landing page that says, "Hey, we are fast, use us. We will deliver the best experience ever." It's always good to just validate how, how true is that? Does it actually meet your goals? Does it give you enough headroom? There's the framework delivering whatever code it has to deliver, then there's going to be your app logic. Is that actually going to help you achieve your goals without you having to become a performance expert? Hopefully, the answer is yes. The answer is very often not that clear. I think understanding the problem space, understanding your constraints, I think that's really important. And then also say that there's been great work done in stacks, like Next and Svelte and Lit and many other solutions to try helping people here. Noel Minchow: Yeah. That leads me to an interesting question on performance pattern specifically, because I think one could argue that doing things performantly is more a matter of choosing the right tools in the modern, like the modern web ecosystem. Is there work, I guess, are there common pitfalls beyond that you guys talk about in the book that devs might be falling into? Even if they're making all the right decisions up to that point, everything's looking good, the code is relatively healthy, modularized, there's tree shaking and stuff happening. What performance problems do you guys still see as the most common? Lydia Hallie: Well, personally, I think it's not necessarily a performance pitfall, but it's more the balance between having a good user experience and a good developer experience, because you can optimize for the user experience and have a horrible developer experience that will still give you a bad product. You can't iterate as fast, you don't feel comfortable making changes in your code, your team just isn't as productive. And then, you can have a really good developer experience. So many tools nowadays, they also focus on the developer experience, the DX, which is great. But of course, the user doesn't care about how you developed your app, what your code base looks like. So, I feel a lot of people, either they really try to optimize to get that really fast user experience. And then I see their code, it's just packed together. It's like, "Okay, it's great. But what is your actual result here?" You want to have a great product you can share with the world and maintain hopefully for a long time. Scalable if you want to add team members, all that stuff. So, I guess just scalability for both users and your team for developers is a pretty common pitfall. Addy Osmani: I guess, that's a really, really important point. My answer would be in a slightly different direction, which is, I think that a lot of production sites today very much very often come down to having two classes of problems. There are problems you introduce yourself via your application code, your first party code as some people will call them. And then, there is your third-party code or stuff that you have authored and that either gets included on your site via marketing or the business or other folks. Sometimes it's embeds, ads, trackers, all sorts of other things. And I've seen plenty of teams who will build a really fast experience and then get bogged down by all of this other third-party stuff being added to their pages. I think that a little bit of a performance mindset in businesses really helps here, caring about every single piece that's contributing to the end user outcomes is really important. And then just diligence, like being able to push back and say, "Well, if we don't include all of these third parties, maybe we're able to load up pages faster, maybe we can increase our conversions. Maybe we can increase the business metrics in some ways." And so, as much as the content on Patterns.dev tries to help you out with your first party code, the code that you're authoring yourself, we also try touching a little bit on this other aspect code that you don't own and how should you navigate that problem space too? Noel Minchow: Nice. That's a really cool kind of space to focus on, I think. Because I agree and I've been in this situation before. Again, I'm working on web front-end code that's getting pushed out for marketing content purposes. And yeah, it's just, if I think it's even in the past, it was particularly challenging to know the impact of adding something that wasn't performant and then just kind of leaning on the fact that we need this to see X, Y, Z happen. We need these four metrics to understand what's going on, but not really factoring in how much that may be impacting your page ranking and stuff like that. It's nice. It's super cool to hear that you guys focus on that a little bit. Cool. Cool. Well, I want to, I guess, touch on all of them. So how about in the renderings, the rendering space? Is there anything, I guess any particular high-level points that you guys would like to touch on or you think that might be interesting to give a 30-second blurb on? Addy Osmani: Well, I know that Lydia, Vercel have been thinking a lot about the spectrum that is rendering. And 10 years ago, it was very much SSR, CSR these days. There's 10 other ways of doing things. Maybe you have thoughts on that side of things in rendering. Lydia Hallie: Yeah. I mean, I feel even some patterns that we've covered on this website will almost be outdated again, maybe within the next five years. I mean, hopefully not, probably not. But we're definitely rethinking the way, there are many benefits to static, like SSG and many benefits to SSR. But at the same time, they all have their performance benefits and drawbacks, of course. So, for example, now with like edge rendering and streaming SSR, we're combining both the benefits of static and then the benefits of SSR in this new rendering technique or not even a technique, I guess, new rendering pattern, which is extremely interesting. It's a very different way of thinking about front end code and just rendering in general on the web and how you, I guess, build your entire pages, how you structure your components, your trees, all that stuff. So, yeah, it's definitely interesting to see just how the rendering is getting more optimized for global rendering, more on the edge, closer to your users. Yeah. Noel Minchow: Yeah. Nice, nice. Very cool. Yeah, I feel we've been circling around this idea and we've touched on it via all of these topics we've talked about thus far and you opened with it as well and I asked initially. But having a more modern perspective on patterns versus what was being done traditionally, I guess at large, and also even in the web JavaScript space. What do you guys view as the biggest differences now, reflecting now that you've written the book? What are the most significant deltas? Addy Osmani: I think, one of the biggest realizations for us was, a decade ago, I and other folks first tried to do an interpretation of the Gang of Four book on patterns, which is one of the fundamental pieces of literature around this topic. In many cases, we were trying to translate what had already been done for Java and Python and other languages over to JavaScript. And in some cases, it made sense. In other cases, you had to squint and say, "Well, this looks really weird." And I don't know that we would actually use it in a production code base. Going through that process again, recently, we had that realization again. Well, some of these patterns just don't really quite make as much sense. And I think that was a healthy realization for us because it meant that we could tell people, "Well, here's what this pattern is. By the way, you can probably just skip over the rest of this article, but if you really want to read it, you can." And then, it allowed us to also acknowledge there are places where some patterns are still very widely used, even if via another library. So, for example, we talk a little bit about the observer pattern on the site and around forever. And these days, people who are using things like RxJS may not realize well, yeah, you're using the observer pattern there. Rx combines the observer pattern and the iterator pattern with collections to manage sequences of events. And I think it's healthy to understand how are all the different pieces you're using in your app today connected and what are those patterns? How do they come back to the foundations of how we used to build for the web? I think there's something interesting about that. Lydia Hallie: I think for me, the biggest difference was just to see, of course, I saw it from a more modern perspective. I think I started with ES-5. So, of course, I didn't really know even just the Syntax back then. But just seeing how much JavaScript has evolved and especially TypeScript, I'm so grateful for all the people working on the JavaScript engine, the JavaScript Syntax to make it so much easier for us. Addy Osmani: It's also really, I would say there's also really good having Lydia have that perspective coming into this. I come with a lot of baggage, unfortunately, how I built for the web. I have to remember back to the time when we didn't have modules in the language, we didn't have classes. And we had to think about required JS, common JS, AMD, all weird ways of structuring things. And being able to just kind of acknowledge that was a thing, let's throw some of it away and try to just encourage people to use what is now built into the language. I think that was healthy. Noel Minchow: Yeah. Yeah. I guess, I kind of agree, I think with the traditional approach of read the design patterns, the Gang of Four book and figured out it's kind of the same, I feel discussion has been happening on the proponents of really functional code for a long time. We're not really focusing as engineers. I think a lot of the time we're not focusing on problems that those design patterns were really written or prescribed to solve. We're focusing on something different now, especially again with how modern React and Vue are written. And, it's much more, I mean, reactive library, right? Well, I'm not really thinking about this in terms of objects like I would have of old. So, yeah, I feel that perspective and something a little bit more pragmatic is a really probably a worthwhile thing for devs that are just entering this space to understand. So, nice, nice. That's very cool. Is there any other kind of, I don't know, big or considerations you guys would implore people to think about when they're setting out for something new at large, just like starting a new product? They have functionality in mind. They want to build X, Y, Z app. How much thought would you recommend they give it beforehand in how do I architect this? What patterns do I choose to use versus just like jumping in and starting to build? Addy Osmani: I think that, especially in projects where you're going to be working with a team or you're going to be working with more folks than yourself, it's always easier when it's just you, because you can do whatever you want. But when you're working in a team, I think it's important to keep in mind readability. Patterns.dev design patterns, this whole space is all about trying to deliver better code or good code that can last a little while. And good code is a love letter from yourself to the next programmer or the other people on your team. The more you think about your code in terms of humans who have to read it and iterate on it and build on it, the better your code is going to get, because you're going to be thinking about the other people who also have to contribute to it. So, I think that leveraging your human language skills when you're writing code is valuable, that's another one of those places where being disciplined with patterns or just getting agreement in your team, like what are the two or three things that are important to us? What are the principles? What are the patterns we care about that can be valuable for the long term, just to make sure that your code has a chance of being maintainable to some degree? Noel Minchow: Yeah, totally. Yeah. That's kind of a good segue, I think, into my last area of questions here. I'm curious what motivated you guys to feel that you had the background, the knowledge to write this book and tell people what to pay attention to. How did you find yourselves there and what motivated you to write? Addy Osmani: I'll hand things off to Lydia in a second. I think that one of the challenges that I've always found with giving people guidance around architecture or patterns is that it can sometimes come across as very academic and very much like, "Here is the code, figure it out." Or "Here are the concepts, figure it out." And what was missing, I think, was being able to connect back to the audience a little bit better via interactive code, sandboxes and visuals. And that's something that I continue to believe was an amazing reason Lydia was able to bring so much to the project. When I first saw that she was doing all of these articles that were able to convey really complex topics in a simple way via motion, via animations, via really good descriptions, I saw an opportunity there for us to maybe be able to work together. And so, I think that has been part of why we thought we could maybe do a better job at this than some previous attempts. Lydia, I don't know. What do you think? Lydia Hallie: Yeah, no, I mean, for me, I was very excited about it because as I mentioned earlier, I have always been like, "Oh, you don't necessarily have to go to college to be a good software engineer. You can just teach yourself nowadays." And of course, we see this entire influx now of people that do the same thing, which is amazing. But most people and me included always have this thing, I know I don't know certain things, but I don't know what I don't know. And one of these things was patterns. So, being able to also teach myself as I was writing some of these articles, because of course, I had to kind of modernize some of the articles that were already written. I didn't even know that this was a thing, but now I do know. And of course, as I was teaching myself how to code back then, I used so many free resources that I just, I loved that I was able to also give back to those people that I feel I would've loved to read this, to have read this story when I was teaching myself how to code. So, being able to be helpful to so many new developers coming into the industry now and making sure that they are ready for everything, that they can create performance apps, that they don't feel overwhelmed when hearing all those terms. I think, yeah. I'm very grateful that I got to be part of that. Noel Minchow: Nice, awesome. Lydia earlier, you mentioned that when you were set out and were looking for, I think a specific, a design patterns book specifically. You found Addy's old book that was from 2012. Is that right? Lydia Hallie: That's right. Yeah. Noel Minchow: Yeah. And you're like, "That's probably a little bit dated at this point. It's not where I want to spend my time." Does that notion of, in the software world, everything's changing really quick, best practices, the tools that are available, something's dated once it's been on the shelf for six months, does that notion stress you guys out? Does it influence how you talk about topics? Addy Osmani: Yes, is the short answer. It's especially difficult, I think a long time ago, even in the past, people were using libraries and frameworks to build things. We had Dojo and Backbone and Angular JS and all these things. One of the difficulties writing about this space is that even within the Reacts world, things change every year to some degree. And being able to stay on top of, okay, well, where is the puck going while also acknowledging that most people are probably not going to necessarily be using the future for a while means that we have to continue delivering well on the current best practices, as well as keeping a tight eye on the future. And there is a little bit of stress intention that comes from that because we could say, "Well, you should do this today, but here is roughly what tomorrow's solution could look like." If that solution keeps changing, that means that our articles have to keep getting updated. Otherwise, we're giving people false guidance. So, I do think it adds a little bit of stress. It also is, I think a good invigorating factor for us to try staying on top of what's changing. And hopefully we don't do a terrible job of that at the end of the day. Lydia Hallie: Yeah. I believe by the time we were ready to publish, at least the website and the book, we already had to change some of the articles because they were already outdated or at least there were more modern solutions to it. Because I believe we spend a year and a year and a half. So, it was like, "Okay, this is just going to be a lifelong thing now. We're going to have to update this every month or something." But yeah, it's only good. I'm only happy that JavaScript ecosystem is moving forward all the time. It's a good sign. Noel Minchow: Yeah. It's an exciting space, for sure. I guess, yeah, with that in mind, you guys seem to have this understanding of how things are evolving, understanding the nature of that beast. What do you guys think the future looks like? Do you think we'll always be in this world of even the patterns that people are using to develop apps changing or do you think we'll eventually stabilize a little bit and they'll kind of be, well, we're maturing as an industry? Web dev in particular is kind of hitting this point where now it's a little less turbulent or do you think it'll always be a very iterative, just kind of turbulent space? Addy Osmani: I think that things are likely to get a little bit more opinionated as our understanding of the space continues to improve, especially now that the idea of opinionated web frameworks is more established. So, Next and Angular and so on. The opportunities for those frameworks to have more of an opinion, even if it's just in docs around some of these ideas, I think will help us stabilize a little bit further on the options. I do think it's going to, there are always going to be places where it's difficult to generalize for everybody and say, "Well, here is how everybody should be tackling state management." Here's how everybody should be tackling communicating between components." It's difficult sometimes to standardize on just the one way to do these things. And so, getting clearer and getting more alignment on the options or what has worked well, I think, will be a place of opportunity for the community. Noel Minchow: Cool. Cool. Yeah. I think so as well. And I feel it's interesting because it's slowing in some ways and changing more rapidly in other ways. And it is always just kind of, it's interesting to see, just reflect to me like, "Oh yeah, we've been doing this the same way for five or six years now. " But even the way we're, the preferred way of communicating data between components, like as an example, seems to still not be totally settled upon and maybe context driven and situational. But yeah, it's a fun space to be in like I said, for sure. I guess yeah, more broadly, what are you guys looking forward for the rest of this year, just in general in the tech space? What's on the horizon that you're excited about? Lydia Hallie: I think personally what I'm most excited about is of course the increasing edge, whether it's middleware or workers or rendering, just because it can bring so many performance benefits, speed optimizations to so many users all across the world and just different, yeah, as I said before, it's a different way of thinking about how you design your websites, which I think is very exciting and it's better to not have those [inaudible 00:37:44] that you often now have a service site rendering. You don't really have to think too much about, I guess the DevOps part as much anymore. So, that's definitely an exciting part. Addy Osmani: And I guess I'm excited about two small things. One is, new capabilities we've been bringing to the web platform for faster experiences. So, things like early hints, priority hints. Other ways for developers to basically try getting the resources needed for their pages to load and render fetched a little bit sooner. And then, I continue to be excited about the whole space that is GitHub Copilot, GPT-3. All of these ways of automatically writing code for you and how does that tie back to patterns? If those engines are relying on stack overflow answers, for example, how much of old patterns are they relying on for what they generate versus new versus good? I don't know. It's an interesting space. Lydia Hallie: We've got to manipulate Copilot, always use our pattern. Noel Minchow: Yeah. Yeah. Instill patterns in the machine. Think it, make it happen. Yeah. Yeah. Nice. Very cool. Well, again, I think we've covered a lot, and yeah, dove into a bunch. Is there anything you guys want to plug or point to listeners to as we sign off here? Addy Osmani: Check out patterns.dev, please. No, we've been very fortunate. I think patterns.dev just crossed to two and a half million people checking it out, which is really cool. Please check it out. Feel free to share the book. Everything is free and give us feedback. While some folks can say we're experts, we don't know everything. And so, we always look for opportunities to improve. So, feedback's welcome. Noel Minchow: Nice. How about you Lydia? Anything else? Anything outside of the book? Lydia Hallie: I was just going to, oh, outside of the book now I was just going to say, make sure to give feedback. And of course, if you have any ideas and patterns that we should add or frameworks that we should add, please let us know. Because of course, we wanted to make it available for all web developers, not just React developers. Noel Minchow: Oh, awesome. Cool. Well, yeah. Thank you guys so much for coming on and chatting with me. It's been a pleasure. Hopefully we can chat again soon maybe as you guys are working on updates and stuff. We'll have some fresh topics to cover. Lydia Hallie: Yeah. Thanks so much for inviting us. Addy Osmani: Sounds good.