John Carmack wrote a great blog post a while back about Static Code Analysis. http://altdevblogaday.com/2011/12/24/static-code-analysis/ http://altdevblogaday.

John Carmack wrote a great blog post a while back about Static Code Analysis. http://altdevblogaday.com/2011/12/24/static-code-analysis/ http://altdevblogaday.com/2011/12/24/static-code-analysis/ While not all of this is immediately applicable to JSHint and the like, it provides some insight into why static code analysis can be seen as helpful. As you also mention, it's really helpful for code within a codebase to be consistently written. JSHint can help enforce some of that consistency. This is where JSHint really shines. If your JS is tied to some sort of "build" process (even a short 1-2 second one), catching errors before running the build is incredibly helpful. If you intend to minify your JS code (as you should) before distribution, finding missing semicolons can be very important, indeed. I find the most helpful JSHint errors to be about mistyped variable names. It's so much easier to see that in my editor, fix it, and THEN run it in the browser.