TECHjerm

By Saylee Tushar Chitre (schitre)  and Juilee Tushar Chitre (jchitre)

Transcript of Podcast:

Our project is Evaluation of JavaScript Source Code Analyzers named JSLint, JSHint and ESLint. 


In this podcast, we will talk in detail about the tool JSHint and its inner working. Also, we will evaluate two popular JavaScript libraries using all the three tools. We will also be talking about the JavaScript community acceptance of the different tools and investigate the reasons for the peculiar reactions of JavaScript community to these tools. 


Let’s start off with JSHint and why it came into picture when we already had JSLint. JSLint has certain style conventions that were not acceptable to the JavaScript community and also had no configuration options to turn off such features. For example, JSLint mandates users to combine variable declarations with the previous ones. It prefers all declarations at the same place. For example, a statement of the form var b=c; has to be combined with the previous var a=d; statements. This is one of its many requirements, thus showing that JSLint is very opinionated. And it needs all variable declarations at the top. Without this, it simply refuses to scan your program ahead. And there is no way to turn this feature off. As we can observe, JSLint reported more errors than users liked and became less usable. A software engineer named Anton Kovalyov thus forked JSLint and created JSHint  in an effort to make a more community driven and useful tool.  


Let us now talk about how JSHint works and how to use it. JSHint works by parsing the source code provided to it and looking for problems. It uses a Pratt Parser with top down operator precedence just like JSLint. Developers can refer the JSHint documentation to find which options are ‘enforcing’ and which are ‘relaxing’. It means that some warnings are displayed by default and you need to enable ‘relaxing’ option to turn them off. JSHint has many more configurable options and relaxing options as compared to JSLint. It is also less stringent compared to JSLint

which explains its popularity.


Now, let’s talk about the first JavaScript codebase that we evaluated.

It is Skrollr.js. It has one source file named skrollr.js containing around 1640 lines of code. 

Skrollr is an scrolling animation library majorly used for parallax scrolling written entirely in JavaScript. Parallax scrolling creates an illusion of depth in a 2d scene by scrolling the background images slower than the foreground ones. It can be used to enhance your web application’s user interface. We came across this unique and popular library while researching on the current trending JavaScript libraries and thought it was really cool and hence decided to investigate it in our project.


Now, let’s talk about the evaluation of Skrollr using the different tools:

JSHint gave no errors or warnings with the default configuration.

ESLint gave 116 warnings or problems and most of them were asking to “use double quotes for string literals” wherever the program used single quotes, while  another was “no fall-through without explicit comment”-only ESLint has identified this problem. In our blog post, we have already spoken about dealing with these kind of problems and how switching off certain warnings can relax the criteria for you.


JSLint found 51 errors in only 5 % of file, also scanned only 5% of the file. JSLint has a default maxerror count of 50 and stops scanning a file for more errors the moment it crosses this value. We can make JSLint scan the entire file by setting this maxerror configuration option to a very large number. It would have been great if JSLint scanned the entire file by default without requiring this extra work on our part.


The next JavaScript library we evaluated is Underscore.js. Let me tell you a bit more about this unique library. 

Underscore provides support for functional programming aspects for JavaScript. It is a utility-belt library and does not extend any of the core JavaScript objects while achieving its goals.

It has one source file named underscore.js containing around 1300 lines of code. 


Now, let’s talk about the evaluation of Underscore.js using the tools. JSHint found 45 errors in the entire file. 

JSLint found 50 errors in only 4 % of the file. On setting the configuration option maxerr to a huge number, it scanned more but stopped because of the problem of var declarations in the middle of the file which was discussed earlier.

ESLint found 82 problems in the entire file but the thing to note is, ESLint works differently from both JSHint and JSLint, so even the type of problems that ESLint identifies are somewhat different from JSHint and JSLint. 


One fun thing that we tried was we evaluated each tool’s code base using that tool itself. We wanted to know if the tools themselves followed what they preached. 

And surprisingly, JSLint and ESLint were the winners. JSLint gave zero errors or warnings about itself with the default settings.

And, for the next one, we both were a little taken aback to find the usually lenient JSHint giving 

52 warnings and too many errors-regarding mixed spaces and tabs about itself. 

When we resolved the errors regarding mixed spaces and tabs,  JSHint gave 37 warnings about its own code base. 

As for the third tool, when we evaluated ESLint using ESLint, ESLint also did not find any errors with itself.


Now, we will discuss our analysis of the communities of these tools.

Firstly, let’s consider JSLint here. The tool has a Google+ community moderated by Douglas Crockford himself, having around 247 members currently. We analyzed some of the posts and topics of discussion going on there. Most were about people posting code snippets and asking if they could be warned about additional things and about some cases where JSLint apparently did not give correct warnings. Douglas Crockford monitors the community and “fixes” JSLint code where he finds it necessary or useful. However, one very striking thing we realized was that there were almost no posts about relaxing any strict rules or adding any option to customize or relax a rule. In fact, in the feedback section of JSLint website, Douglas Crockford himself states that “.. please don't ask me to dumb JSLint down or to make it more forgiving of bad practices. You would only be disappointed.”  So, we see that it is more difficult to contribute to JSLint. The updates and/or added features have to be first approved by Mr. Douglas Crockford himself.

Hmmn..rather strict..


Now, let’s contrast this to the JSHint community, wherein firstly, JSHint is a community driven tool and appreciates input from the community members. One great thing we noticed about JSHint is the high amount of community activity in order to constantly upgrade it by providing new features. It is open source and developers are paid to fix some important bugs. Its new website was released this October. It has a great visual interface which continues to evaluate and provide reports about your code snippet while you type. So, it kind of gives you feedback about your code on the fly. We thought this was pretty cool and useful. JSHint, being a tool driven for and by the JavaScript community has greater acceptance among its users. The JSHint website also states which companies are using JSHint and we found it to be a rather impressive list with Twitter, Facebook, Yahoo among the prominent ones using it. Also, we found the manner of discussing updates in JSHint to be very encouraging. People were thanked for their contribution in adding a feature, check or an option. This goes very well with their community-binding perspective. 


Now, comparing JSLint and JSHint with ESLint, ESLint seems like a new player and a rather new entrant in this domain. All updates and issues related to ESLint are discussed in github itself and as of now, it does not have a website of its own. 368 issues have been resolved till now, which is quite a good number. The rationale behind writing ESLint is an interesting and promising one. The developers said that after JSLint frustrated them, they took to JSHint, but even that seemed limiting because you cannot add custom rules there. Rather, you go by what the overall JavaScript community says. But your particular team’s requirements could be very unique and different. In such situations, putting in requests to change JSHint community-wide does not make sense. Also, limiting yourself by JSHint and trying to figure out your project-specific details remains unsolved. So, ESLint has this very unique and amazing feature of being able to add custom rules to ESLint which can be switched on or off with a simple config file. We found this feature very innovative and it has the ability to help out different teams customize the linter for themselves. Also, an interesting point to note: while looking out for JavaScript tools for this project, we found JSLint and JSHint immediately, while we posted on the LinkedIn community of JavaScript and one of the members suggested ESLint as a useful tool. So, we feel ESLint has the potential to be a mainstream tool and certainly found it useful.


According to us, a great way to use the tools is to choose the tool appropriate for your project,  configure  rules to give warnings or errors as you need, derive qualitative conclusions from results, incorporate those in your code and contribute to help improve the tools, if possible.

We hope that this podcast has given you all a good overview about the communities surrounding the tools and an idea about their roadmap . Thank you!


JavaScript Source Code Analyzers Podcast

Bryan O'Sullivan shares his experience helping make developers more efficient, both inside of Facebook as Director of Developer Efficiency and with his various Haskell libraries, some of which you probably know and use already: aeson, attoparsec, criterion, statistics, and text (to name a few). We speak about performance and optimization of Haskell programs and where documentation for "Real World" Haskell development should go from here. The talk with Bryan also reveals how far you can go with Haskell without being overly concerned about category theory and the other math behind the language and libraries.

The Haskell Cast #10 - Bryan O'Sullivan on Performance and Efficiency

Welcome to JAMstack Radio, a new podcast that discusses the JAMstack, a new way to build fast and secure apps or websites. JAMstack Radio is hosted by Brian Douglas, Developer & Advocate at Netlify.

In this first episode, Brian is joined by Aaron Autrand, and Christian Schlensker to discuss the JAMstack and some of it’s best applications.

Producer: Ted Carstensen
Editor: Lucas Oswald

Subscribe on iTunes

JAMstack Radio - Ep. #1, Introducing JAMstack Radio

In the second episode of JAMstack Radio, Brian talks with Matt Biilmann, the Co-founder and CEO of Netlify, about the origins of the term JAMstack and the massive changes in web infrastructure over the past decade that have made this new stack possible.

Producer: Ted Carstensen
Editor: Lucas Oswald

JavaScript Source Code Analyzers Podcast

sayleechitre