It’s pretty common to hate on the Javascript-sphere and plethora of ever changing libraries and frameworks that we all have to keep track of and learn. There’s a reason that parody O’Reilly book covers like this one exist after all:

Real world rewriting your front end every six weeks. By ORLY.

Whilst I was writing my last post about setting up ESLint I was thinking to myself that even in the space of linting there has been so much change in a short space of time.

It would be easy to get frustrated with the fact that I had to learn how to use and integrate a new linter into my work flow over and over. But after some introspection I found I wasn’t that frustrated. Not at all really. But then, why not?

When I had a good think about it I realised that the reason I wasn’t too miffed about making these changes was because each iteration of linting package was an improvement on the last. It was a step towards an ideal. More than that I knew that for each step the price I was paying in development time would be worth it for the benefits I could reap.

Coming to this realisation is what inspired me to write this post. I’m hoping that this will be first in a “How did we get here” series of posts where I cover the evolution of different tools and frameworks, why we thought they were the bomb at the time we were using them and why the next tool or framework became the new “must have”. My hope is that when we all gain this understanding it will go some way to waylaying our future frustrations at having to integrate “another bloody tool”.

So without further ado let’s look at ESLint and answer the question; How did we get here?


In the beginning a bloke named Douglas Crockford (an amazingly clever chap and Javascript pseudo-celebrity) created a tool, JSLint.

It was designed to analyse Javascript source code and check it for syntactical errors. Being that Javascript is an interpreted language JSLint was a boon for Javascript developers and everyone generally agreed the Douglas really was on to something with this whole “linting” business. One thing that was widely disagreed upon though were the rules that were enforced by JSLint. Some thought they were too strict and other’s thought that the rules could have gone further.

The commonly accepted best practice at the time was “Use JSLint because it’s good. But it’s not so good that it will be able to know which warnings you care about and which you don’t so just ignore the ones that relate to rules you don’t agree with. Hey, you can’t have everything right?”.

This seemed like sound advice when the only tool available to you was JSLint but it wasn’t long before this wasn’t good enough to satisfy the developers of JSHint.


JSHint was born out a desire to reach a nirvana of flexibility where we could have a linting package that was suitable for use in any Javascript project without the need to have hundreds of false positive warnings cluttering up our error lists. JSHint’s goal was to become an equally powerful yet more flexible derivative of JSLint.

JSHint forked the JSLint code in early 2011 and started modifying the rules that were being enforce by JSLint to make it a bit less evangelistic and a bit more realistic. Early on in development of JSHint the developers realised that they were never going to get to reach the “goldielocks state” of being juuuust right. So, they decided to add the ability for you to modify which rules were being checked.

Everyone rejoiced in their own slice of linting perfection and as wider adoption grew the project gained even more functionality and tooling surrounding it. Thus JSHint became the standard for making sure your Javascript syntax was inline (pun intended).


After some time watching code happily pass through it’s JSHint rules people began to notice other problems in their Javascript code. Not necessarily syntactical problems but problems none the less.

For instance people began experiencing the pure white hot fury of finding another tab instead of the correct 2 spaces. Or maybe finding that some inconsiderate person had made another if statement with one line of code in the body instead of correctly in-lining the if! ARGH!

JSCS was created to try and bring this madness to end and finally be able to enforce practices like putting the curly brace on the same line as an if statement instead on the next line like a savage.  Calm down there I was only joking about these hotly fought about stylistic choices (or was I?) but none the less JSCS was the solution to an important problem.

Before JSCS there wasn’t really a way of bringing any sort of standard to the way your code was written. Sure you could write some formal documentation about your project’s coding standard but that was your last and only form of control over coding style.

Whether you agree with all the rules or not, by defining a team coding style with JSCS you are able to create a code base that looks as professional as it functions. Not only that you foster an environment where if two pieces of code look the same there’s every chance that they will act the same. You see when you look at a code base and it conforms to a certain style of indentation or it prefers one way of implementing an if statement over another then your eyes begin to get trained to look for these patterns. This aids a lot in your comprehension of the code. Just by looking at it you can discern something about it and what it does.

This sort expressiveness is invaluable when you are working as a team on a project because it doesn’t matter who wrote the code (even you from 6 months ago) your chances of understanding it’s purpose are increased substantially. With this understanding you are able to make quick assumptions about the code based mostly on it’s structure and style alone. When you can do this you stand to make big gains in the speed and quality in your development.


Overtime JSHint and JSCS grew to be widely popular and you would find that they were almost always used together. We were all very pleased with the code that we were putting out and it seemed we had finally come up with a tool set that ticked all the boxes.

This is the reason why, for some us ESLint, kind of came as a surprise. Part of the reason why it’s take up was a little bit slower (by that I mean, it took me longer to try it) was that it kind of solved a problem that we didn’t really know we had.

ESLint delivered very similar functionality to JSHint but one of it’s big differentiating factors was the fact that it brought with it the ability to be, in the words of the website, “pluggable”. Cool buzzword ESLint but what does it mean? They go on to explain being “pluggable” means that not only could you turn on and off rules like you could JSHint but you could also import entire rules sets of your own design. Other uses for functionality included the ability to import rules sets for whole different Javascript related languages like JSX and modern ECMAScript.

Once everyone (me) came around to this idea of being “pluggable” and the supreme power and flexibility it gave we saw a very quick and wide spread adoption of ESLint (I began including it in my projects) and it was at this time that JSCS jumped on the ESLint train. ESLint and JSCS went about combining functionality such that you now had a one stop shop to ensure good style and linting for code.

Now we’re here

So here we are in the present day we have one very powerful package to cover all our styling and syntax checking needs and we are all in a happy place.

I hope you can now you will find the same sort of calm that I have experienced by knowing the history of linting packages and why they have changed so often in the past years. Having this understanding of the reasoning behind these changes helps us to remember that no developer sets out with the specific intent of frustrating everyone by unnecessary change.

Everyone who works on projects like this are merely striving for innovation in an attempt to make good code easier to write. Whilst it has been a difficult experience for us all to work through these changes I think you’ll agree that each step of the way has added real value and that now, with ESLint, we’re all in a much happier place.

If you’d like to continue this conversation then please don’t hesitate to drop a comment below or get in touch with me on any of the social medias. You’ll find my social media details at the top of the page. Otherwise I’ll talk to you next week!