JSHint and JSLint are outdated

[slikts]

JSHint or JSLint don't belong in a list with "awesome" in the name as they're severely out of date and pointing users towards them does a disservice. The one up to date and well-maintained linter for JS is ESLint.

[mre]

I'm not a JavaScript developer, so I cannot judge if the tools are severely out of date. Do you have any references for that?

• JSHint saw its last stable release two years ago, which might be an indication, but that might just be an indication that it's relatively stable.
• JSLint was updated at the end of last year by the original author @douglascrockford himself, so I wonder why it should really be removed from the list.

Just trying to be fair here.

[slikts]

The JS spec has annual updates, and JSHint doesn't support a popular feature like async/await that's been in browsers since 2016; it's out of date and unmaintained.

As for JSLint, see usage statistics. ESLint is the industry standard, JSHint is holding on as an out of date legacy tool, and JSLint is just not used despite being the original JS linter.

[mre]

Thanks for the insights. @andygrunwald @impredicative any thoughts?

[impredicative]

In general I think it's a good idea to unlist a package that hasn't been updated on GitHub in two years, although this is not the only criteria for unlisting a package. As we see, both JSHint and JSLint have been updated on GitHub within the past few months. I am not a JS developer either, so I'll have to look more into these two.

It may help to find a way to group packages by how much they're trending relative to others for the same language, but I don't know of an easy way to do this.

[slikts]

The name "awesome" suggests that the curation criteria would be deeper than just having commits. As it stands, new developers shouldn't be looking at JSHint because it's years out of date with major and popular language features, and the usage statistics for JSLint should speak for themselves.

[andygrunwald]

Thank you @slikts for bringing this up.

I'm not a JavaScript developer

Applies to me as well.

The name "awesome" suggests that the curation ...

I agree here with @slikts

In terms of should we unlist this, let us ask a few JS people about there opinion: @asciidisco @Schepp @pago @malte-wessel can you help here? Or provide an opinion?

[asciidisco]

To me, this is all about what one likes to achieve with a list like this, for example:

From a historic point of view, it is necessary to include those tools, because the ones that are widely used today are build on the shortcomings of their predecessors. JSLint for example is still maintained, but just not widely used (don't know the numbers, but my twitter filter bubble told me so); so it's a working piece of software that isn't adopted very well (anymore). Does it work: yes. Is it useful: depends.

If you want to have a curated list of tools you recommend for todays development world, then it would probably make sense to exclude it. No doubt.

My, definitely subjective, suggestion would be: Leave the tools in, but add a marker or comment that they're outdated/unmaintained. If I would be new to the topic, and again, I repeat, it's very subjective, I would like to have access to all the information & tools. Even it would only be for the sole purpose of being able to read up (somewhere else of course) why I should prefer one over the other.

[slikts]

… don't know the numbers …

I linked to the npm statistics before.

The term "awesome" is evaluative; it suggests curation based on positive qualities, not a museum.

JSLint and JSHint both still work; JSLint is used in ultra-low-end machines because it's lighter, and JSHint is used in place of ESLint in the browsers, where ESLint doesn't run (and JSHint does poorly because it's so out of date). Both are very niche uses.

Edit: Then there's also legacy uses, which shouldn't be a factor.

[impredicative]

Niche specialty use is IMO sufficient for mention and inclusion with the noted caveats regarding its niche, especially if the project has continued to have updates. Legacy use is not.

[slikts]

Developing on such low-end machines that can't run ESLint (like Chromebooks) is exceedingly niche, so I probably shouldn't even have brought it up, and JSHint isn't adequate for what it's still used for (online JS editors), so that might as well be counted as legacy.

[mre]

Thanks everyone for your input. Very helpful and civil discussion.

I propose to add a new symbol - ⚠️ - to indicate that a tool might be unmaintained/deprecated. I also propose to add an explanation to the top of the list. Every deprecation should still be handled on a case-by-case basis. If we all agree, I'll add a few notes about the deprecation process to CONTRIBUTING.md and link to this discussion.

[mre]

Thanks all for the healthy discussion.

@slikts thanks for raising the topic and providing valuable input. @asciidisco, I'm impressed by your analytical skills and your insightful comment. Thanks to the co-maintainers @andygrunwald and @impredicative for shepherding and providing input.

[douglascrockford]

JSLint is up to date and well maintained. The statement that JSLint is severely out of date is false and uninformed. JSLint recommends the highest level of code quality. JSLint has lost popularity because it does not provide options for retaining bugs. If quality is not your first concern, then JSLint is not the tool for you.

[slikts]

JSLint can't handle trivial idiomatic JS:

const bar = () => {
  console.log("hello world");
};

class Foo {
  bar() {
    console.log("hello world");
  }
}

The errors produced by JSLint for this snippet are actual garble, even though it's valid JS. It's only supported in that the tool can recover and continue parsing, not in any usable sense.

[douglascrockford]

Your trivial code does not meet JSLint's standard.

[slikts]

The point is that they're not edge cases (they're trivial as in ordinary) and still cause unintelligible output from JSLint. At least in this case the tool was able to continue parsing, but, for example, trailing commas in object literals, a feature from 2011, completely breaks parsing. async/await also just breaks, etc.

[douglascrockford]

Fix your code and then it will pass. JSLint will not help you feel good about the bad choices you have made. There are other tools for that.

[slikts]

Again, the point is that the tool is unable to parse or produce intelligible error messages for syntactically valid JS even from close to a decade ago. It's not about it being opinionated stylistically.

[GrosSacASac]

From the readme:

indicates that the community does not recommend to use this tool for new projects anymore as it is outdated or no longer maintained. jshint JSLint

What is the definition of community used here ? Is 5 people agreeing on Github enough?

outdated or no longer maintained

jslint is updated regularly and used in stability critical application where code safety and stability is a top priority.

jshint just released https://jshint.com/blog/2019-02-05/release-2-10-0/

As for numbers of download, not everyone in the JS community is using NPM, so numbers from npm-charts for usage statistics can be miss-leading. jslint does not recommend npm so it is an unfair comparison to begin with.

jslint and jshint both work in the browser, eslint does not even though it is written in JS.

Next steps:

Decide if awesome-static-analysis is a list of awesome or popularity contest.

Sources: https://github.com/denoland/deno#deno https://stackoverflow.com/questions/23210437/npm-install-private-github-repositories-by-dependency-in-package-json

Edit: Use written English form

[slikts]

Other data sets will show the same regarding popularity; for example, Google Trends. npm is also the industry standard for JS package management. Not sure what the relevance of deno would be, and running in the browser is a niche use case.

Nice for JSHint to have caught up to async/await, but that came after I made this issue, and it's years late.

JSLint being out of date is reflected in it just falling over on valid syntax. ESLint can be configured to be strict as well, without the limitations of JSLint.

[mre]

I thought deeply about this issue lately.

Overall, I'm not happy with the way this discussion is evolving. We should all remember that there are real humans behind those keyboards that can be hurt by the things we write. Let's all be constructive.

Please review my changes in #228. I think it is a really important that we get that one right.

[slikts]

For an another point of reference, compare commit histories: ESLint, JSLint, JSHint. ESLint's is bustling, while the others have solo developers.

[GrosSacASac]

It is sad that jslint errors are unclear sometimes. I no longer recommend it to beginners for this reason.