Why I forked JSLint to JSHint

This post was originally published on February 20th, 2011 on my personal blog.

Your sadly pathetic bleatings are harshing my mellow. — Douglas Crockford

This Friday we released JSHint, a code quality tool designed to detect errors and potential problems in JavaScript code and to enforce your team’s coding conventions.

JSHint is a fork of JSLint, the tool written and maintained by Douglas Crockford. JSLint served me well for quite some time but in the past few months it has gotten uncomfortably opinionated and hostile towards your code. It is quickly transforming from a tool that helps developers to prevent bugs to a tool that makes sure you write your code like Douglas Crockford.

Here is an example. Take a look at the code below and try to find a fatal error.

/*global jQuery */
// Example taken from jQuery 1.4.2 source
jQuery.extend({
  /* … */
  isEmptyObject: function( obj ) {
    for ( var name in obj ) {
      return false;
    }
    return true;
  }
  /* … */
});

Can’t see anything wrong with this snippet? Me neither. But JSLint refuses to proceed further, failing with an error that tells you to “move ‘var’ declarations to the top of the function”. What is even worse, there is no way to turn this behavior off. You have to either rewrite your code or stop using JSLint.

This is why you can go to any meetup or a conference, find a JavaScript developer who uses the language on a daily basis and chances are, you won’t find much love for Crockford’s creation.

And this is very sad because I believe in code quality tools and I think they are beneficial to the community. That’s why I started JSHint. And, as we were saying from the day zero, it will always be a community-driven tool. Simply because a community of programmers working together is better than a single person working alone. No matter who this person is.

(Special thanks to Paul Irish, Divya Manian and Jamie Gillar for helping me with this project, and Ryan Grove for donating domains)

This article in Japanese.