Great to know! I don’t use Aptana myself, but it’s always good to have options and know what tools are available within them.

It is activated by going into the preferences and via Aptana > Editors > JavaScript > Validation > JSLint JavaScript Validator.

And yes, integrating it into your development enviroment is a nice thing to do.

Morgan,

yeah, me too. I’m also using it in TextMate, but sometimes go to the site for more options.

Andrea,

It is mainly about best practices, and then what’s correcct code is sometimes differing between different web browsers’ views. But I would say that you enctounter the sampe problems with CSS:

You have good nice valid code, which you then need to tweak for certain web browsers (thinking hasLayout fixes of other features).

Tommy,

As far as I know, the web browser support for === is “complete”. Meaning, I haven’t yet encountered a web browser which doesn’t support it, and using it’s a great way to avoid conversion errors.

Andreas,

The number of errors JSLint throws can be intimidating at first but, just like with HTML-validation, after a while you learn to avoid and understand the errors and write code that’s error-free.

Exactly!

And yes, YSlow offers the option of JSLint-validating the JavaScript of the web page you have navigated too (and CSS validation as well).

My framework automagically compresses all my JS using Dean Edwards JS-packer and if it doesn’t validate in JSLint it normally throws errors compressed so I guess that’s a form of validation.

Regardless, I almost always validate larger chunks of code and jQ plug-ins.

The number of errors JSLint throws can be intimidating at first but, just like with HTML-validation, after a while you learn to avoid and understand the errors and write code that’s error-free.

BTW, I think YSlow comes with a JSLint tool. Or is it built into Firebug perhaps? There’s a JSLint-option under “Tools” that validates your JS in a new window at least.

BTW, how is browser support for the === and !== operators?

Anyway, I agree with you about limitations, but what I meant id that if JSLint says “your code is rubbish”, it doesn’t mean it truly is (while W3 validator, for example, is much more accurate).

Finally, thanks to Doug for this tool, but I could not ever integrate them in my JS development environment, for reasons I said

It’s more for syntax checking and promoting good coding practises. Think of it as an automated code review; obviously it’s got it’s limitations (just like any other automated validator), but it’s a good starting point.

var a = this.b = function(){}; // what’s wrong? … maybe nothing?

Anyway, applied rules are usually good practices, but we should consider how specific browser JS engine implements our code, because everyone does it in a different way.

What I mean is how can we have a perfect “JS ruler” if every JS engine parses our code modifying them in a different way?

I hadn’t thought about using it with Eclipse yet though

This is very helpful so I’m going to use it from now on. It gave a lot of errors on a script I’m working on now, but it didn’t *really* hurt my feelings. I resolved all problems and learned some things to boot.

I haven’t been able to get it ALL right but most of it, if nothing else you get some good code convention pointers from JSLint. Like always using === and indenting with four spaces.

The main reason I use JSLint is to make sure my Javascript is “valid” before pushing it through something like Packer. I had a few instances where I’d missed a semicolon or something, which wasn’t a problem until the script got compressed.