Top 10 Recommended Books for Frontend Engineers

Hey there, frontend friends! Is “read more” one of your new year’s resolutions and 2024 is the year you’re actually going to stick to it? Well, you’re in luck! Here’s a list of 10 fantastic books to kick off your reading journey in the new year.

You’ll notice that most of these books are not frontend-related at all, which might seem like a mistake, but I promise you it’s not (I checked!)

I strongly believe that the key to leveling up your skills as a frontend engineer is to develop your technical breadth, and the best way I know how to do that is by reading books that sit right in your “stretch zone”—like these ones.

The list has books on software design, system design, architecture, performance, and more; so I’m sure you’ll find something that piques your interest.

Let’s jump right in!

• My Software Design Pick: A Philosophy of Software Design by John Ousterhout
• My Design Patterns Pick: Learning JavaScript Design Patterns by Addy Osmani
• My Software Architecture Pick: Fundamentals of Software Architecture by Mark Richards and Neal Ford
• My “Classics” Pick: The Pragmatic Programmer by Andrew Hunt and David Thomas
• My Web Performance Pick: Responsible JavaScript by Jeremy Wagner
• My Functional Programming Pick: Grokkking Simplicity by Eric Normand
• My System Design Pick: Web Scalability for Startup Engineers by Artur Ejsmont
• My Frontend Architecture Pick: Building Micro-Frontends by Luca Mezzalira
• My Programming Pick: The Rules of Programming by Chris Zimmerman
• My “New Book” Pick: Tidy First? by Kent Beck

I 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. A Philosophy of Software Design by John Ousterhout is 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.

This book is my favorite introduction to software design and software complexity. It has both practical and theoretical content, with code examples in Java to illustrate implementation details (although the concepts it covers can be applied in any language.)

“Wait a minute. Did you just say Java? I thought this was a list for frontend developers!”

Yes, I did say Java. And yes, I know that Java and JavaScript are not 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.

Similarly to the famous 2006 paper 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:

• Modules Should be Deep. Modules can (and should) pack a lot of functionality, but their interface should remain as simple as possible. This directly applies to components, views, routes, or any of the different types of modules we use on the frontend.
• Information Hiding and Information Leakage. A good abstraction should be obvious and hide unimportant details. This again applies to functions, components, classes, or even entire libraries.
• Different Layer, Different Abstraction. If two abstractions provide similar functionality but they operate at different layers of the system, that’s a red flag that could be causing your codebase to be more complex than necessary.
• Plus, a number of the later chapters in the book cover tips for commenting and documenting your code—a very important but often overlooked component of software design.

Finding the right abstraction for the problem you’re trying to solve often comes down to choosing the right design pattern. But with so many patterns to choose from, and implementations that vary widely depending on the programming language, this is easier said than done.

That’s why I was so excited to learn that Addy Osmani’s classic book, Learning JavaScript Design Patterns, was getting a second edition. The new edition has been updated to use the latest features of the language and includes some of the new patterns that have emerged over the past decade.

In about 260 pages, you’ll explore:

• The Classics: the patterns you might be familiar with from the Gang of Four book—creational, structural, and behavioral patterns.
• New and Updated: patterns for dealing with asynchronous JavaScript, plus updated sections for MV* and Modular patterns.
• Rendering and React-specific: including patterns for organizing React codebases and modern rendering patterns like Islands Architecture and React Server Components with Next.js.

If you’re looking for a comprehensive introduction to the world of software architecture, look no further than this amazing book by Mark Richards and Neal Ford.

Like most software architecture books, it doesn’t include a lot of frontend-specific content. In fact, there’s very little mention of the frontend at all. But don’t let that discourage you from picking up a copy of this book. This is one of my most recommended reads for software engineers of all kinds.

The book has three parts. Parts 1 and 3 cover the foundational concepts, techniques, and soft skills necessary to become a successful software architect. You’ll learn about architectural thinking, measuring architectural characteristics (e.g., scalability, maintainability, performance), and making architectural decisions.

These two parts of the book talk about architecture at a very general level, without focusing on any particular part of the stack. And because of how general and comprehensive the book’s definition of architecture is, it’s a great way to define what frontend architecture is as well.

Part 2 is the longest in the book, and it covers in detail a number of different architectural styles, such as layered, event-driven, and microservices. Depending on your level of exposure to backend systems, you might find this part a bit more challenging to consume. But if you can handle the discomfort of not completely understanding all of the concepts discussed in this section, reading through it is a fantastic way to increase your technical depth.

Back in my early years as a software developer, one of the books more experienced engineers would recommend to me the most was The Pragmatic Programmer by Dave Thomas and Andrew Hunt.

As a young and easily distracted UI developer I had waaay more important things to do (not really), but I ended up grabbing a copy of the book anyway. And… I didn’t like it very much.

So when the 20th-anniversary edition of the book came out in 2019, I wasn’t particularly excited about it. It took another round of recommendations from people I look up to for me to give the book a second chance. And let me tell you, I’m so glad I did.

It was clear to me now that my problem wasn’t that I didn’t like the book the first time, but that I didn’t fully understand it. So while I wouldn’t recommend it to someone who’s just starting out, I think it’s a fantastic resource for anyone who’s been building software for at least a couple of years.

The Pragmatic Programmer covers some of the most important tools in the software developer’s toolkit. For instance, tracer bullet development, which I wrote about in the past is one of the many subjects it covers. In no particular order, here are some of the topics you’ll find in it:

Duplication, Estimating, Version Control, Prototyping, Debugging, Decoupling, Concurrency, Refactoring, Naming, Reversibility, Domain Languages, and something called Orthogonality which apparently is a very important thing.

We’re not just playing developer-jargon bingo here. Understanding these concepts can play a big role in your career as a software engineer, and this book does a great job of explaining them.

The Pragmatic Programmer is one of my go-to reference books, and it has become one of my most recommended reads for anyone looking to level up their coding skills.

​Responsible JavaScript by Jeremy Wagner is my number one book recommendation for frontend developers who want to learn more about web performance. It’s a short book (around 180 pages), it’s fun, and it’s packed with valuable tips for making your websites faster.

The book talks about the very important role of JavaScript in performance and how shipping too much of it can cause sluggish experiences and inaccessible content. It doesn’t advocate for zero-JavaScript, but it does ask us to be more intentional about the code we ship to our user’s devices.

In its seven chapters, you’ll learn about:

• Strategies for shipping less JavaScript: code splitting, caching, using platform APIs.
• Measuring and assessing JavaScript performance: lab vs. field metrics, painting metrics, and measuring layout stability and main thread responsiveness.
• Optimizing load-time and runtime performance: how the browser’s main thread works and ways in which we can parallelize tasks.
• Managing third-party scripts: self-hosting, pre-connecting, and lazy-loading.

Plus, you’ll learn a number of interesting facts about different species of wasps. That’s right, wasps. If you’re wondering what this has to do with JavaScript performance, check out the book’s website.

Before finding Grokking Simplicty by Eric Normand, all of my previous attempts at learning about functional programming (FP) failed miserably.

Things usually started well, but as soon as the academic jargon and the code examples in Haskell showed up, my brain would immediately shut down.

Thankfully, this book is different.

Unlike many other functional programming books, Grokking Simplicity puts the mathematical concepts of FP to the side to focus entirely on managing software complexity. In particular, it explains how we can build better software by adopting two of the main ideas in functional thinking:

• Distinguishing actions, calculations, and data. Actions are procedures with side effects, like a sendEmail function or a deleteUser method. Calculations are pure functions (e.g., a sum(a, b) function) that will always behave the same no matter how many times you call them. Data is the inert component: things like objects, strings, or numbers. Identifying these and not mixing them up is one of the main traits of a functional programmer.
• Using first-class abstractions. This is about composition and using higher-order functions (passing functions to other functions) to reuse code in an organized way. This section of the book also covers working with timelines (e.g., handling asynchronous operations) and a discussion about reactive vs. onion architecture.

There is a lot I love about this book. For starters, it’s a practical book for software engineers, which isn’t the norm for functional programming literature. The book is also really easy to digest, thanks to the many illustrations and annotated code examples that make the content easy to follow. And, as a bonus for frontend engineers, the code samples are entirely written in JavaScript—so nothing will get lost in translation.

If you’re looking for a gentle introduction to FP, or want to learn new techniques for managing complexity in your applications, I highly recommend you check this one out.

You might be surprised to see a system design book in a list for frontend engineers, but I assure you this is not a mistake. In fact, Web Scalability for Startup Engineers by Artur Ejsmont is one of my favorite books to recommend to software engineers of all kinds, but especially frontend engineers.

I like to think of this book as the missing manual of web development. It’s a 300-page roadmap that will take you on a full-stack journey, from the initial user request to the database layer and back. If you’re a frontend developer looking to expand your backend and data engineering knowledge, this is the book for you.

The first half of the book covers concepts you might already be familiar with, such as building a frontend and API layer, an overview of web scalability, and principles of web development. You might be tempted to skip the introductory chapters but I’d highly recommend that you don’t—they’re well worth the time investment.

The second half takes us all the way to the backend, covering the data layer, caching, messaging queues, and searching. These are areas we don’t typically have a ton of exposure to as frontend developers, so I’m sure you’ll get a ton of value out of them.

Along the way, you’ll find that every concept in the book is marvelously explained with diagrams and practical examples. There is also very little code in the book, so it’s a truly language-agnostic resource. It doesn’t go too deep on any particular subject, but it’s a great starting point for choosing areas to focus on next.

​Luca Mezzalira has been writing and speaking about micro frontends for as long as the term has been around. You can learn a lot about this architectural style from the articles and conference talks he’s given over the years, but if you’re looking for a comprehensive guide, look no further than his 2021 book Building Micro-Frontends.

One of the core concepts in the book is the Micro-Frontends Decision Framework, which you can use to figure out which flavor of micro frontend architecture is right for your application. This includes deciding how to split your micro frontends (vertically or horizontally), how to compose and route them (on the server, client, or at the edge), and which methods they’ll use to talk to each other.

You’ll also find case studies, tips for introducing micro frontends to your organization, and strategies for making the migration from a monolithic architecture. It really covers a lot of ground, so I’m sure you’ll find it useful whether you’re using micro frontends today, or just want to learn more about their pros and cons.

The Rules of Programming by Chris Zimmerman was a really pleasant surprise. I picked it up earlier this year without knowing anything about it, and it quickly became one of my favorite technical reads of the year.

Zimmerman is a co-founder of the Sucker Punch gaming studio, so if you’ve played games like Infamous or Ghost of Tsushima, you’ve played with code written using these very rules. These are the rules his team uses to write simpler, more maintainable code; which I’d say is an important thing to do when building the massive pieces of software modern video games are.

Every concept in the book is explained with fun video game use cases and tons of code examples, which are written in C++. But don’t let that scare you—the book comes with a “Reading C++ for JavaScript Programmers” appendix with everything you need to follow along with the examples.

Here are a few of my favorite rules:

• Rule 1: As Simple as Possible, but No Simpler. I love that this is rule #1—writing simple code that is both correct and complete is our best tool for managing complexity.
• Rule 3: Generalization Takes Three Examples. You might know this as the rule of three—before creating a reusable abstraction, make sure you have at least three concrete use cases for it.
• Rule 7: Eliminate Failure Cases. When writing a piece of code, we can prevent user errors by making it impossible (or at least, very hard) to do the wrong thing.
• Rule 15: Pull the Weeds. Every codebase has those small issues that are easy to fix but also easy to ignore. Pulling the weeds regularly is a low-effort method for keeping your system in good shape.

And if you need an extra incentive to pick up a copy of The Rules of Programming, you should know that all of Zimmerman’s royalties from the book go directly to [Girls Who Code](Girls Who Code), an organization helping young women thrive and lead in the tech workforce.

Tidy First? by Kent Beck is the newest book in the list (it came out about a month ago), and it’s all about software design and the importance of making things easier to change.

The question in the book’s title comes from a situation we’ve all experienced before. We want to make a change, but the codebase is messy; should we tidy things up first? You can probably guess what the answer is: it depends, but the book does a great job of explaining what it depends on exactly.

Tidy First? is a very short read (less than 100 pages), and it’s packed with useful advice, organized into three parts:

• Part 1: Tyidings is a collection of mini refactors to make your codebase easier to deal with. These are structure changes that you can apply at any time, without having to set aside a big chunk of time to do them.
• Part 2: Managing covers how and when to tidy. It has some good advice for how to separate your structure changes from your behavior changes, and some helpful guidelines for deciding if you should tidy first, after, later, or never.
• Part 3: Theory is where the heart of the book is, explaining the value of software design from an economic standpoint, and how good design is one of the most effective tools for reducing the cost of software.

While the first two parts of the book are more practical, I found part 3 to be the more interesting one (and it’s where I took most of my notes.) This is personal preference, of course, but if you’re passionate about software design and like to dive into the origins of concepts such as coupling and cohesion, I can highly recommend Tidy First? as your next read.

Regardless of where you are in your frontend journey, I hope you’ve found your next great read in this list. Do you have any favorite books to recommend? I’d love to hear about them! Reach out on Twitter and let me know.

If you’re looking for more book recommendations, you should check out the Frontend at Scale newsletter. Every two weeks, I publish an original essay along with recommended books, talks, and other resources on software design and architecture tailored specifically to frontend engineers.

You can read the latest newsletter issue here, and subscribe to get the next one in your inbox using the box below 👇 (keep scrolling down!)

Happy reading~