please tell me "why"

nibtime — Sat, 13 Mar 2021 02:06:57 +0000

I am currently in a phase, where I am sort of reflecting on my past 1,5 years of web development. I am trying to see how things went and what decisions I could make to improve.

Sometimes, thinking about what libs and frameworks to use is so hard. There is so much abundance, it is overwhelming. And it just keeps growing.

I just read this tweet from Dan Abramov:

"Hell is other people's abstractions"

Made me laugh. It is just so true 😂.

Committing to fundamental abstractions is one of the things I believe one needs to be most careful about: you will literally get used to thinking in them. I still mourn about the many people who were sold into one of the biggest hoaxes of computer science: "inheritance for code reuse" - The 3 Amigos made some decent cash by selling dogs that "woof" and ducks that "quack".

I decided for myself, that from now on I will only try out and possibly commit to abstractions if I can see a strong "why". I need to see strong reasons, conceptually, that something is a really good idea. Minimalism and low-key are not just nice, but an absolute must-have.

I was happy to see, that there can be libs that fulfill my ideals when I discovered jotai and zustand for React state. On the very first time I looked into them, I was able to infer this "why". I was able to project into the future, if I write code like that, the experience of doing so will be pleasant and things will turn out well.

When I looked into Redux it was more like: "Yeah, I get it, it's by no means bad engineering, but I can't see a possible reality where I write code like that." 😅

I wish, that docs would focus on this "why" aspect more often. Usually, they only tell you "how". There's the obligatory introduction (like the counter sample) and then there are recipes of various sorts.

But the "how" is only interesting after you committed to the abstraction. Outside the "mental box" of the abstraction, it has no relevance. The "why" is important to decide whether to step into this "mental box" or not.

Docs rarely provide really strong and convincing support for the "why" (if they do, instant trust explosion). So please tell me "why" more often 🙏.

avoid the "death by a 1000 cuts" performance problem with jotai

nibtime — Wed, 10 Mar 2021 17:27:12 +0000

Problem

I first got aware of a really hard to grasp performance problem of React by this blog post from Rich Harris: "death by a 1000 cuts".

The danger of defaulting to doing unnecessary work, even if that work is trivial, is that your app will eventually succumb to 'death by a thousand cuts' with no clear bottleneck to aim at once it's time to optimize.

Let's explore what that means. Let's look at a most simple pattern involving derived React state: Adding two numbers.

const Component = (props) => {
  const [n, setN] = useState(1)
  const [m, setM] = useState(1)
  const sum = n + m
  ...
}

When we just look at this piece of code, there seems to be no problem at all. This component will work smoothly and performance is absolutely no issue.

Let's observe what happens during React rendering and how this contributes to the "death by a 1000 cuts".

React components rerender on state or props changes. On every rerender, the function body of the React component will be executed. So on every rerender, the addition (n + m) gets executed, also when state or props changes happen that do not influence the result of the addition.

At first sight, this doesn't matter at all. Re-evaluating the addition every time, even if unnecessary, doesn't make any problem. To prevent unnecessary re-evaluation we can do the following:

const sum = useMemo(() => n + m, [n, m])

But wait, we are only supposed to do that with expensive computations, right? And simple addition is pretty much the cheapest thing there is.

So we do not memoize such statements and accept a little unnecessary extra work. We accept a "tiny little cut". One or a few of them don't do much harm.

But as your codebase grows and such "cuts" keep adding up to 1000, at some point the UI could get sluggish and slow somehow and you might have absolutely no idea why that is and what you did wrong (because you actually did nothing wrong).

Then you are experiencing the "death by a 1000 cuts" performance problem.

Cure

Start memoizing derived state all over your codebase with useMemo. There is no clear indication about where to start and when it is enough. At some point after doing this, the performance will be OK again. After your application grows further, it might pop up again and you have to repeat the process.

Redemption

Design your state patterns bottom-up with jotai atoms. Then this problem has no opportunity to manifest itself by design!

Let's take a closer look at the core abstraction of jotai, the atom, and how we build patterns of state with it. Let's look how we would model the above addition with jotai:

const nAtom = atom(1)
const mAtom = atom(1)
const sumAtom = atom((get) => get(nAtom) + get(mAtom))

const Component = (props) => {
  const [n, setN] = useAtom(nAtom)
  const [m, setM] = useAtom(mAtom)
  const sum = useAtom(sumAtom)
  ...
}

This Component behaves the same as the snippet with useState from above. With one difference: sum will only be re-evaluated when either n or m changes. So useMemo is sort of "built-in".

Let's explore those atom declarations and their meaning. nAtom and mAtom are so-called "primitive atoms". They are a readable and writable container for a single number. With useAtom we can interact with this container inside React components with the same interface that useState gives us.

sumAtom is a so-called "derived atom". It is a readable-only container that holds the sum of the current values of nAtom and mAtom. This container "knows", that it only needs to re-evaluate its value when one of its dependencies (nAtom, mAtom) change. Those dependencies are tracked with the get function. With useAtom we can interact with this container inside React components and get the derived value (the sum) directly.

By designing state with atoms in this bottom-up fashion, we always end up with a minimal "dependency/data flow graph" for our state, where the derived state gets only re-evaluated if one of its (transitive) dependencies changes.

If that sounds too fancy: it's basically the same thing that spreadsheets do, just replace "atom" with "cell" 😉

We always just do the minimum necessary work. No "cuts" are happening.

DEV Community: nibtime

please tell me "why"

avoid the "death by a 1000 cuts" performance problem with jotai

Problem

Cure

Redemption