Notes

In recent months, I’ve struggled to find a name for a concept that kept popping up in my head, and Matthias found it for me in his piece: cognitive debt.

If you create a piece of work yourself or together in a team, your brain learns and remembers important aspects of the work and your decisions. If you use an LLM to generate it, all that learning doesn’t happen and so it takes individuals and teams much longer to actually understand what’s going on.

A very deep, hands-on dive into the inner workings of React. It covers all necessary topics including reconciliation, concurrent rendering, fibers, hooks, etc., and explains them while reimplementing the core of React using simplified code.

While the post presents an entirely new ID format for specific needs, it also nicely summarizes the available ID format options, along with thoughts on where each of them is useful and where they fall short.

If you’ve got a single database and no plans to shard, use auto-increment. If you just need uniqueness and don’t care about ordering, UUIDv4 is fine. If you want time ordering without coordination and moderate concurrency is good enough, go with ULID or UUIDv7.

Yet another CSS reset. This one is quite modern. It might be opinionated, but it provides solid reasoning behind the choices.

I’ve been eyeing Jujutsu for quite some time. I need to give it a try. One day. (sighs)

This post demonstrates how Tangled uses Jujutsu’s change-ids to streamline the code review process in an evolving merge request – something I’ve been pondering for some time myself.

The mixture of discussions, new commits, amended commits, and rebases, makes code review messy in traditional tools such as Gitlab, and this seems to make it really streamlined.

Well, one day 🤞

There used to be a time when Sass was priceless. It has been my go-to choice as well, and it has been so for ages. But CSS has come a long way – it now has custom properties, supports nesting, and will likely get conditions, functions, and even mixins soon. And it lives in a mature ecosystem with features such as CSS modules that help with code organization.

I wholeheartedly agree with Jeff’s conclusion there:

So what is my verdict — is it time to un-Sass?

Please don’t hate me, but my conclusion is: it depends.

I wouldn’t blindly jump into rewriting an existing, sizeable codebase from Sass to CSS. But for projects on the smaller side, and definitely for new projects, I believe CSS is already more than capable.

This post is music to my ears. It essentially conveys the same message I’ve been presenting in a talk called ‘Keep yourself DRY.’ We are obsessed with deduplicating code into abstractions, but abstractions often don’t age well:

Each new requirement made it slightly worse, but never quite bad enough to refactor. It’s death by a thousand parameters.

Having said that, it’s also quite difficult to design good abstractions from the beginning. As Matheus says:

The right time to abstract isn’t when you see duplication — it’s when you understand the pattern.

And if you do abstract early and only later a different pattern emerges, do not be afraid to break the abstraction down and put it back on the drawing board.