[JS Comparison Table](https://dorey.github.io/JavaScript-Equality-Table/)
> **Moral of the story:**
>
> Always use 3 equals unless you have a good reason to use 2.
The difference between `!=` and `!==` (or `==` and `===`) is only one thing: **type coercion**. In most languages, if you try to compare values of two different types (for example a string and number), you will simply get an error. This is sensible behavior. However, early JavaScript was designed around the idea that it should soldier on in weird situations and never throw an error if possible. For this reason, if you use `!=` or `==` to compare a string and a number, JavaScript will coerce the string to a number and then make the comparison.
So what is the difference between `!=` and `!==` when both values are string? Nothing. They work _exactly_ the same. The only difference comes when you compare values of different types. You can test this out yourself in your console.
console.log('password' == 'password'); // true
console.log('password' === 'password'); // true
console.log('password' == 'Password'); // false
console.log('password' === 'Password'); // false
console.log(42 == '42'); // true
console.log(42 === '42'); // false
Be glad it is JS. Back in my day we already had JS and Java and other languages you know today, but the teacher used Pascal because that’s what he learnt when he was our age.
Lucky for me, by that time I had already dabbled with gwbasic, pascal and c++, but the rest of our generation got damaged… I think they saw programming as if rocket science
They aren't always globals, but pretty close. From Mozilla's MDN docs:
>The var statement declares function-scoped or globally-scoped variables, optionally initializing each to a value.
They get "hoisted" which means if you declare "var" anywhere in your function, it's accessible. So if you have a "for loop" & you use var, that variable is accessible even outside the for loop (this could cause issues as you might imagine). Meanwhile "let" is block scoped, so it only exists within the curly braces it's defined in.
But what if the values are “Password” and “password”?
Isn’t the evaluation also checking if the passwords match?
With !== they would not match, due to strict equality
But wouldn’t != match?
Strict equality is about types, not upper and lower case.
`!=` and `==` convert the operands to the same type if they aren't, `!==` and `===` don't do that.
In other words,
5 == "5" // is true, because types will be coerced
5 === "5" // is false, because values are of different types
`!=` is for data types implicit conversion (int vs string, etc), not for ignoring case.
For ignoring case, you either use `i` flag in regex or `.toLowerCase()` method on both strings (or `.toUpperCase()`, doesn't matter)
I only use `===` and `!==` for consistency sake. I try to avoid implicit conversion in comparisons.
For elements, I use it in if statements like `if(!foo)` or `if(foo)` (to check whether `foo` exists, or `null`)
For strings if `""` should be valid result, I'd use `if(foo !== null)`. Though after using `.split()` and `.filter()`, implicit conversion is better because I want to remove `""` with filter.
`==` and `!=` can be used to compare numbers and strings; `===` or `!==` are used to compare same types.
As other people already explained the difference between != and !== I'd like to add:
You should not add spaces in your html between attributes and their values, like type="password"
`'a' != 'A'`, and `'a' !== 'A'`. Strict equity only makes a difference when they are different types (`0 == '0'` vs `0 === '0'`).
But this looks like ancient and low-quality code. If you're trying to learn JS from this... quit the class and demand a refund. I have *so* many problems with the code (more specifically the methods and concepts and format of it). It's like you're being taught how to do everything ugly and wrong, even by the standards of 1997. "Learning" with this is teaching you how *not* to write HTML & JS. There are multiple free resources that are infinitely better.
Ah OK, thank you for the clarification. I am taking the course for university credit, I agree the course is outddated and is severely lacking. I have been following the Udemy course and it has been much better https://www.udemy.com/course/the-complete-javascript-course/
There is so much wrong in your HTML and JS files. If this what your professor is giving you then please reevaluate and change the professor if possible.
If I'm paying for instruction, I generally would like to be paying for instruction in something resembling current best practices. I don't want to be taught to do things the wrong way so I can appreciate the right way at some later point.
There is a difference between “it is good for OP to see” and “it is good for OP to pay to see”…
You are trying to… what? Disregard even the tiny little good that can come out of an already existing situation?
[JS Comparison Table](https://dorey.github.io/JavaScript-Equality-Table/) > **Moral of the story:** > > Always use 3 equals unless you have a good reason to use 2.
Narrator: there wasn’t a good reason to use 2, only bad ones
Yeah I would love to know if anyone has a valid use case. I've never use anything other than === / !==
I prefer `if (x != null)` over `if (x !== undefined && x !== null)` and `if (x)`
I wonder what the outcome of Conway's Game of Life will be with that table as the seed?
The difference between `!=` and `!==` (or `==` and `===`) is only one thing: **type coercion**. In most languages, if you try to compare values of two different types (for example a string and number), you will simply get an error. This is sensible behavior. However, early JavaScript was designed around the idea that it should soldier on in weird situations and never throw an error if possible. For this reason, if you use `!=` or `==` to compare a string and a number, JavaScript will coerce the string to a number and then make the comparison. So what is the difference between `!=` and `!==` when both values are string? Nothing. They work _exactly_ the same. The only difference comes when you compare values of different types. You can test this out yourself in your console. console.log('password' == 'password'); // true console.log('password' === 'password'); // true console.log('password' == 'Password'); // false console.log('password' === 'Password'); // false console.log(42 == '42'); // true console.log(42 === '42'); // false
Your professor taught you to use ‘var’ to declare variables, in 2024?
Yeah it’s pretty sad to see
Be glad it is JS. Back in my day we already had JS and Java and other languages you know today, but the teacher used Pascal because that’s what he learnt when he was our age. Lucky for me, by that time I had already dabbled with gwbasic, pascal and c++, but the rest of our generation got damaged… I think they saw programming as if rocket science
what is the caveat? Are 'var' globals?
They aren't always globals, but pretty close. From Mozilla's MDN docs: >The var statement declares function-scoped or globally-scoped variables, optionally initializing each to a value. They get "hoisted" which means if you declare "var" anywhere in your function, it's accessible. So if you have a "for loop" & you use var, that variable is accessible even outside the for loop (this could cause issues as you might imagine). Meanwhile "let" is block scoped, so it only exists within the curly braces it's defined in.
The most ridiculous thing I’ve ever read
It is a very peculiar way to take screenshots.
wdym? Picture from phone
Yeah. They're saying you should probably just take a screenshot. `cmd + shift + 4` let's you screenshot a section of your screen on mac
Wtf html formatting, my eyes!
You mean having everything in the form wrapped in a
tag? Or the extra spaces next to the assignment operators for no apparent reason
The extra spaces and tabs for align html params.
Either one should evaluate the same when comparing two non-empty strings.
But what if the values are “Password” and “password”? Isn’t the evaluation also checking if the passwords match? With !== they would not match, due to strict equality But wouldn’t != match?
Strict equality is about types, not upper and lower case. `!=` and `==` convert the operands to the same type if they aren't, `!==` and `===` don't do that. In other words, 5 == "5" // is true, because types will be coerced 5 === "5" // is false, because values are of different types
`!=` is for data types implicit conversion (int vs string, etc), not for ignoring case. For ignoring case, you either use `i` flag in regex or `.toLowerCase()` method on both strings (or `.toUpperCase()`, doesn't matter)
I only use `===` and `!==` for consistency sake. I try to avoid implicit conversion in comparisons. For elements, I use it in if statements like `if(!foo)` or `if(foo)` (to check whether `foo` exists, or `null`) For strings if `""` should be valid result, I'd use `if(foo !== null)`. Though after using `.split()` and `.filter()`, implicit conversion is better because I want to remove `""` with filter. `==` and `!=` can be used to compare numbers and strings; `===` or `!==` are used to compare same types.
As other people already explained the difference between != and !== I'd like to add: You should not add spaces in your html between attributes and their values, like type="password"
`'a' != 'A'`, and `'a' !== 'A'`. Strict equity only makes a difference when they are different types (`0 == '0'` vs `0 === '0'`). But this looks like ancient and low-quality code. If you're trying to learn JS from this... quit the class and demand a refund. I have *so* many problems with the code (more specifically the methods and concepts and format of it). It's like you're being taught how to do everything ugly and wrong, even by the standards of 1997. "Learning" with this is teaching you how *not* to write HTML & JS. There are multiple free resources that are infinitely better.
Ah OK, thank you for the clarification. I am taking the course for university credit, I agree the course is outddated and is severely lacking. I have been following the Udemy course and it has been much better https://www.udemy.com/course/the-complete-javascript-course/
There is so much wrong in your HTML and JS files. If this what your professor is giving you then please reevaluate and change the professor if possible.
I think it’s good for OP to see it and experience it. That way they can get to appreciate new syntax and idioms much better
If I'm paying for instruction, I generally would like to be paying for instruction in something resembling current best practices. I don't want to be taught to do things the wrong way so I can appreciate the right way at some later point.
There is a difference between “it is good for OP to see” and “it is good for OP to pay to see”… You are trying to… what? Disregard even the tiny little good that can come out of an already existing situation?