Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JSHint and JSLint are outdated #223

Closed
slikts opened this issue Jan 25, 2019 · 23 comments · Fixed by #224
Closed

JSHint and JSLint are outdated #223

slikts opened this issue Jan 25, 2019 · 23 comments · Fixed by #224

Comments

@slikts
Copy link

slikts commented Jan 25, 2019

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.

@slikts slikts changed the title JSHint or JSLint are outdated JSHint and JSLint are outdated Jan 25, 2019
@mre
Copy link
Member

mre commented Jan 26, 2019

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
Copy link
Author

slikts commented Jan 28, 2019

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
Copy link
Member

mre commented Jan 28, 2019

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

@impredicative
Copy link
Collaborator

impredicative commented Jan 28, 2019

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
Copy link
Author

slikts commented Jan 28, 2019

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
Copy link
Collaborator

andygrunwald commented Jan 29, 2019

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
Copy link

asciidisco commented Jan 29, 2019

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
Copy link
Author

slikts commented Jan 29, 2019

… 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
Copy link
Collaborator

impredicative commented Jan 29, 2019

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
Copy link
Author

slikts commented Jan 29, 2019

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
Copy link
Member

mre commented Jan 29, 2019

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
Copy link
Member

mre commented Jan 31, 2019

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
Copy link

douglascrockford commented Jan 31, 2019

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
Copy link
Author

slikts commented Jan 31, 2019

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
Copy link

douglascrockford commented Feb 1, 2019

Your trivial code does not meet JSLint's standard.

@slikts
Copy link
Author

slikts commented Feb 1, 2019

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
Copy link

douglascrockford commented Feb 1, 2019

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
Copy link
Author

slikts commented Feb 1, 2019

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
Copy link

GrosSacASac commented Feb 5, 2019

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
Copy link
Author

slikts commented Feb 5, 2019

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
Copy link
Member

mre commented Feb 5, 2019

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
Copy link
Author

slikts commented Feb 5, 2019

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

@GrosSacASac
Copy link

GrosSacASac commented Feb 5, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants