Back to the Future: JavaScript Best Practices

A while ago, somebody asked me for some reading material on JavaScript best practices. This was the moment I realized that Douglas Crockford’s JavaScript: The Good Parts is actually outdated. On the one hand, that’s a good thing. It means that writing decent code has become more common than it used to be. On the other hand, I have no idea what “decent code” means anymore. I think it’s time to take a trip, back to the future.

The Past

Best practices in JavaScript have always been a delicate matter. In the early days, it took so much effort to get things to work in every browser, it didn’t occur to anyone that things like code style mattered.

Over the years, things got better. It was still hard to get people to agree on a set of best practices, though. Since the language is so very “expressive”, there was always more than one way to do things. Take classes. Npm still contains nearly 300 packages with the keyword inheritance. Then there are the different module systems, and even entire libraries that assist with functional programming in JavaScript.

In those days, code style was very much coupled to the framework you were using. Code that was written on top of Dojo hardly resembled code that was based on jQuery.

Around that time, Douglas Crockford wrote a linting tool (called JSLint) that checks your code for potential errors. Later, others followed.

In the past, if you wanted to read up on best practices, I would have recommended the following:

The Present

Nowadays, things are different. ECMAScript 6 defines syntax for classes and modules, slowly getting rid of the profusion of different libraries and tools. For example, using React.createClass() is considered bad practice. Class syntax has been implemented by Chrome, Firefox, Edge and Safari. Module syntax support is still in progress, but transpilers like Babel solve this problem. And it’s not just ECMAScript 6. If you want to do functional programming in the browser, you can choose a functional language that compiles to JavaScript (e.g. Elm, PureScript).

Best practices like Unobtrusive JavaScript are being revisited. According to the creators of React, inline styles are no longer bad practice. As long as you define styles as JavaScript objects (and reuse them to prevent duplication) you can place them inline to style HTML elements. The same goes for handling events (like onClick). If you are working with Angular, different rules apply of course.

ESLint is the latest linting tool. It checks code style as well as potential errors, and it supports ECMAScript 6. You can find presets by Airbnb, Angular, and so on.

Conclusion

It seems little has changed. You still choose your best practices based on the framework you are using. These frameworks, however, have moved from low-level (e.g. Dojo, jQuery) to high-level (e.g. React, Angular).

Some things do change. Certain best practices, like separate stylesheets, are being revisited. Others, like checking code style, are become more popular.