Elements of JavaScript Style
Eric Elliott

The general idea here is easy enough to get behind!

JavaScript thinkers still have a tendency to switch back and forth between what’s good for the human reader and what’s good for the execution environment.

I think the whole “simple as possible but not moreso” rule will have varying mileage for different kinds of work.

It’s often a very good idea to isolate different terms of your calculations into discrete values: Having a temporary variable for some part of a transformation on one line, and another variable for a different stage of transformation on another line. And yes, this is an artifact of limited human working memory, BUT it also makes debugging so much easier. I welcome a compiler/transpiler that does the algebraic substitution/reduction on the production code; but I don’t apologize for keeping the source code in a long form.

Our job as engineers has been made more complex by transpilation. We now must think about how to write the most readable, easiest-to-maintain source code, and now we MUST understand what the transpiler is doing to our code.

We never get to draw the line between “style” and implementation. Not yet. Languages like Ruby just hide implementation so completely that style is all that remains. I don’t want JavaScript to drift too far in that direction.