Added rationale for not using eqeqeq

.eslintrc.js

@@ -25,5 +25,22 @@ module.exports = {
 		'keyword-spacing': 'error',
 		// Don't allow unused variables, but allow unused function args (e.g. in callbacks) and global vars
 		'no-unused-vars': ['error', {vars: 'local', args: 'none'}]
+
+		// We will NOT be using eqeqeq for a few reasons:
+		//  1. I would have to go through and check every single `==` to make sure that it's not depending on loose equality checks.
+		//  2. I'm only using ESLint to enforce style, not actual differences in functionality. ==/=== is not merely a style choice.
+		//       Yes, I know that 'no-var' is actually enforcing a difference in functionality, but in practice nobody uses
+		//       (or even knows about) var's hoisting functionality, so at this point it's effectively a style choice.
+		//  3. A lot of the time, you actually *want* loose equality checks, especially when interacting with a web server
+		//       (as HTTP as no concept of anything but strings). Yes, most of our interaction is JSON, but not all. And even then,
+		//       not all JSON actually serializes numbers as numbers.
+		//  4. `==` is really nowhere near as dangerous as memes would lead you to believe, if you know what you're doing.
+		//  5. If the idea behind enforcing `===` is to prevent inexperienced developers from unwittingly introducing bugs
+		//       via loose quality checks, in my opinion it could be just as harmful to instruct a code quality tool to
+		//       naively demand that all `==` become `===`. If a developer were to build code that works, but upon opening
+		//       a pull request they see that ESLint demands they use `===` instead, they might just click "fix" and resubmit,
+		//       expecting the code quality tool to know what it's doing. But it *doesn't* know what it's doing, since it's
+		//       just blindly alerting when it sees `==`. The change in functionality from `==` to `===` could very well
+		//       introduce a bug by itself.
 	}
 };