Hey friends 👋 Today’s newsletter is coming a bit later than usual because this morning I made the questionable decision to attempt the Murph workout (key word: attempt), which unfortunately derailed my Sunday schedule.

If you don’t know what Murph is, just imagine 45 minutes of pain followed by 2 days of soreness throughout your entire body. So, you know, slightly less painful than reading some of my jokes.

Today we’re talking about the role of computer science in frontend development, the many great talks of React Conf 2024, and the new favorite framework of JavaScript developers, *checks notes*… Laravel?

Let’s dive in.

SOFTWARE DESIGN

Computer Science for Frontend Developers

From the creators of life-long existential questions such as “should designers code?” and “should backend developers know CSS?”, comes another of life’s mysteries that seems to be making the rounds these days:

Should frontend developers know data structures and algorithms?

There are plenty of people on both sides of this argument. Some say that computer science knowledge is worthless for frontend developers since it never comes up in the actual job, while others insist that you’re not a real engineer unless you can implement Dijkstra’s algorithm with your eyes closed.

There is a bit of truth on both of the extremes, but my advice is a bit more nuanced. I think every software developer would benefit from learning the fundamentals of data structures and algorithms, but that most people don’t need to go beyond the basics.

Let’s talk a bit more about that.

You Don’t Need To Know This Stuff…

Let’s start by exploring why some people think we shouldn’t bother with learning about data structures and algorithms.

To be honest, it’s hard to disagree with their argument because it’s true that our day-to-day jobs as frontend developers aren’t full of opportunities to use our hard-earned computer science knowledge.

There are a few reasons for this. The main one—which is why this is true of all software development in general—is that many of the most frequently used algorithms are baked into the languages and frameworks that we use.

If we need to sort an array, for example, we can trust that JavaScript’s native Array.sort() method already uses an optimized sorting algorithm, so there’s really no need to implement our own.

Same with a UI library like React or Vue. Since these libraries handle DOM diffing and updating, we don’t need to ask ourselves what’s the most efficient way to traverse the DOM tree—it’s already been handled for us.

Another reason why interview-like challenges are so rare in the real world, is that we don’t typically experience the drawbacks of slow algorithms at the scale of data we handle in the frontend.

Imagine we have a list of users and need to filter it based on some arbitrary query. Something like, I don’t know, whether they prefer to use let or const.

If the list is large enough (say, thousands of users or more), we could argue that the filtering should happen on the backend, probably as part of a database query.

And if the list is small enough for us to search on the client, then the choice of algorithm doesn’t really matter that much—we could filter it using the most inefficient searching algorithm possible, and it would still be pretty fast.

Either way, it seems like the opportunities to use the fancy search algorithm we spent so much effort learning are all gone… So why bother learning all of this stuff, then? Is it true that computer science knowledge is worthless for frontend developers?

Well, not exactly.

…Until You Do

Sometimes we really need to squeeze every last millisecond possible out of the code we execute on the client. In these cases, knowing how to optimize things using efficient data structures and algorithms can make our lives a lot easier.

A common use case is when we’re working with graphics or animations. If we’re building something like a game or an interactive chart using canvas, for example, we’d want any interactions and animations to run smoothly at 60 frames per second or higher.

This means that whatever computations we run during a rendering cycle (i.e. one call of the requestAnimationFrame function) must complete in 16 milliseconds or less, or we risk our animations looking all choppy.

Let’s say we have a function that searches through a large array and takes around 40 milliseconds to run. Normally, this run time wouldn’t be an issue. If we run this function as part of a click handler, for example, 40 milliseconds would still feel instantaneous for the user.

But if this same function runs on each animation frame, that’s a whole different story—it would make our animations look terrible.

Here’s where a bit of computer science knowledge can come to the rescue.

For instance, we could replace our large array with a Map or a regular JavaScript object where searches take a constant amount of time regardless of size. Implementing this is straightforward and only takes a few lines of code, but the only way to know about this optimization is by having some fundamental knowledge of different data structures beforehand.

Now, I’m not advocating for memorizing random facts and obscure algorithms just because we might need them once in a blue moon. Google and ChatGPT have done the memorization for us and can come up with the right answer on the spot.

The real value of the fundamentals, and why I recommend learning them, is that they can help us come up with the right questions.

A Super Simple Roadmap

All this to say that I stand by my original argument—even though learning this stuff is not strictly necessary, most developers would benefit from having some basic knowledge of data structures and algorithms.

So my recommendation is to spend some time learning the fundamentals… and then stop.

Specifically, what I mean by fundamentals is:

• Learning about Big O Notation. It’ll help you compare the performance of different algorithms and quickly distinguish the fast vs slow ones.
• Learning how to operate on basic data structures such as arrays, maps, sets, queues and stacks.
• Learning how basic algorithms like binary search and quick sort work. This will also help you grasp some concepts like recursion and dynamic programming, which might show up on your code from time to time.

Once you familiarize yourself with the basics, create a Leetcode account and try to solve a few problems.

Then, if you’d like to dive a little deeper, look into graphs and tree traversal algorithms, which might come in handy if you ever need to navigate the DOM by hand.

At this point, feel free to stop… or not! You might find that solving Leetcode challenges is actually pretty fun and you’d like to continue your journey down the rabbit hole. Choose your own adventure and do what feels right for you.

In terms of actual resources to learn data structures and algorithms, I have a few to recommend:

If you’re like me and you prefer the self-paced experience of learning from books, my number one recommendation is Grokking Algorithms by Aditya Bhargava (which, by the way, just recently published its second edition.) It’s a relatively short read and it’s full of illustrations and fun examples. The code snippets are written in Python, but they’re pretty easy to follow.

The classic Cracking the Coding Interview is also a good one. It’s a long book, and it goes much deeper than I’d recommend most people to go into this subject (unless you’re preparing for an interview, of course), but the first half of the book is a good introduction to this subject.

And finally, if you want to go really deep, you can’t go wrong with the popular college-approved Introductions to Algorithms from MIT Press. Don’t let the “introduction” in its title fool you, though. This book is massive and it explains the subject in much more detail than other resources out there.

If you prefer video, ThePrimeagen has a free and comprehensive course on Frontend Masters with almost 10 hours of content that starts with the basics and covers a lot of ground. He also has a shorter paid course on the same platform with some additional algorithms and more advanced content. I highly recommend both of these.

And if you prefer something a little less intensive, freeCodeCamp has a 5-hour course on YouTube that is also a great introduction and it’s definitely worth checking out.

ARCHITECTURE SNACKS

Links Worth Checking Out

📕 READ

1. Aditya Bhargava (author of the Grokking Algorithms book we just talked about) put together a really good collection of bite-sized TypeScript hints.
2. Learn all about queues in this fantastic interactive blog post by Sam Rose. I may or may not have spent the last 20 minutes playing with the interactive animations.
3. Adam Rackis wrote a deep dive about combining React Server Components with React Query for easy data management.
4. The React team put together a blog post recapping React Conf 2024, in case you don’t have two full days to catch up with all the talks.
5. Want to learn Laravel but don't feel like reading 1,400 pages of documentation? You're in luck. As I'm writing this, my friend and ex-coworker Josh is reading the entire Laravel docs on stream for us, so there's really no excuse now.

​

🎥 WATCH

​React for Two Computers by Dan Abramov

React Conf, Google I/O, Vercel Ship, and the apparently dozen other conferences that happened these past two weeks left us a ton of great talks to chat about. I’m slowly catching up with all of them (just 2,000 hours to go), but this one by Dan Abramov is one of my favorites so far. He came up with one of the simplest explanations of React Server Components I’ve seen, and in typical Dan fashion, he delivered it via a live coding demo from first principles. I highly recommend giving this one a watch, even if you’re an RSC expert.

​

🎧 LISTEN

​Laravel vs. JavaScript with Dax & Adam Elmore

For reasons I don’t yet fully understand, tech Twitter spent most of the past couple of weeks arguing about PHP (or more specifically, Laravel) vs. server-side JavaScript. In this crossover episode of the Mostly Technical podcast, Ian and Aaron from team Laravel are joined by Dax and Adam from the How About Tomorrow podcast to chat about PHP vs JS, what SST actually is, selling coffee from the Terminal, and much more.

That’s all for today, friends! Thank you for making it all the way to the end. If you enjoyed the newsletter, it would mean the world to me if you’d share it with your friends and coworkers. (And if you didn't enjoy it, why not share it with an enemy?)

Did someone forward this to you? First of all, tell them how awesome they are, and then consider subscribing to the newsletter to get the next issue right in your inbox.

I read and reply to all of your comments. Feel free to reach out on Twitter or reply to this email directly with any feedback or questions.

Have a great week 👋

– Maxi