Saw a question on StackOverflow this morning that mentioned ESLint was merging with another JavaScript linter, JSCS, or at least their teams were.

I added a quick comment:

An opinion question as written (the one you link to does a good job hitting a grey area: "Show me the way code is handled differently in each"), but here's an interesting, related tidbit: It appears ESLint isn't merging with so much as aqui-volunteering (?) JSCS's team.

... the first goal of the combined ESLint/JSCS team is to make the transition to ESLint easy for JSCS users.

They've planned to add features from JSCS that ESLint doesn't have now, but it seems the JSCS codebase isn't merging with ESLint, but is likely going to wither on the vine. Makes sense, but still interesting!

_{Aside: I like aqui-volunteering. See what I did there? (Sorry.)}

One comment from the ESLint project's announcement about the merger bugged me, however...

With the new combined ESLint/JSCS team, you can expect a lot more from ESLint in the future. We now have some of the brightest people in the world working on making ESLint the best possible tool for JavaScript syntax analysis. I’m personally very excited about ESLint’s future and tackling some of the more difficult problems like making autofix possible for every rule and incorporating type information into our analysis. We can go a lot further, faster, when we’re all working on the same tool. [emph mine]

Ah, the mythical volunteer month strikes again. If only all that were true.

I still don't know what more coders really buys you. If you take the time to create clearly defined interfaces between every chunk of work, you can gain nearly 2x production from double the coders. And I think there's something to careful use of pair programming, which provides three sets of advantages:

1. Great architectural review.
2. Bug spotting that ids lots of low-hanging fruit/duh moments.
3. Shared familiarity with code.

The third is one of the most important. Forcing coders to share what they were doing and thinking with someone else gives you the first and second, but also means that your cyborg -- and all code is full of cyborgs, some strange melding of code and the style of the person(s) writing it -- is more spread out, reducing the impact whenever some of the meatware decides to move on.

But does it work here?

But when it comes to great JavaScript linting, I'm not sure more is better. You've still got one guy working on a linter as a side project that, afaict, is every bit as useful, if not moreso, in standardizing code and enforcing best practices than the work of the 371 (to date) at ESLint. (In case you're new to the blog, that's JSLint.)

I mean, tell me which code you'd rather maintain:

or...

And I should point out the JSLint repo has no folders, and you really only need that single jslint.js file. Occam's code, folk. Make code so simple to use that it'd make William proud. ;^)

I like Nicholas at ESLint. Seems like a really good guy -- and ESLint seems like a good, well thought-out tool. It just seems like overkill -- harder to maintain, more to learn to use proficiently, more likely to change from installation to installation, which means less standardized code -- and there's nothing that bugs me like over-engineering. One example: Autofixing? Why not just use Typescript from the start? Seems too much for a linter. Teach me how to write good code. Don't automate the fishing.

Here's a less biased example: Looks how excited this guy on SO is that ESLint makes it exceptionally easy to create new rules.. To me, that's cringeworthy -- No, no no, I don't want everyone on the team creating new rules! But if quickly creating custom rules is your use case, well, ESLint might be what you're looking to find.

(Though, admittedly, I have suggested to others that they hack JSLint directly, since it's just JavaScript, which might be even worse.)

Anyhow, just an interesting [to me] cultural contrast between two popular and useful linting projects.

Labels: coding, cyborg, ESLint, JSLint, style