A Comparison of JavaScript Linting Tools

A linting tool helps me avoid silly mistakes when writing JavaScript. Despite my many years of experience, I still type variable names incorrectly, make syntax errors and forget to handle my errors properly. A good linting tool, or a linter, will tell me about this before I waste my time—or worse, my client’s time. A good linting tool can also help make sure a project adheres to a coding standard.

There are many linters available for JavaScript, but how do you choose which one to use? Let’s take a look at both the features and the pros and cons of four popular alternatives: JSLint, JSHint, JSCS and ESLint.


The four tools work in the same basic way. They have a set of rules which they use to analyze and report problems in JavaScript files. They can be installed via npm. They are used from the command line by passing in files, are available as plugins for tools like Grunt, or are integrated into editors. They all support using comments for configuration.

But that’s where the similarities end. Each tool has its own pros and cons—it’s just that some have more pros than others.


JSLint Logo

JSLint is the oldest of the four. Douglas Crockford created it in 2002 to enforce what, in his experience, are the good parts of JavaScript. If you agree with the good parts, JSLint can be a good tool—you install it and it’s ready to go.

The downsides are that JSLint is not configurable or extensible. You can’t disable many features at all, and some of them lack documentation. The official website is not very helpful, for example it lacks any information on how to integrate it with your editor.


  • Comes configured and ready to go (if you agree with the rules it enforces)


  • JSLint doesn’t have a configuration file, which can be problematic if you need to change the settings
  • Limited number of configuration options, many rules cannot be disabled
  • You can’t add custom rules
  • Undocumented features
  • Difficult to know which rule is causing which error


JSHint Logo

JSHint was created as a more configurable version of JSLint (of which it is a fork). You can configure every rule, and put them into a configuration file, which makes JSHint easy to use in bigger projects. JSHint also has good documentation for each of the rules, so you know exactly what they do. Integrating it into editors is also simple.

A small downside to JSHint is that it comes with a relaxed default configuration. This means you need to do some setup to make it useful. When comparing it with ESLint, it’s also more difficult to know which rules you need to change in order to enable or disable certain error messages.


  • Most settings can be configured
  • Supports a configuration file, making it easier to use in larger projects
  • Has support for many libraries out of the box, like jQuery, QUnit, NodeJS, Mocha, etc.
  • Basic ES6 support


  • Difficult to know which rule is causing an error
  • Has two types of option: enforcing and relaxing (which can be used to make JSHint stricter, or to suppress its warnings). This can make configuration slightly confusing
  • No custom rule support



JSCS is different from the others in that it doesn’t do anything unless you give it a configuration file or tell it to use a preset. You can download configurations from their website, so it’s not a big problem, and it has a number of presets, such as the jQuery coding style preset and the Google preset.

It has over 90 different rules, and you can create custom ones with plugins. JSCS also supports custom reporters, which makes it easier to integrate with tools that need their input in a specific format.

JSCS is a code style checker. This means it only catches issues related to code formatting, and not potential bugs or errors. As a result, it’s less flexible than the others, but if you need to enforce a specific coding style, it’s a job JSCS does well.


  • Supports custom reporters, which can make it easier to integrate with other tools
  • Presets and ready-made configuration files can make it easy to set up if you follow one of the available coding styles
  • Has a flag to include rule names in reports, so it’s easy to figure out which rule is causing which error
  • Can be extended with custom plugins


  • Only detects coding style violations. JSCS doesn’t detect potential bugs such as unused variables, or accidental globals, etc.
  • Slowest of the four, but this is not a problem in typical use


ESLint Logo

ESLint is the most recent out of the four. It was designed to be easily extensible, comes with a large number of custom rules, and it’s easy to install more in the form of plugins. It gives concise output, but includes the rule name by default so you always know which rules are causing the error messages.

ESLint documentation can be a bit hit or miss. The rules list is easy to follow and is grouped into logical categories, but the configuration instructions are a little confusing in places. It does, however, offer links to editor integration, plugins and examples all in a single location.


  • Flexible: any rule can be toggled, and many rules have extra settings that can be tweaked
  • Very extensible and has many plugins available
  • Easy to understand output
  • Includes many rules not available in other linters, making ESLint more useful for detecting problems
  • Best ES6 support, and also the only tool to support JSX
  • Supports custom reporters


  • Some configuration required
  • Slow, but not a hindrance

My Recommendations

My choice of these four is ESLint. JSLint is strict and not configurable, whereas JSHint is lacking the extension mechanism. JSCS is a good choice if you only want to check coding style, but ESLint does that and it checks your code for bugs and other problems as well.

ESLint is also the obvious choice if you want to use ES6 (or ES2015, as they seem to be calling it now). Of all the tools mentioned, it has the widest support for ES6 features.

If you want to try ESLint, I’ve made it really easy for you by creating a 5-step quick start guide. You can download the ESLint 5-step quickstart guide from my website.

JSHint is strong second choice. If you don’t need the advanced features of ESLint, JSHint catches a good number of issues once properly configured. JSCS, with its huge number of available rules, is a top pick if you don’t need anything other than coding style checks (indentation, braces, etc.).

I’m hesitant to recommend JSLint at all. The other tools do the same things, but don’t force any specific rules on the user. The only exception here is if you happen to agree with all the rules it enforces, in which case it might well be worth looking into.

A linting tool is a good step towards catching problems, but it only sees as many errors as its rules permit. For a more foolproof automated bug-catcher, I recommend using unit tests. Code reviews can also be useful for this purpose.

How do you and your team ensure the quality of your code?


  1. Jslint:
    “The official website is not very helpful, for example it lacks any information on how to integrate it with your editor.”

    I can find zero information on any of the sites about integration with my editor (netbeans).
    Jslint on the other hand, works just fine with netbeans.
    Just add it in the plugin-settings.
    No trace of the other ones there.

  2. I prefer JSLint myself too because it knows what it wants. There’s no letting things slide, or forgiving forgotten semicolons with jslint. It will make you cry, and make you a better coder in the process.

  3. Exactly, why mess about having to configure the others when JSLint is already configured for you by a JavaScript expert.

  4. Not all of them have anything to do with issues. Examples of rules that are purely stylistic:

    • Use spaces for indentation, not tabs
    • White-space between parameters, function foo( a ) is not allowed, where function foo(a) is.

    Although these can actually be disabled using the --white flag, who knows what else it does, since it’s not documented anywhere.

    But that defeats the purpose of not having to configure it, as you were saying. Plus, since JSLint doesn’t have a configuration file, you have to remember to use the correct configuration flags whenever you run it.

    As a fun factoid, the tabs vs spaces rule was silently added without warnings to JSLint. What if you had written your code in a certain way, and the next day it was decided that you no longer can do it like that? It seems a bit problematic to me. Especially as Douglas is saying new should not be used anymore, and many large codebases use it extensively. What happens if JSLint suddenly decides to not allow it anymore, just like it decided with tabs?

  5. My understanding is that the criticism of tabs comes down to 1) alignment problems, and 2) editor problems.

    Alignment problems because, for example, something like this is common:

    (function () {
        // ...
        if (cond1
            cond3) {
        // ...

    If you’re going to use tabs to indent and you still want this code to look correctly formatted for everyone else, then you need to take special care to use the right mixture of tabs and spaces.

    (function () {
    →// ...
    →if (cond1
    →••••cond3) {
    →// ...

    Most people don’t get this mixture right. Even some of the best programmers don’t always get this right. I recall seeing alignment problems in the Linux kernel, for example.

    And the other problem is editors, which I’m told sometimes replaces a file’s indentation style to match the editor’s configured style, so code commits end up with a lot of white space diffs.

    In a perfect world, tabs would be the way to go. As the argument goes, everyone would get to indent to whatever width they prefer. But, unfortunately, a lot of human error creeps in, and tabs end up doing more harm than good.

34 more replies