​

​Hey there,

I hope you're having a great week. If you are, it's about to get even better! And if you aren't, well, hopefully a few minutes of my rambling can lighten your mood 🙌​

Let's go:

1. Commenting Code

Since the beginning of time (or, like, the beginning of programming languages at least) we've been able to comment our code.

Comments are a pretty simple idea: Just a way to write "normal" language inside your source code. I think most people would agree that this can be useful at times - but there's also groups of people that are completely against code comments all together. So let's talk about it!

As with everything in programming, "best practices" is a balance. There's never a definitive answer, no "silver bullet" that applies to every single situation. There are good comments, and there are bad comments. And bad comments are often worse than no comments.

Here's an example (simplified, but you get the idea):

​This is what I would consider a "bad" comment: it doesn't tell us anything the code doesn't already tell us. And, at worst, the comment is lying if we later change the code but forget to change the comment!

Another example of a bad comment could be to explain something that could be explained by simply making the code more descriptive:

In this scenario it would be better to make the code more self-explanatory, to eliminate the need for a comment:

But of course these few examples doesn't mean you shouldn't ever use comments to document your code (like some people might have you believe that all comments are bad 😱)

In practice, there's plenty of cases where you simply can't make the code explain itself. Or where you have to implement some complex logic that is much easier to reason about with 1-2 lines of normal language to explain the context.

In any case, you'll always have to use your best judgement - just remember that it's not black and white. So if you encounter someone saying "comments are a code smell" or, on the contrary, if you notice yourself overcommenting stuff that really should be refactored, try to take a step back and evaluate the individual case by itself.

Yes, in an ideal world we all write perfect code that is crystal clear to anyone reading it and doesn't require comments. But that's just not how reality works.

My own personal take is that comments should always be helpful rather than distracting. So if you can save someone (or your future self) time by documenting a function or line with a quick note - you should do that. Comments aren't inherently bad as long as you use them effectively ✌️

​

2. GitHub Copilot stats

In case you haven't heard: AI is all the rage right now, especially in programming. With tools like ChatGPT and GitHub Copilot, developers can focus on more interesting problems and less on memorizing correct syntax. But just how big is GitHub Copilot actually?

Well, in a recent blogpost (by GitHub), they quoted the following numbers:

​Which is just bananas. It's unclear exactly how they came to these numbers, but it's likely measured from people who actively use Copilot (and of course not 46% of all code written globally is by Copilot). It's also worth noting that these numbers are from an article that pitches Copilot for Business - so it's obviously part of a marketing effort as well.

Regardless of the exact figures, I can confidently say that Copilot has helped me in my day-to-day coding tasks. Especially with more repetitive tasks like generating mock data or scaffolding out the starting point for a component.

How about you? Have you tried Copilot yet, and what do you think of these numbers?

​Read the full article for context​

​

3. Optimistic UI with Remix

Switching gears: a common problem in front-end development is to keep your server state (that is, the data that is saved in a database) equal with your UI state (the HTML/CSS/JS parts of a website). For example, if a user clicks a button to create a blog post, you don't want them to wait until that data hits the server and the server responds saying the blog post was successfully created.

Most of the time you *know* that the operation will go well. And in order for the UI to feel snappy and avoid that latency while the server does its thing and responds, we can implement something called "optimistic UI". Basically it's a way to update our UI instantly - while still dealing with errors later if the operation doesn't go as we expected.

Ryan Florence, one of the creators of the React framework Remix, breaks it down really well in this video - including how to handle these optimistic UI updates with Remix specifically:

​

Did you enjoy today's newsletter?

​👍 Yes, it was amazing!​

​😐 Eh, I guess it was ok​

​👎 Not really at all​

If you did, I would really appreciate if you could share the newsletter with your friends! Either by forwarding this email, or by posting about it on Twitter, LinkedIn, or Facebook. You can also simply copy/paste the link mads.fyi/top3 on other platforms. It really helps to keep me motivated and let the newsletter grow

— Mads Brodt