Developer Ergonomics in Javascript
Ergonomics is the study of efficiency in one’s working environment. Developers have a strong need for efficiency since they pay an extra hefty price for distraction, an average of 23 minutes of lost time per major interruption. https://www.ironistic.com/the-cost-of-distractions-on-developers/
For this reason I think it is a wise investment to take some time up front in a project and think about developer ergonomics. In the javascript world, most conversations about developer ergonomics will be framework specific. In this article I will consider the case of a very small vanilla javascript web application.
Live Reloading
Sometimes known as hot reloading, this is the small but crucial innovation that your wep application should refresh automatically as you edit and save source code files. You get this for free if you use frameworks such as create-react-app or angular-cli. In a vanilla javascript project, I’ve used the npm package called lr-http-request and set up my npm start script to run it and it seems to work really well.
Prettier
The big innovation in this space that I’ve seen is a project called prettier which reformats your code in a systematic way. It doesn’t just pattern match formatting errors, and tries to fix them, it literally compiles your code into an AST (abstract syntax tree), and then rewrites it back as formatted code, taking into account various preferences such as number of characters per line, tabs vs spaces, single vs double quotes, and semicolons or none, which you can put in a configuration file called .prettierrc and have it run in your editor such as vscode with a prettier plug-in. Interestingly, the big frameworks do not yet come with prettier out of the box, but it is such a useful innovation, they might someday.
Having opinions is fine. But opinions about formatting in this day an age seems like a waste of energy… in other words, bikeshedding.
Even with it’s purposefully limited configuration, the output of prettier is good enough. Have faith in the utility of prettier. Move your opinions farther up the chain toward semantics.
A side channel benefit of using prettier to format on save is that syntax errors immediately make themselves obvious: if the code does not reformat on save like you expect, chances are you just typed a syntax error, even if you didn’t immediately notice the red squigglies.
Prettier does its job so well that I have disabled formatting rules from my linter.
Linting
In my opinion, code formatting should be handled by a tool specialized for the purpose: prettier, while linting should be reserved for more complex and semantic analysis such as complexity thresholds.
Linting is automated code review. It can catch potential and actual errors, and it can be used to encourage coding best practices. Opposite of prettier, linting tools have nearly infinite configurability, hundreds of rules, some of which take multiple values. The way I see it, each linting rule is a conversation starter, a starting point for further research as you learn more about best practices.
This used to be a crowded space with all sorts of javascript linting tools vying for dominance including jshint and jscs, but two tools have come out on top: eslint and tslint.
Probably either one of those will work for your project. Eslint can lint typescript files with a plug-in, and tslint can lint javascript files with a jsRules section of its config file. The choice probably comes down to preference and affinity toward or against typescript. If you never plan on using typescript, go with eslint, but if you use typescript or think you might someday switch to typescript, go with tslint
Static Type Checking
While not strictly necessary for smaller projects, I highly recommend using a static type checking language for javascript. The two big ones out there are flow and typescript. For various reasons, I prefer typescript, but flow is a great choice also. The cost of type checking is a compilation step, but with modern tooling that is not such a big deal and can be mostly automated.
https://medium.freecodecamp.org/why-use-static-types-in-javascript-part-2-part-3-be699ee7be60
More…
There are a lot more things that can contribute to developer ergonomics, such as testing, continuous integration, and so on. This article was meant to just scratch the surface. If you want me to write more along this line of thought, let me know.
