And even in the one case where == says they are the same, you can fix that by making sure you are using === so that it doesn't do type coercion for the comparison.
What's confusing about that? It's null, just two different kinds with slightly different meanings. Is having two boolean values also confusing?! Should we simplify it?
I mean I can get behind trying to remove null entirely and replacing it with better concepts, but I cannot understand why having one more null value suddenly makes it confusing. You don't even have to care in 95% of the cases, and it can be useful in the other 5%.
Honestly, it looks more like some kind of misguided purism to me.
Oh man, you've got me itching to get into the intricacies of JavaScript…
One fun example of the difference: when doing arithmetic operations, null is indeed converted to 0, but undefined is converted to NaN. This has to do with null being an assigned value that represents empty, whereas undefined is not actually a value but a response indicating that there was no value assigned in the first place.
response indicating that there was no value assigned in the first place.
You can explicitly assign undefined to a variable though.
Another fun fact about JavaScript is that undefined never used to be a keyword. If you did var foo = undefined, foo would indeed have a value of undefined, but it was only because there was no variable called undefined in scope!
You could do varundefined = 42 then var foo = undefined would actually set foo to 42! window.undefined = 42 would break all sorts of things.
Thankfully this was fixed with ES5 in 2009, although it took a few years for browsers to make the change.
Javascript, regarding zero, null and undefined =
They're all the same thingThat's not true these days. You can try it yourself right in your browser's dev console.
These results are from Firefox's console.
0 == null == undefined > false 0 == null > false 0 == undefined > false null == undefined > true null === undefined > falseAnd even in the one case where
==says they are the same, you can fix that by making sure you are using===so that it doesn't do type coercion for the comparison.Shhhhh, bashing Javascript is cool around here.
Just make fun of it for having two flavors of null.
So what's wrong with having two flavors of null?
It's super confusing. A lot of people think even one null is a problem.
What's confusing about that? It's null, just two different kinds with slightly different meanings. Is having two boolean values also confusing?! Should we simplify it?
I mean I can get behind trying to remove null entirely and replacing it with better concepts, but I cannot understand why having one more null value suddenly makes it confusing. You don't even have to care in 95% of the cases, and it can be useful in the other 5%.
Honestly, it looks more like some kind of misguided purism to me.
Why stop at two? Why not have a dozen versions of null?
Idk, how many more do you need?
Oh man, you've got me itching to get into the intricacies of JavaScript…
One fun example of the difference: when doing arithmetic operations,
nullis indeed converted to 0, butundefinedis converted to NaN. This has to do withnullbeing an assigned value that represents empty, whereasundefinedis not actually a value but a response indicating that there was no value assigned in the first place.You can explicitly assign undefined to a variable though.
Another fun fact about JavaScript is that
undefinednever used to be a keyword. If you didvar foo = undefined,foowould indeed have a value ofundefined, but it was only because there was no variable calledundefinedin scope!You could do
var undefined = 42thenvar foo = undefinedwould actually setfooto42!window.undefined = 42would break all sorts of things.Thankfully this was fixed with ES5 in 2009, although it took a few years for browsers to make the change.
javascript moment
Reminds me of this trifecta.