If I may pick on one piece of advice here: intermediate variables. I think both the bad and good examples are both equally unreadable and feel the "good" versio

If I may pick on one piece of advice here: intermediate variables. I think both the bad and good examples are both equally unreadable and feel the "good" version would introduce more confusion into a code base than the "bad" example. For example, if I came across the example in code, I would begin to wonder why the `deltaX` variable exists at all if its only purpose is to be renamed `translateX` and spend some time tracing the code to see where the variable falls out of scope and to see if it's important. Then I might wonder whether it used for something else at some other point in time and trace the history of these lines (somewhat akin to nerd sniping). Now I'm focusing on the variable as if it's important when really the important bit is the relationship of the current to the initial. The code is obscuring the fact that "delta" is `current - initial`. Look how many times the pattern is repeated! Perhaps we need an abstraction that can produce the delta for us. However, the data structure makes that a little bit tricky as scrollTop is held in an ad hoc manner, so maybe we should update the data structure so that we can eventually have an api like: type ScreenPoint = { x: number; y: number; scrollTop: number } type toDelta = (current: ScreenPoint, initial: ScreenPoint) => ScreenPoint // example implementation of toDelta using ramda for brevity const toDelta = R.mergeWith<ScreenPoint, ScreenPoint>(R.subtract) const delta = toDelta(current, initial) shadow.style.transform = `translate(${delta.x}px, ${delta.y + delta.scrollTop}px)` Intermediate variables can be tricky because you can't always trust that the name matches what's actually going on inside, so you have to read everything anyhow.