ISSUE 1Hey Reader, Welcome to the inaugural edition of Frontend at Scale, your bi-weekly newsletter for all things software design, frontend architecture, and terribly bad puns. In today’s issue, we’ll talk about complexity, principles for scaling frontend applications, the risks or micro frontends, and… a philosophy book? Let’s dive in. SOFTWARE DESIGNIt's All About ComplexityWe should start by addressing the elephant in the room. No, not PHP; the other elephant—complexity. There’s a famous 2006 paper that speaks very eloquently to the importance of caring about complexity. Here’s a quote from the paper that I think sums things up pretty well: “Complexity is the root cause of the vast majority of problems with software today. Unreliability, late delivery, lack of security — often even poor performance in large-scale systems can all be seen as deriving ultimately from unmanageable complexity.” That’s a bit of a spicy take by 2006 standards, but the authors do have a point. When you think about the root cause of frustration in large codebases, whether is tech debt, maintaining legacy code, or making sense of undocumented features, it can often be attributed to some form of complexity. This immediately brings up another question, though: what exactly is complexity? We know it’s all around us, but how can we single it out? Can we see it? Can we touch it? Well, no, we can’t touch it. But we can try to describe it. The way I like to think about it is that software complexity is anything that makes the system harder to change, harder to understand, or both. For frontend systems in particular, this could mean an inconsistent folder structure, lack of documentation, disorganized state management, or a combination of all of those. This is a general definition, of course, so we can’t use it to measure complexity in any way. And if we can’t measure it, how do we know if we’re doing a good job at managing it? To answer this question we need to go one level deeper: if we want to learn how to manage complexity, we have to get better at recognizing its symptoms. Symptoms of ComplexityStanford Professor John Ousterhout wrote an entire book about this—A Philosophy of Software Design (we'll come back to this book later in the newsletter.) In his book, Ousterhout describes three ways in which complexity typically manifests itself:
Paying attention to these symptoms will help you identify when complexity starts to creep into your codebase. Because, make no mistake, complexity is actively conspiring against you, and is very, very sneaky. Nobody sets out to build a complex system from scratch. But as time passes, more teammates join the team, and more features are added to the product, complexity slowly but surely finds its way in. If you let it grow unchecked, at one point someone in your team will inevitably say the four words engineering managers fear the most: “We need a rewrite.” I hear you, frustrated developer. But a full rewrite is a massive endeavor, and almost never the right solution. Also, we don’t want a stressed out manager, do we? Let’s not do that to them. Instead, here are two questions you can ask yourself to help manage or eliminate some of that complexity from your codebase:
You might be familiar with camping rule of “always leaving the campsite better than you found it.” If you find a mess in the campsite (or codebase, in our case), you clean it up, no matter who made it. No git blame allowed. Asking ourselves these two questions will help us stick to that rule. But my favorite thing about these questions is that they bring us all the way back to our definition of complexity. When we optimize for change and make the system easier to understand, we’re not just treating the symptoms, we’re attacking complexity directly at its roots. WATCH LISTPrinciples for Scaling Frontend Application DevelopmentMalte Ubl, CTO at Vercel and former Principal Engineer at Google, gave a talk at React Summit earlier this year sharing his principles for scaling frontend applications. Given that you’re reading a newsletter that is literally called Frontend at Scale, I’m going to go out on a limb here and say that you might find Malte’s talk interesting. I won’t spoil the talk for you because I hope you give it a watch, but I will share my two favorite principles:
ARCHITECTURE SNACKSLinks Worth Checking OutBOOKSHELFA Philosophy of Software DesignI know a book with “philosophy” in its name might have caused you to tune out immediately, but in case you’re still reading, I promise this one is worth checking out. It’s a short book (~180 pages), and it’s a relatively light read, free of most of the technical jargon you’ll find in other books of its kind. If my earlier ramblings about complexity were of any interest to you, this book is the best resource I can recommend to explore the topic further. The code examples are in Java, but the concepts are universal and can be applied in any language. “Wait a minute. Did you just say Java? I thought this was a frontend newsletter.” Yes, I did say Java. And yes, I know that Java and JavaScript are no the same thing! (I think.) But the book is more about software design at a high level, so there really isn’t too much code in it. If that still sounds too intimidating, you can do what I do: squint your eyes a little bit, and pretend the book is written in TypeScript. Just like Out of the Tar Pit, A Philosophy of Software Design is based on the thesis that complexity is the root of all evil. But the book takes things a bit further, saying that managing complexity is the most important part of our jobs as software designers and engineers. Whether you agree with that statement or not, I’m sure you’ll find the strategies covered in the book useful. A few of my favorites are:
|
113 Cherry St #92768, Seattle, WA 98104-2205 |
Get the latest articles, talks, case studies, and insights from the world of software design and architecture—tailored specifically to frontend engineers. Delivered right to your inbox every two weeks.
Read it on the website ISSUE 10 Hey Reader, I have some exciting news to share before we start—Frontend at Scale has officially reached 1,000 subscribers 🎉 This is absolutely incredible to me, and I cannot thank you enough for being part of this journey so far. Whether you’ve been reading my ramblings from the very beginning or you just joined us last week, I want you to know how much I appreciate you hanging out with me every two weeks. If you enjoy the newsletter, the absolutely best way to...
Read it on the website ISSUE 9 Hey Reader, I hope you had a fantastic week. Mine was great—I took some time off work to enjoy the beautiful California woods with my wife and kids, which was a much needed rest but also the reason there was no Frontend at Scale last weekend. I hope you didn't miss the newsletter too much 😊 Today I'm flying out to NYC for this year's React Summit US. I'm super excited to hang out with the nice folks from the React community and to give my talk, The Messy Middle,...
Read it on the website ISSUE 8 Hey Reader, Do you have plans for this upcoming Friday, October 27th, at 9:30am Pacific? Work, you said? I'm not entirely sure what that word means, but I hope you can make some time come chat about application design in Astro with Ben Holmes and me on my Twitch channel. This is the first of what I'm hoping will become a series of talks on frontend architecture and software design with different framework authors and experts, and I couldn't be more excited to...