The many faces of undefined in JavaScript

This was probably the single worst design decision of JavaScript. It is the only language I know of that has two "absent value" types. If null was a billion dollar mistake, then undefined adds an order of magnitude to the problem. There is absolutely no reason for undefined to exist.

We've generally adopted strict mode. I think it is now time to come up with and adopt a new no-undefined mode. And yes, it should break the standard library. It is worth it.

This was a nice read, well-written and informative!

I could add that in my mental model, the reason that an object property with an undefined value is different from an actually undefined property, is that since JS objects are basically key/value maps, there is a difference between a key existing with an undefined value and the key itself not existing at all.

I never use null in Javascript, because I don't want attributes of type null, I just want attributes to either be present or not. This usually simplifies all designs and there is no need to think about null separately; it's treated in code an invalid value for an attribute.

The remaining caveat is that when serializing an object, attributes of type undefined need to be skipped, and some libraries get that wrong. So sometimes it is necessary to delete them from objects before serialization.

So in my view, things would be better if null didn't exist at all and if assigning an undefined value to an object attribute would actually delete the attribute from the object. Of course the language can't be changed now, but that is the philosophy I try to use in code design.

I do realize there is the use case of passing an update object e.g. with HTTP PUT/PATCH and wanting to make a distinction between "don't update an attribute" and "remove an attribute". In that case, null kind of makes sense as a designator to remove an attribute.

> void doesn’t introduce any new semantics to the language.

I'm sure the author is most likely aware of this plus the context is around TypeScript but I think it can still be misunderstood and if you haven't been around when IIFE were very common you might not be aware that:

`void` is a javascript operator and it does have semantic meaning, it evaluates an expression and returns undefined.

   const a = void 1;
   console.log(a); // undefined

see: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

JavaScript, where "Null: the billion dollar mistake" is doubled by having yet another null-ish value.

There is also one more kind of undefined, which is undefined as a type: the string value "undefined" for `typeof undefined`

The TypeScript portion is a little bit wrong. Return position void in TypeScript means the value is unobserved by the caller, not that it's undefined. It's subtly different.

It never fails to amaze me how JavaScript still has so many inconsistencies and weird behavior.

My biggest pet peeve is the lack of decimal in the main language.

One positive note: I think the name "undefined" is actually very fitting for what it represents.

Simple rule of thumb: never catch yourself typing the word "undefined" in a JS/TS codebase.

Easy.

For me, the flexibility that comes from loose typing is one of the biggest strengths in JavaScript. For example, using loose equality (double equals) is truthful for both null and undefined, but false for 0.

Null is the sole case in js that should always be == checked. Null or undefined should never be === unless you're explicitly encoding a semantic difference in your types.