Hacker News Reader

Comment by ricardobeat | Hacker News Reader

JSHint [1] - don't fall prey to JSLint's dictatorship UglifyJS [2] for compression

For debugging: get used to webkit inspector and Firebug. console.log is the best thing since sliced bread (object inspection, etc). Use a `debugger;` statement to insert breakpoints [3].

node.js: get started with Express [4] and mocha [5]. Make the jump to coffeescript after you're comfortable, it's a great fit on the server. Read howtonode's articles to get an introduction to various aspects of node [6].

[1] jshint.com

[2] https://github.com/mishoo/UglifyJS

[3] https://developer.mozilla.org/En/Debugging

[4] http://expressjs.com

[5] http://visionmedia.github.com/mocha/

[6] http://howtonode.org/

View on HN

I created a small node server to provide jshint as a service to people who don't care to install node on their machines. It also includes a git pre commit hook to lint each of your staged commits.

https://github.com/johnbender/jshint-service

You can use the provided address in the post commit hook if you don't feel like setting up the server yourself.

[edit: post commit -> pre commit]

Second jshint. I use syntactic vim plugin, could never go without it anymore. http://stackoverflow.com/a/5893447. Also node-dev https://github.com/fgnass/node-dev

Oh also: python -mjson.tool is great for formatting json on the command line. Like: curl -XGET http://example.com/API | python -mjson.tool

If you are seeing JSLint as a dictatorship, you are probably seeing those tools from the wrong way. Those tools helps you spot potential mistake and help your code be a little better. What they give you is advice, you will find that from time to time the advice they give you aren't that great and you are always free to ignore them in those cases.

The problem is that JSLint goes further than static analysis and suggests what could be considered simply "stylistic" changes to match the way Crockford thinks javascript should be written.

For example, doing comparisons (x == null) or (x != null) is a well known shortcut for checking vs null or undefined. There's nothing inherently "bad" about using that shortcut.

It sounds to me like what you need isn't an escape from JSLint, but rather a better JSLint config file that skips the stylistic checks you dislike. JSLint at its strictest can definitely be a little too strict.

(of course, there's really no reason to be using JSLint over JSHint anyway)

Well that was actually my point; JSHint is effectively a highly configurable version of JSLint.

JSLint is already a highly configurable version of JSLint. JSHint is a leniently configured JSLint.

breacimanno said it all. JSLint is highly opinionated, JSHint gives you the extra control so that you can use it just to catch mistakes, not conform your style to someone else's standard. I use a textmate extension that lints on every save, it's not practical/healthy to keep ignoring warnings - you know what that will lead to.

JSHint [1] - don't fall prey to JSLint's dictatorship

Keep in mind, this is simply an opinion. Although not everybody appreciates JSLint's emphasis on explicitness and readability, there are still a great number of people who do. To the OP, try both, and decide for yourself which one helps you write better code.

Reply on news.ycombinator.com