JavaScript Equality Minesweeper

https://slikts.github.io/js-equality-game/

by bennettfeely • 8 years ago

185 112 8 years ago

slikts.github.io

ttty• 8 years ago

It's so funny. Anybody still using == with js?

simias5• 8 years ago

Plenty of beginners I'm sure. People who come from languages where == is not broken will probably default to using it, if only because of muscle memory. It might not be immediately obvious that it's broken too which makes it worse.

CraneWorm• 8 years ago

People relying on its broken behaviour :)

DougBTX• 8 years ago

I'm interested to know what people think about this with TypeScript - quite a lot of the weird behaviour in plain JS is rejected by the compiler, eg, "true == 1" evaluates to true in plain JS, but is a compiler error in TypeScript since it rejects bool vs number equality checks.

So with TypeScript code, I've been continuing to use == as in most other languages, with the expectation that any odd comparisons will be flagged by the compiler. On the other hand, I've not verified myself that it catches them all, so I wonder if anyone has come across other edge cases with this that could cause problems down the line.

slikts4• 8 years ago

The issue there is that TS allows dropping out of the type system with `any`, so it might not actually be checking the types you're comparing, so I'd still use ===.

kbp2• 8 years ago

I prefer it when Typescript tries to provide static type checking for Javascript rather than providing checking for how they wish Javascript was. `(x: number, y: string) => x == y` is an error because 'this condition will always return false'. In what language? There are linter rules for enforcing === over ==; Typescript having incorrect type definitions to try and make sure you only use == like === seems like a really poor solution to that.

slikts4• 8 years ago

It's idiomatic to use == to check for both null and undefined at least.

A lot of people seem to have a perception of languages as being handed down by some language gods, and apparent problems with the language get explained away by "mere users" lacking knowledge, perspective, discipline, etc.

skrebbel• 8 years ago

Everybody who uses >= and <= implicitly uses ==.

That said, if you mix types between comparison operands or inside arrays then you probably have bigger problems than "==" semantics. :-)

paradite8• 8 years ago

People who writes `if(value)`

blauditore• 8 years ago

But that's not the same; it's about truthy-ness. E.g. -1 and 1 are both truthy, but not loosely equal.

darepublic• 8 years ago

Truthy ? A : B Truthy && A Falsy || fallback

11235813213455• 8 years ago

For typeof obj == '..' you don't need === since typeof always returns a string

And the engine makes it as fast as === https://github.com/dperini/nwsapi/pull/11#issuecomment-38327... (Generally else == is slower than ===)

atirip6• 8 years ago

Yes. In our codebase it is forbidden to test for true/false, only truthy/falsy is allowed. The only place where === is needed and allowed is testing for if function argument is omitted. Otherwise == and yes, all developers understand that and agree and no, we haven’t had any bugs because of that. Big and complex web app, not my first, the previous gig was even bigger, same approach. Works like a charm.

noxToken2• 8 years ago

But why? I'm having a hard time understanding why you'd outright ban identity (===) and only allow equality (==).

I can think of one instance where I needed identity instead of equality, and I took the time to refactor to ensure that equality would work.

christophilus• 8 years ago

We use it to check if a value is null or undefined (`foo == null`) is true for both `foo = null` and `foo = undefined`, which is pretty handy. Other than that, we don't use `==`.

marijn• 8 years ago

As long as the types on both sides match, the behavior of == is perfectly reasonable, and in typical uses, this will be the case.

mishoo• 8 years ago

I do, when I know the types match. Also, I always use == to test if something is either null or undefined; cases where the distinction matters are extremely rare, and this looks too silly: typeof foo === "undefined" || foo === null.

yoklov• 8 years ago

Firefox has a few million lines of JS code and the coding standard prefers `==` to `===`. I don't think it's linted for though.

keymone3• 8 years ago

it seems equality operator in javascript is good for nothing but being a source of confusion and a target of jokes.

does it not make sense to just remove it from the language completely? who is deciding that?

slikts4• 8 years ago

You can't remove JavaScript features without breaking websites. The one exception was when the strict mode pragma was added, but that was a one-off, and there's too much resistance now to add more pragmas (they tried that with "strong mode").

The best solution currently is to have linter rules enforcing ===.

Nimelrian• 8 years ago

it seems equality operator in javascript is good for nothing but being a source of confusion and a target of jokes.

  if (someValue != null) {
    // someValue is neither null nor undefined
  }

> does it not make sense to just remove it from the language completely?

No, because you'd wreck quite a bit of the internet with that.

who is deciding that?

ECMA TC39

paradite8• 8 years ago

it seems equality operator in javascript is good for nothing but being a source of confusion and a target of jokes.

I would say that's the defining characteristics of JavaScript.

It makes it fun to write JavaScript with its quirkiness and "dynamic" nature. And once you master it you become a ninja.

Compare it to Java or Golang where you are restricted by the language syntax and anything slightly creative and fun is either not supported or not idiomatic.

keymone3• 8 years ago

It makes it fun to write JavaScript with its quirkiness and "dynamic" nature.

nope. none of that. there are plenty of fun, dynamic languages that aren't the horrible pile of shit that is raw javascript.

And once you master it you become a ninja.

wait, was this sarcasm? hard to tell..

simias5• 8 years ago

You'll have to show me one inventive and useful "ninja" trick revolving around the use of '=='. Sounds to me like the classic "my programming language is perfect and if you don't like it you're just too dumb to get it". This is pretty common among C developers in my experience but I didn't expect that from JS enthusiasts. What's next, PHP ninjas?

matthewmacleod2• 8 years ago

Honestly… The last thing I want in most of my code is "creativity" and "fun".

flavio81• 8 years ago

It makes it fun to write JavaScript with its quirkiness and "dynamic" nature. And once you master it you become a ninja.

Yes, a ninja of the "undefined is not a function" wars.

Sohcahtoa822• 8 years ago

slightly creative and fun

In my experience, code that is "slightly creative and fun" is unreadable and not actually useful for creating working products as a part of a team.

simias5• 8 years ago

I'm actually surprised that it doesn't give you at least a warning when you "use strict;". That being said plenty of JS linters will yell at you if you use '=='.

alangpierce2• 8 years ago

does it not make sense to just remove it from the language completely?

The way syntax is "removed from the language" in JS is by introducing commonly-used lint rules that disallow them, and that has already happened with `==`: https://eslint.org/docs/rules/eqeqeq . As long as the community makes it so a standard project setup has a linter with good defaults, `==` can effectively be removed from JavaScript without having to break nearly every website in existence (which is what would happen if browsers decided to start crashing on `==`).

teddyh• 8 years ago

“Let’s talk about Javascript!”

https://www.destroyallsoftware.com/talks/wat

tenaciousDaniel2• 8 years ago

This will never stop being funny.

giancarlostoro• 8 years ago

Great video. Wish it was much longer honestly.

brianzelip• 8 years ago

So great. There actually are 16 NaNs in the Batman song!

IvanK_net• 8 years ago

I don't think it is useful to know the behaviour of JS in such cases. In practice, you rarely compare strings with numbers, or objects with booleans.

I wrote tens of thousands of lines of JS (e.g. this library https://github.com/photopea/UPNG.js ), I never used "===" in my life :D

slikts4• 8 years ago

The implicit coercion rules don't matter if you make sure to convert the types explicitly, but then you're just relying on your discipline. You might be able to pull it off individually, but it starts mattering more when working with other people.

Also, from a brief glance at your code example, you don't seem to have caught up with other current best practices like linting or modules.

awestroke2• 8 years ago

You don't have to rely on discipline, you can use tooling like ESLint or Flow to make sure there are no implicit conversions in the codebase.

bazani• 8 years ago

Well, looks like my knowledge is negative. I clicked the box random and when i asked for my result i was 245% wrong. O_o'

raxxorrax• 8 years ago

Probably some badly placed equality operator in the script.

yifanl• 8 years ago

The calculation function is provided on the page.

lucideer• 8 years ago

The logic here is that there's three possible answers, and also a lot more empty blocks than checkmarks or Xes.

e.g.:

- say there are 100 or so blocks, 20 are checkmarks

- if I click on 40, and get 10 checks, 30 blank, that means I got 30/20 wrong

snek3• 8 years ago

I see a lot of comments here suggesting that == is okay to use if you know what you're doing or if the types on both sides match or if this or if that. Writing idiomatic code is all about being expressive and being explicit. Even in the most common case, testing for null or undefined, it's absolutely not clear what is actually happening or what the intent is. I write a lot of JS, and I've never had any justifiable reason to use ==.

always_good• 8 years ago

Agreed. The second you use `==`, now everyone else who encounters it has to do their own research to see if you indeed meant it.

It's like every time you defensively throw in a nil-guard just in case: everyone now has to go "wait, can nils really get this far into the system?"

You just start wasting the time of the people experienced enough to identify it as a potential problem.

SeriousM• 8 years ago

Thank you, that was a well written summary of my thoughts.

tenaciousDaniel2• 8 years ago

yeah if I'm doing any kind of loose type-checking I make it explicit.

if (myNum === 2 || myNum === '2') {}

It's very easy for developers to mistakenly "see" the third equality symbol and get confused by the intent of the code.

kenbellows2• 8 years ago

In that sort of case I like to use explicit type casting, e.g.

    if (Number(myNum) === 2) {}

For me this also extends to using `Boolean(val)` instead of `!!val`, etc.; though I understand the appeal of those nifty one-liners, I think they cause confusion in many places and don't communicate intent nearly as well.

thatswrong0• 8 years ago

I only ever use == to do “x == null”, to check if x is undefined or null, but not any other falsey value like 0.

platz• 8 years ago

that is the only good and handy use of it, yes.

alangpierce2• 8 years ago

Depending on your conventions for null/undefined (another annoying wart of JavaScript), I think it often makes sense to treat `== null` as a special allowed case. In the code I work in, `== null` is strongly encouraged (but not required) as the way of doing null checks, and all other uses of `==` are disallowed by lint. Just like our other patterns and conventions, it's something people pick up reasonably quickly as they're introduced to the code, nothing tricky, just a little pattern that acts as a concise replacement to the `?` operator from CoffeeScript.

The alternatives are writing `x === null || x === undefined` everywhere (which might lead to people just picking one out of laziness, leading to bugs), doing things like `if (x)` (which we still do sometimes, but can lead to subtle falsy-related bugs if you're not careful), or to do careful bookkeeping of when variables might be null vs undefined. In my opinion, the null/undefined distinction is more cognitive overhead than the benefit it provides, so it's best to just check for both at the same time and never intentionally treat them as different. Given that mindset, I think the `== null` pattern is slightly unfortunate, but better than the alternatives.

novaleaf• 8 years ago

exactly! `==null` and `!=null` are the only reasons I use it.

For those not aware, you can specify a rule in [js/es/ts]lint to allow only these cases.

Rumudiez• 8 years ago

My team checks for types, not for null.

`const isString = myVar => typeof myVar !== 'string'`

This is more reusable and more idiomatic in my opinion than null/undefined checks

danschumann• 8 years ago

`true == [1]` is news to me

linkmotif• 8 years ago

Fun game. Really captures the spirit of the subject. Great idea!!

I’m not one to pride myself on ignorance, but the JS equality operator is ridiculous and therefore, IMO, not worthy of the mental energy it demands.

How well do you know the rules for the == operator in JavaScript?

Well enough to use `===`. I’ve noticed in my code every time I’m tempted to use `==`, I always end up finding a better way. `==` is basically code smell that only really smart people should use.

wlesieutre• 8 years ago

`==` is basically code smell that only really smart people should use.

And then cross your fingers that no one else ever has to look at or work on that code because they might not pick up on whatever "smart" reason the == operator was used.

malmsteen2• 8 years ago

True == 1 but False "not ==" 0

Wut?

kenbellows2• 8 years ago

Not sure what you mean, can you explain more? When I open my console, I get:

    > true == 1
    -> true
    > false == 0
    -> true

Do you get something different? Or is the game claiming something different?

malmsteen2• 8 years ago

the game claims something different no ?

brookside• 8 years ago

  NaN == NaN

is falsy, no? (Shows as truthy in the game, unless I am misunderstanding.)

etimberg• 8 years ago

The coercing between types only happens if the types are different.

jmull• 8 years ago

NaN == NaN is falsy (so is NaN === NaN, for that matter).

But when I played the game, it looked to me like the game correctly claimed it is falsy. (Though I'm not 100% sure I know what the notation the game uses means.)

hamandchris• 8 years ago

There needs to be a PHP version of this.

spion2• 8 years ago

The problem with this and the wat talk is that

* you don't actually see the case-space (value space) of all the comparisons that do work as expected, and

* you don't a sense of what is the likelihood that these sort of comparisons would happen in real world code

Some of them like the empty string are likely to happen from user input, but Typescript mitigates those by forcing you to e.g. use Number(inputField.value) to conver to number and complaining about the assignment otherwise.

Others pretty much never ever happen - instead of comparing 1 or -1 to true, you're more likely to use if (val) which casts to boolean, and the truthy table is different from the equality comparison table (it makes a bit more sense)

Most of the real world comparisons are to non-empty strings or numbers, and those are only equal to arrays in some cases - but its rare for an actual array to be produced by anything. Things you know are arrays already you don't compare using "==" to begin with.

So yeah, in practice the confusing rules of JS equality comparison don't really matter all that much.

ryanong• 8 years ago

"So yeah, in practice the confusing rules of JS equality comparison don't really matter all that much."

I run into this all the time. Plenty of junior devs I work with do this. Unfortunately we haven't implemented typescript yet. Yea === solves this problem but I wish there was a deprecation path for ==. Why can't we figure out as a community how to deprecate horrible javascript apis? Why can't we as a community figure out how to have a good standard library?

spion2• 8 years ago

The anemic JS standard library is a much bigger problem, resulting with bloated bundles with all sorts of basic stuff in them (lodash, timezones, etc). Even worse, the fact that things aren't standard means that multiple "standard" library replacements might be used, depending on the preference of the developers who wrote the library you depend on (ramda? lodash? individual lodash subpackages? etc). Small modules don't solve the problem, because you can still have 5 small modules with a slightly different API doing the same thing, all of them used by different libraries you depend on due to different preferences of their authors.

IMO TypeScript fits like a glove on top of JS and largely gets rid of the language problems, leaving mainly library / ecosystem problems.

Dart did many things wrong, but one thing it did do right was the standard library. If we had a standard library like that in JS, that would change everything.

Another serious problem are modules. The fact that the ES6 loader is "open ended" just means that we don't really have a solution to the problem of distributing JS. The fact that HTTP2 push is somewhat broken means we can't rely on it to load ES6 modules either.

At the very least we need the concept of absolute and relative module identifiers. Even if the specifics are implementation-defined, e.g.

* whether module ids are used,

* or content hashes,

* or absolute paths (or maybe npm module names with the version?)

the ability to provide absolute modules via a DLL:

  provides 'lodash@2.0.5' {
    export ... // multiple things
  }

  provides 'other-module@version' {
  }

would be of incredible help.

That, or maybe we can fix HTTP2 push.

I mean, JS definitely has serious problems, but equality coercion is not one of them :)

haburka• 8 years ago

The deprecation path for bad apis is to use eslint. If you make it so you can’t merge without eslint passing then you have effectively deprecated syntax.

bacro• 8 years ago

668% wrong!! :D

yoava• 8 years ago

Super cool application, and can teach a lot about why you should use === instead of == in JavaScript.

The only legit case to use == is if you are

1. Insane

2. The kind of person who changes Java 1 object to equal 2

sadjfoadsf• 8 years ago

There's a lot of ===ers in here. I can't say I've ever experienced a situation where not using === has caused an issue. However, I can think of many cases where === would have caused an issue. In other words, I've found == better handles unintended logical errors. Nonetheless, the equality chart is difficult to memorize. Luckily, I typically only deal with a subset of it.

JavaScript Equality Minesweeper

Related Stories