"Good code is a love letter from yourself to the next programmer you're handing that code off to."
In this episode, we talk about using design patterns to improve how you architect web apps, with authors of the book, Learning Patterns, Lydia Hallie, Staff Developer Advocate at Vercel, and Addy Osmani, engineering manager at Google working on Chrome.
Ben Halpern is co-founder and webmaster of DEV/Forem.
Ridhwana Khan is a senior software engineer at DEV
[00:00:00] AO: In many ways, they allow you to improve readability. So fundamentally good code is a love letter from yourself to the next programmer you’re handing that code off to or the next person you’re working with your team on that code.
[00:00:23] BH: Welcome to DevDiscuss, the show where we cover the burning topics that impact all of our lives as developers. I’m Ben Halpern, a co-founder of Forem.
[00:00:31] RK: And I'm Ridhwana Khan, Lead Engineer at Forem. And today, we’re talking about using design patterns to improve how you architect web apps with the authors of the new book, Learning Patterns, Lydia Hallie, Staff Developer Advocate at Vercel, and Addy Osmani, Engineering Manager at Google working on Chrome. Thank you so much for being here.
[00:00:50] LH: Yeah. Thank you so much for having us.
[00:00:52] AO: Excited to be here.
[00:00:53] BH: We both had you on the show in the past, but let’s get a little refresher on your developer backgrounds and sort of catch up with what you both have been up to lately. Lydia, why don’t we start with you?
[00:01:04] LH: So I recently joined Vercel as a staff developer advocate. After five or six years in engineering, I felt like it was so fun to also use my visualizations in which I was actually on the last podcast that I was with you guys. I was talking about that to teach like advanced developers that already have a lot of experience with React, how to improve their applications, improve what performance and build even better applications.
[00:01:29] RK: And Addy, can you give us some cliff notes on your background?
[00:02:16] SY: So you both came together to write this book about design patterns and their importance. I think Addy, you sort of just spoke to this, but do you want to elaborate on the impetus for writing this particular book right now?
[00:05:00] RK: What would you say is the audience for this book?
[00:06:30] BH: How did you two go about dividing and conquering and ultimately creating the content of the book?
[00:06:37] AO: I would say that the good content in the book is by Lydia and everything else is by me.
[00:06:43] LH: We definitely disagree. Most of the good content definitely comes from Addy. No, I read through his book that he wrote in 2009 and I kind of tried to identify the patterns that I felt were still useful. Now from like a modern perspective, is it worth translating this into a modern implementation? And as I was reading it, I tried to create the visualizations for it to make sure that I understood the patterns correctly. And then Addy reviewed it and he rewrote most of the texts to fit the modern ES6 implementations.
[00:07:13] AO: We also had help from a few other folks who’ve been great at contributing technical editing and so on. I would say that one of the really exciting things about getting to work on this together was even having side conversations about like, “Is this thing actually still relevant? And if you happen to be using React or you happen to be using something else, what would it actually mean to use this pattern in that context?” So that was kind of cool.
[00:07:35] RK: So I noticed that there are some React patterns that you cover in the book. Do you feel like the audience needs to know any React before reading that portion of like design patterns that are applicable to React?
[00:07:51] AO: If we’re talking about anything React specific or Next.js specific, there’s a good intro chapter to the topic. So yes, it always helps if you have a little bit of background in the library or framework we’re talking about, but you should also be able to catch up if you don’t.
[00:08:08] RK: And why do you feel that design patterns are sort of a vital part of building any applications?
[00:08:15] AO: My perspective on this is that design patterns give us a common vocabulary to talk about software design, and that’s always been like one of their biggest values. I think that the analogy that I always like going back to is one by Mario Cervera, but he asks, “Can you imagine an architect is discussing a house only in terms of bricks, walls, doors, and other kinds of low-level terms?” It will take forever to describe a basic house. And so architects use this idea of room patterns, like a bedroom or a bathroom or a kitchen. And that allows us to convey an awful lot of information with very simple sentences, like a two-bedroom, one-bathroom house. I should also say that one thing we’ve tried to stress a lot in the site is patterns are valuable for solving specific problems and they are descriptive, not prescriptive. So if you don’t have the problems we talked about, you shouldn’t use them. They’re not like a blunt tool.
[00:09:10] BH: So you are describing a lot of patterns for general maintainability, success, user experience, all the goals of creating effective web apps. But of course the website says a focus on performance, it’s right up there, but it’s not the first thing. You’re known for that. Wondering what the approach and the thought was about maintaining the importance of performance and then the context of a book that doesn’t have it as the title or the top line and that sort of thing.
[00:09:43] AO: So the impetus was sometimes the patterns that you ended up choosing for composing your application can have effects that aren’t necessarily obvious at the very start. And so if you end up producing something that you're going through a tool and it’s going to generate some output, if the DX of your overall experience and the maintainability of ability of your code is good, the outcomes are actually not so good for the user, that’s not great. And so we wanted to emphasize that while maintainability is really important, so is everything else that’s involved in getting pixels down to the user at the very end. And so the book is kind of, as I mentioned, like separated out into these three sections. Design patterns are at the very start because that’s kind of the offering time experience. Right? You’re like writing your components, you’re writing your app, and then we take you through the other areas of performance and rendering because those are concerns that you can think about later and then try to figure out, “Okay, well, how do these connect back to the maintainability side of things?” But we did feel like strongly, there’s more to it than just the offering.
[00:10:45] LH: I also think that once you read the actual patterns, you’ll quickly figure out that it is about performance. We do mention the effects that they have on your web performance pretty frequently.
[00:11:15] BH: Lydia, when it came to achieving some of the visualizations, what was the process when it came to performance stuff? What did you try to hit in terms of effectively describing performance concerns through your visualization style?
[00:11:32] LH: I try to visualize the steps that even like the script it goes through or just a network request in general, like those very basic things in performance, but that might be pretty hard to grasp if you don’t have a clear kind of mental image of what it really means under the hood. Like why is a large bundle affecting my performance negatively? What’s time to first byte mean? How can I even improve time to first byte? Like all those core web vitals that I feel like it was useful for me to visualize that, “Okay, time to first byte, that’s just the initial request to the server.” And when you split that up into smaller chunks, you just see that bar moving more towards the start. And of course, it was pretty difficult to visualize this in a way where I feel like everyone would understand it, even people that might not have this experience or this background and performance. But for me, personally, I try to make it in a way that when I just started coding, it would have made sense to me. I tried to create the visualization that I personally missed or about stuff that confused me until I wrote the book. So I mainly just created it for myself, but in a way that I felt would benefit everyone.
[00:12:39] AO: One of Lydia’s superpowers is being able to take really complex nuanced topics and break them down in a way that everybody can understand really well. That’s one of the things that drew me to her work in the first place. It’s like, “Wow! I would normally be writing a very long article about this topic and I don’t think most people are going to actually read through the end.” She’s able to convey concepts in less than 20 seconds in a video and get that across really, really well. I think that that’s also a super power she’s brought to the book.
[00:13:06] RK: You just answered my next question. I was just going to ask, because I found the book like exceptionally clear. It explains concepts really well. It shows them really well. How do you get from a point where some things are like difficult to wrap your head around, but then you get to this clear guide for patterns?
[00:13:25] LH: I mean, it’s certainly very difficult to explain something in a very simple way. Initially, you might think like, “Oh, to explain something in a simple way, you just need the basic knowledge,” but it’s actually the opposite. You need to know pretty much everything in order to explain something to a five-year-old, but then really understanding like, “Okay, but what are the real problems here? What are we really trying to solve?” You often end up with just like a bullet list of maybe three items and just trying to tackle these ones is usually the way that I work. And it’s also very relatable, like trying to create a relatable article, like, “Okay, but why does this affect performance?” Like, “Why is this the output when I do this?” Just questions that I personally have as a developer that a lot of the time when I’m reading a technical blog post, I feel like the author doesn’t always mention those things, or they just explain it from a very kind of technical viewpoint, which doesn’t always make sense as a reader. I don’t want you to assume things. I don’t want to fill in the gaps or the blanks. I want to have a very clear article that explains everything in a very simplified way or simple way, but not simplified.
[00:14:29] RK: So it sounds like you do a ton of in-depth research to understand everything and then just summarize it in a minute trade, two-minute trade. It’s amazing.
[00:14:41] LH: Yeah.
[00:14:42] RK: So talk about how learning to implement traditional as well as brand new patterns in a modern way can help you improve your applications on many different levels. Can you talk a little bit about why and how that is?
[00:14:55] AO: My perspective on why it’s valuable to get a little bit of a background in patterns is that in many ways they allow you to improve readability. So fundamentally good code is a love letter from yourself to the next programmer you’re handing that code off to or the next person you’re working with your team on that code. And the more you think about writing your code is if a human has to execute it, the better your code is going to get. I think patterns are one of those places where we can lean into a lot of prior experience in trying to make things readable and maintainable rather than necessarily like reinventing the wheel. You always have to approach these things with pragmatism, but I think that trying to take advantage of all the lessons other people have learned over the years is just really valuable. And I guess on top of that, patterns are also useful when you have a specific problem, like you’re trying to refactor your code. They give you in many ways like a refactoring target. So you might detect problems that could be solvable using particular patterns. In that way, they can give you kind of guidance and direction about roughly where you might want to land.
[00:16:01] RK: It’s going to stick with me that good code is a love letter to a team member. I really like that.
[00:16:06] BH: Can we get into a few design patterns described in the book, ones that stand out as most important for listeners who might want to get a gist of something so that they know what to expect in the book?
[00:18:50] AO: I guess another aspect of this that’s interesting, a lot of the abstractions people are using to write web applications today have got their own design patterns now. That wasn’t something that you had to think about too much back in the day. And so if you’re using React these days, you probably need to think about hooks or higher order components or other ways of structuring your code. And we wanted to make sure that the book was still not ignoring that. That was the thing. So we tried to touch on some of those topics as well.
[00:19:39] AO: I would say that on the language side of things, it was really interesting to see how much the need to solve a problem and kind of user land on your own, disappeared with modules, classes are contentious, like some people are really into them, some people are not. And so you see a little bit of discussion around that topic. Patterns like the observer pattern, which were something people heavily used even 10 years ago, you now might be implementing it yourself. You might be using our RxJS. And so just trying to map patterns to the modern landscape I think was an interesting exercise for us. You also asked about, “What are other things that have changed in the browser or in the platform?” I would say, and this is my own biased perspective, but I would say that one of the biggest challenges for delivering a good user experience these days is resource prioritization. So making sure that you’re getting files down the wire and execute it in the browser in the order that you, the developer, intended. This is something that there’s still a big education gap around, like very often we’ll like structure a page. If it renders okay and kind of feels it’s done, we just ship it. But that can mean that really key resources. So if your branding is really important, if your logo is really important, that’s your probably load early on. If people are going to interact with your page, the scripts for that should probably be loading early on, the same for your hero images and things like that. So on the platform side, over the years, we’ve gotten features like link REL preload, more recently priority hints. Effectively, just like levers that allow you to change how the browser is considering the importance of resources, I think that was important. And so getting that kind of base and how should we load and render things. I think that’s going to be useful to folks if they haven’t read too much on this topic before.
[00:21:45] RK: For both of you, I’m curious to know which was the most complex pattern that you needed to implement into a more simplified description or even an animation.
[00:22:49] LH: Yeah, I think I would agree, especially now that I work at Vercel, I work with a lot of Next.js developers. I’ve worked with Next pretty much my entire dev career almost. There were so many rendering patterns of way of rendering. And of course, they started or back then started as just SSR and they slowly moved to SSG. And I still see a lot of frameworks nowadays. Also, just use one singular pattern initially and then they usually figure out that that doesn’t really make sense as an app scaler as they grow. So writing about the current limitations of even very popular and performant patterns was sometimes pretty difficult.
[00:23:28] RK: So you answered what was like one of the more complex patterns that you needed to implement. Tell me about the pattern that you feel is the most used pattern in everyday code. Which one do you use the most in your everyday coding?
[00:23:43] LH: I mean for me, besides like the module pattern, which isn’t necessarily a pattern that most people have to think about nowadays, since it’s just an ES6 feature, there’s also like the hooks pattern, which a lot of React developers nowadays either move to from class components, or like new React developers, they usually only use the hooks pattern and it’s also useful for them to see like, “Okay, but why were hooks introduced? What was the problem that hooks or what is the problem that hooks are solving in most cases? And why are there still some people against the hooks pattern?” That definitely gives a lot of developers, whether you’re new or advanced, a lot of background information.
[00:25:30] AO: I think that a valid criticism is that very often if you’re jumping for a design pattern without understanding the context where it’s trying to help solve a particular kind of problem, you can needlessly add complexity. Nobody should be going into like, “Hey, I’m going to go build an e-commerce app tomorrow. I’ve got to use the hooks pattern, the container pattern, and the proxy pattern. Otherwise, I’m not going to get funding.” That’s not how to think about patterns. Identify what problems you’re trying to solve. One of the things that we tried hard with this book to do was capture the pros and cons. Like, “What are the good places where this pattern makes sense and what are the places where it doesn’t?” And so hopefully, we’ve done an okay job of that, but I think we could probably continue building on that base. As a general rule, keep code simple. Try to make it easy to read and maintain by other people. Design patterns can be really powerful, but use them when it’s clear that they have value.
[00:26:22] RK: Can you talk about some of the tips and tricks or patterns that you have in the book that you think would be the most useful to help folks improve on how they architect their apps? So if they had to read like just a couple of sections in the book, what would be the most go-to patterns that you would encourage them to read first?
[00:26:45] LH: Personally, I would say read the rendering pattern section. I think the way that people render their data, whether you’re using a framework or you’re just using React like standalone, it affects not only the user experience, but also to developer experience. It can highly affect how your business is going to work out as your project grows. Or if it goes viral, can you handle all the bandwidth, all that stuff? Especially when you do a Google search or you’re in Tech Twitter, you’ll often see terms like CSR, SSR, ISG, ISR. You get thrown with all these abbreviations and it might not always make sense and then people’s opinion on it as well. So I think just reading those patterns and then identifying like, “Okay, these are the use cases for my project. Am I currently implementing that?” Can already improve both, yeah, like I said, your own experience as a developer, as well as your user experience almost instantly.
[00:27:34] BH: Can you talk about the decision to make the book totally free and available or no money?
[00:27:41] AO: With the first book, it actually started out as an open source project. And by the way, I’ve never intentionally written a book. I’m just really bad at keeping articles short enough. So they start off as an article and then just keep getting longer and longer and longer. I started off with an open source book on GitHub, and then this was for like the version 10 years ago. And then O’Reilly reached out to me and were like, “Hey, do you want to turn this into a real thing?” And an important part of the deal I had with them was, “Sure, but we have to keep this open. We need to make sure that everybody can access this.” And this idea of open access to books is I think really important. It expands our ability to include a lot more people who are on this journey of trying to improve their programming skills. And I have myself a lot of critiques of the original book that was written, but keeping it open allowed, I think based on the analytics, like 5 million people to read it over the years and that was just mind blowing to me. It was like, “Oh my gosh! This is really, really cool.” And we wanted to make sure that if we were doing a more modern version of this book, that we were being just as inclusive. We want everybody to be able to access it and take advantage of the content. Another benefit of that is we’ve seen lots of people filing feedback and ideas and helping us improve it. And so I think that open model has a lot of value to it.
[00:28:55] LH: I would completely agree. And as an author of the book, I am still getting so many other opportunities or just positive feedback from it that I value a lot more than just having that money.
[00:29:08] RK: I really loved that and I really loved the book. And so my follow-up question here is what do you see is the next project for the both of you if there is one?
[00:29:20] AO: I think a big piece of feedback we’ve had is, “This is cool. Are you all going to do a version for other frameworks or other parts of the ecosystem?” And so I would say the top of that list in terms of feedback has been Vue.js. There’s been a lot of evolution in the Vue community over the last couple of years from the shift from Vue 2 to Vue 3. And so we’re really excited about that the next part of this project being focused on Vue. So what are Vue design patterns and how do we interpret all these patterns through that lens? No dates just yet on when that’s going to be available, but that’s the next big thing we’re hoping for.
[00:29:56] LH: We might also already have to rewrite or at least update some of the articles as they’re already outdated, some of them, or at least there is a simpler way of implementing them. So there’s probably just going to be a lot of maintenance as well.
[00:30:10] RK: Oh, we're super excited about whatever’s next and I’m pretty sure the audience is as well.
[00:30:16] LH: Thank you.
[00:30:17] BH: How do you get over any possible paralysis from the notion that these are going to get out of date and like trying to future-proof? Where do you land on that? How do you go about doing that knowing that things get out of date so quickly in this world?
[00:30:33] AO: We have a weekly call where we just cry into our terminals and console each other. To some extent, it’s very difficult to keep any technical, like educational content as up to date as possible. So we’re always trying to do our best job. I think one of the benefits of especially Lydia at Vercel, being relatively plugged into the ecosystem and how trends are going, we’re usually just a little bit ahead of the curve, I guess, in terms of knowing what direction the winds are changing. And so that allows us to make sure that the content is updated or we’re at least talking about, “Hey, there’s a big change coming. Maybe we should just make sure our guidance isn’t way out of date.” I guess being proactive about that is an important part.
[00:31:15] BH: And is there anything else we haven’t covered that you two would like to speak to?
[00:31:20] AO: Check out the book. Please feel free to leave us feedback. It’s also available on all of the various app stores for free. So Google Play, Apple Books, all those places. Reviews, always welcome, also free. So feel free to give them.
[00:31:36] RK: Awesome. Thank you so much, Addy and Lydia for joining us today. It was great to have you on the show.
[00:31:42] LH: Thank you.
[00:31:42] AO: Thanks for having us.
[00:31:52] BH: Thank you for listening to DevDiscuss. This show is produced by Gabe Segura. Our senior producer is Levi Sharpe. Editorial oversight by Jess Lee, Peter Frank, and Saron Yitbarek. Our theme song is by Slow Biz. If you have any questions or comments, email [email protected] and make sure to join our DevDiscuss Twitter chats on Tuesdays at 9:00 PM Eastern Time. Or if you want to start your own discussion, write a post on DEV using the tag “discuss”. Please rate and subscribe to this show on Apple Podcasts.