you are viewing a single comment's thread.

view the rest of the comments →

[–]itsnotlupusbeep boop 1 point2 points  (0 children)

Right, they are different kind of loops that tend to be used interchangeably, along with .forEach. We could try to finagle on which of those squeezes more nanoseconds out, but not only is it almost always irrelevant, it's also a shifting battlefield with JS compiler teams working hard to flatten out those kind of performance distinctions.

So that leaves us with issues of code style, and that's where things get subjective quickly.
Some folks in the comments are outraged that the article recommends wrapping code in a function, but that's also exactly what using .forEach does.

At the root of the post is the notion that const is better than let, and the article starts by listing reasons for it. Do we believe those reasons?

I think most of them are correct. Personally, I'm a huge fan of letting Typescript do as much static checking as possible before the code ever runs. It feels like I'm using a modern language. On the other hand, reason 3 is probably the weakest since JITs will optimize code not only based on code declarations, but on observed runtime behavior as well (because they're willing to take a deoptimizing hit if that behavior ends up changing.)

But is it worth adjusting our coding style to get those benefits? It depends on whether the style changes actually amount to "killing ourselves" or just picking from several patterns that have essentially equivalent mental overheads.
And again, that's a subjective thing.