1 + false ? (I have no idea in which order JS would evaluate things as I rarely have to touch that language much anymore)
I’m JavaScript developer. I love coding WebApps. JS sucks💩.
How does people manage to work with that language?
by not ever using == and !=, but only === and !==
almost forced to for web front end. why you would use it anywhere else, however, i will never know
The same reason people drive their car to buy groceries.
You bought it for something where it was the only option, driving 30km to work everyday. But ever since you got it, the trip to the super market is kinda too hot in the summer and too cold in the winter and what if you spontaneously need to buy more than expected?
People learn it for front end dev, and then they use what they know for back end too.
By banishing the bad part of the language with linter.
For instance, standard eslint preset has rules that enforce usage of
===
, https://eslint.org/docs/latest/rules/eqeqeqThese rules often come with project starter template
And typescript is basically just a linter on steroids
Typescript :)
Don’t forget that
_.isFinite('1')
returns true ;)JS devs should have a font that turns == into ≈.
parseInt(0.00000000005)
5
As a backend developer i still dont know a shit what that means
In javascript, === does not perform type coercion when checking for equality
Because in JS:
1 == "1" // true 1 === "1" // false
1+1====2!
← dreamberd developerBasically Java in a nutshell
eight equals equals equals equals equals equals equals equals equals capital d tilde tilde
cries in PHP
I also came to represent my php breathren.
it depends on what your definition of is is
I still don’t understand the
===
operatorThe other comments explains it in pretty good detail, but when I was learning my teacher explained it sort of like a mnemonic.
1 + 1 = 2 is read “one plus one equals two”
1 + 1 == 2 is read “one plus one is equal to two”
1 + 1 === 2 is read “one plus one is really equal to two”
And you hit the nail on the head, is that === is type explicit while == is implicit.
I’d use something like:
= becomes
== equals
=== is identical to
It’s funny how everyone thinks “equals” in this context should be “identical to” when, in normal language, it doesn’t really mean that at all!
The short answer is that your language needs === when it fucked up the semantics of ==, but it’s also too popular and you can’t fix it without breaking half the web.
Like
==
but more strict. The==
operator will do type conversion, so0 == ''
will actually be true, as an example. Sometimes (honestly, most times) you may want to compare more strictly.See this StackOverflow answer: https://stackoverflow.com/questions/359494/which-equals-operator-vs-should-be-used-in-javascript-comparisons
JS’s
==
has some gotchas and you almost never want to use it. So===
is what==
should have been.All examples are true:
"1" == true [1, 2] == "1,2" " " == false null == undefined
It isn’t that insane. But some invariants that you may expect don’t hold.
"" == 0 "0" == 0 "" != "0"
> 1 == 1 true > 1 == '1' true > 1 === '1' false
(from node REPL)
Basically it’s the real equals sign
It’s like the ==, but there’s one more =
==
but for JavaScript. What you don’t understand is the==
of JavaScript.So in JavaScript there’s the assignment
=
and the comparator is
==
Since there’s no types JS will do implicit conversion before comparison when using == in a case like this
if(false == '0'){ //this is true }
But with === it doesn’t. It means literally compare these
if(false === '0'){ //this is false }else{ //so this will execute instead }
But this, however, will
var someState = false; if(someState === false){ //this is true }
Best answer. Thanks Lemmyoverflow.
Np. closed as duplicate
It’s also important if you’re checking hashes (at least, it was - if you’re using correct hashing algorithm that isn’t ancient, you will not have this problem).
Because if you take for example “0e462097431906509019562988736854” (which is md5(“240610708”), but also applicable to most other hashing algorithms that hash to a hex string), if(“0e462097431906509019562988736854” == 0) is true. So any other data that hashes to any variantion of “0e[1-9]+” will pass the check, for example:
md5("240610708") == md5("hashcatqlffzszeRcrt")
that equals to
"0e462097431906509019562988736854" == "0e242700999142460696437005736231"
which thanks to scientific notation and no strict type checking can also mean
0462097431906509019562988736854 == 0242700999142460696437005736231
which is
0 == 0
`I did use md5 as an example because the strings are pretty short, but it’s applicable to a whole lot of other hashes. And the problem is that if you use one of the strings that hash to a magic hash in a vulnerable site, it will pass the password check for any user who’s password also hashes to a magic hash. There’s not really a high chance of that happening, but there’s still a lot of hashes that do hash to it.
that is terrifying
I wish the assignment operator wasn’t the equal sign.
x 👈 5
Ok deal, but that means we need to change the equality operator to 👉👈
You sonnofabitch I’m in!:-P
x 🔫 5
the pew pew principle /s
Interpreter: Wait, x is 5?
This code: Always has been.
It is now, if you know what’s good for you.
:=
That’s delayed assignment.
procrastination assignment
====
whenLol
== same (after magic) === same and same type (in Javascript) ==== same and same type and same actual type (in the backend before conversion to JSON) ===== same and same type and same actual type and same desired type (what the customer wanted)
ChatGpt: 1+1≈2
Reddit: 1+1=your muther (sic, x2)
X: 1+1≈we should violently overthrow the government
4chan: nvm, I don’t want to get banned for saying this one
4chan: “Gamer words”
No, that’s Discord 🙃