# Comparison Operator

What is the difference between registerEarly !== true and registerEarly != true?

Hey there! welcome to the forums.

I believe the !== is the same as === which is checking for strict equality based on the type of value/variable you are checking. It is the more practical use case because often times in a production environment of code you donât want to have interchangeable types, especially when you have calculations that require numbers, if you pass in a string this could break the calculation.

the != is using internal methods to check if the values have a comparatively equal match. For example, if `x = true` which is a Boolean and you used the `!=` like so : `x != 'true'` it would return false, even though you are checking a Boolean against a String.

1 Like

If we want to dial this in, the correct term is âidentityâ. In strict type matching there is no coercion so terms must be identical to each other.

`==` is âequalityâ, or as you describe, âa comparatively equal match.â This is loose type matching that employs coercion. Does coercing A to the same type as B result in a match? The real problem here is the reading required to fully learn and understand how JS performs coercion. This is a big question that would need to be answered if we are to incorporate loose type matching in our production code, with any certainty of itâs being failproof.

``````'42' == 42
``````

vs.

``````42 == '42'
``````

In which direction is the coercion being applied? Can we say with certainty that the coercion is always String to Number (as I suspect)?

``````true == 1
``````

vs.

``````1 == true
``````

is there even any coercion going on? Well, yeah, loose typing allows `true` to be a Number. We can prove this:

``````Number(true)    //  1
Number(false)   //  0
``````

That is definite coercion being as it is deliberate. What we cannot do is trick JS into parsing an integer from a Boolean.

``````parseInt(true, 2)    //  NaN
``````

We can go with some assumptions, based upon evidence: Boolean does not coerce to a String, would be one. Object does not coerce to Array, would be another.

Finally, what coerces to what? Itâs a tough question and one for intermediate learners to understand but not one that new learners need to know about, which would explain why strict type matching is broadly encouraged and enforced in lessons. We learners want to learn the tangible stuff before the grey area stuff. We just have to take it on faith that JS has some magic sauce in the background since there is so much evidence for coercion in the language. For another day.

2 Likes

Aside

TypeScript is an overprint (my term) of JavaScript that compiles to âuse strictâ compliance but gives oversight of the code through required elements in order to be syntax error free. Does that make sense? I donât know.

Itâs main goal is to have us write picture perfect code with strict type matching, homogeneous arrays, and the like. Quality production code. What is generated from that is strict JS that can reliably be served to any device and any local version of JavaScript (ECMAScript).

Long story short, it is a lot of work to learn TypeScript, and depends upon a solid foundation in JavaScript owing to the discipline and intuition required. Beyond that, itâs just another level of vigilance, on the whole. If one is planning to work in the industry, then set aside the few weeks it will take to get TS under your belt. It will teach one how to write stricter JS if we learn from the output it generates. Then just write code that meets that level of uniformity without TS. Key is to learn it.

2 Likes

Good to see you mtf! Itâs been a long time. You helped me a lot in my earlier days.

3 Likes

Great to see youâre still going at it! It is only by creating examples that Iâve been able all these years to keep an open mind, and stay close to the beginner level with enthusiasm.

3 Likes

Long live the beginners!

1 Like